Prospero: A new coding harness for a more civilized age

Also, I don't remember how but I have heard of JUCE before and I immediately recognized it even though I have never used it. I think I spend too much time on github :D

I loved the utility of paseo but like the OP didn't want to build on web frameworks, so I re-wrote all of it in rust with zed's ui framework for the frontend desktop client.

More on my personal blog about it here: https://chicagobuss.dev/blog/my-setup/

The hard bit is when you have complex, responsive layouts involving text. (And styling it)

Something seemingly trivial like an agent-style chat containing markdown text blocks, where it's expandable and smoothly scrollable is insanely difficult. The only frameworks that do this well are browsers, and the amount of horrible, horrible logic hidden inside them to make it look easy is hard to believe.

And since in many agents you're also going to want to display actual HTML, unless you're going to embed a browser engine in your C++ library, that's just not doable.

This is what I'm doing too, and it's so much better. No more blocking copy/paste, no more stuck title bars, it actually sends notifications only when I need to give it input, it feels snappy, it doesn't destroy the scrollback buffer, messages are timestamped, I can copy my prompt out without spaces being added, it automatically bumps the agent to check when background processes run too long, and I added a sandbox that actually provides a modicum of security.

AFAIK - Of the big three only OpenAI explicitly allows third party harnesses without paying exorbitant API rates. It's one of the primary reasons I still use them.

To avoid these problems some folks use tools like herdr which operate like tmux or via the SDK to drive the official harness, rather than speaking directly to the API routes.

If you are familiar with pi, then some of the key features listed on the GitHub page (and website) already illustrate substantial differences: hax is much smaller in footprint (I wouldn't even call pi "light-weight", really - heavy js runtime with a lot of dependencies), hax preserves native terminal scrollback (pi uses alt-screen fullscreen, or clears in some cases in differential mode), hax uses normal XDG dirs (pi uses ~/.pi), hax is extended out-of-process (pi suggests in-process plugins).

There are other differences in presentation, and in features (for example, hax has background bash invocation out-of-the-box). Not practical to list all of them.

Not a big deal since most of my sessions were parked so I just found a way to have them exit without losing the screen content (I took a screen dump from herdr) and a simple wrapper script that waits until hit enter to resume the session.

I don't _ have _ to switch to a lighter weight harness, but I'm not oblivious to memory usage

Even on 64 GB RAM machines you could easily get memory pressure on the system when trying to work with a chonky local model. Consider also resource-constrained cases like small VPS servers or SBC computers (like Raspberry Pi).

Ergonomics and features are included too here. The point is that these can coexist with small resource footprint.

T3 does it this way.

I don't know why you needed a paragraph to say that 1000% memory inflation is a trade-off to optimize dev costs and we can just ignore JS because our goal is to support a browser as the gui.

It's a bunch of nonsense and yet you call what I said nonsense while all you do is provide opinion that it's OK because trade-off or something. What you said is purely opinion so you can't say my take is nonsense. There's nothing "pure engineering perspective" about it.

Even optimizing for specific hardware platforms is now trivial yet we act like everything has to be done through the browser, even though we know it's impossible to secure or do effectively because of the forest of constantly changing, proprietary tech.

It just opened. Instantly. Every button and thing happens instantly. what are we doing everywhere else. I'd forgotten that things can be this fast.