Nice to see a gui coding agent. I use tui agents all the time but I am building a gui one. I use Claude Code, Codex, opencode and a couple other but I do not like the DX/UX.
I often want click a part of the wall of text (from agent) and search for related text, open them up on the side or so. I want to open a linked file. I want to answer multiple questions in an async manner, even come back and continue answering the next day.
There are many prompt level features I want too - orchestrate with subagents, but only the tasks I select - how do I select when there is no checkbox. Or maybe delegate a subagent to dig into (read only) one portion of the chat response. Maybe codify (write) only one task in a list of tasks. So many many other small things.
As a full-time user of coding agents, the TUI barely works for me. I think splitting text, searching in text, merging text are more important in agent driven development than ever before. It is all text, all the way. This is what I am building myself, with my own gui framework.
You're not alone - I also revolted against the TUI crowd and created my own GUI-centric harness juggler (https://github.com/juggler-ai/juggler). Might be up your street. If you're not too involved in your own project, maybe help out on mine :)
Honestly, I just don't get the TUI obsession, other than the fact that people are multiplexing many remote sessions over ssh. So my aim with juggler was to have an architecture that could do all the multi-client remote sessions with a GUI/websockets/Y.js sync etc.
Hi, I tried Juggler a few months back, and while it's technically impressive as a one-person product, I found it super stressful to use. It emits so much output and activity, in various nested forms.
Where Claude Code and Codex have made progress recently, I feel, is with sharpening the interactivity. For example, Codex will emit a lightweight ream of "thinking", then on completion it will erase this and only show the final, coherent answer. It doesn't show much detail about which commands it runs, either. You can still drill into that, but it's usually the least important thing. Claude also does sub/side-sessions that can talk to the other sessions. So if a session finds an unrelated, pre-existing bug, it can start an adjacent session for the bug fix, and keep abreast on when the fix lands. If you start a side session to do research, it can message the other session with new findings.
I don't know if Juggler is still like it was, but I strongly recommend making it less verbose. I just couldn't deal with the noise.
I was doing dark magic on my Linux distro the other day and borked it terribly. I had no desktop. I knew my system would reboot. But I was able to get into a TTY and, from there, I was able to run OpenCode. With a little AI help, I get my desktop back and fully recovered. I did not even have to reboot.
Thanks Julian, I just checked it and it looks lovely and ticks quite a few of the boxes in my mental model. I will clone and dig in.
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.
Using TUI is also architecturally simpler. I don't want to rely upon third-party mappings of the CLI/MCP to the GUI, which are potentially incomplete or buggy.
I recently switched from the OpenCode GUI to OpenChamber, which still uses the OpenCode backend. It's pretty great. One of the features is the ability to select a portion of an agent's response and add a comment to it. Comments are sent along with the next prompt. It's also much better at handling subagents. With a proper plan in place, it will send out swarms in waves.
I'm similar but not really a programmer. I've been a linux sysadmin for a few decades but for whatever reason I prefer using Codex via the desktop app rather than the TUI. The desktop app on linux is fine for me. Note: i've not used it anywhere else but since linux was the last to get the desktop client i'm assuming it's at least as good on other operating systems.
On looking at Prospero it's ... simpler than this is so maybe not robust enough for your wants.
I see the argument but personally I find LLMs to be a perfect TUI application because of their functionality. Text in -> text out is precisely how the models work so the interface doesn't need to go much beyond that.
I would agree 100% with you if context was not an issue. But it is and a big one. In a chat, I have questions and investigations that should always branch off. I also make tiny test implementations from an ongoing idea (in the chat). Forking the idea, or even running parallel ideas. None of these are possible unless we can manipulate the text, split into smaller chunks and send off to agents.
Yeah but it fails the instant you want to do something audio/visual and actually see/hear anything. Good example right on the OPs site, smoothing a Mandelbrot fractal and working on a set of color palettes.
Great to see what you're doing there, but speaking as a 30-year hardcore C++ veteran (to the extent of creating my own C++ GUI framework: https://juce.com)... When I was writing a code agent (https://github.com/juggler-ai/juggler), there's no way I'd have used C++ for an agent GUI!
Agent UIs are all markdown, HTML, big scrolling lists, text flow, unicode chars, and all the other stuff that C++ frameworks are terrible at, but which is a doddle in HTML/CSS/JS.. You are a brave man!
> and all the other stuff that C++ frameworks are terrible at, but which is a doddle in HTML/CSS/JS
This is very interesting. I know that coding string-related stuff with C/C++ can be incredibly tedious and error prone (even hard security-wise). But all the stuff in the web-related stacks/libraries in other languages, is either already somehow being transcompiled to C to execute, or could be relatively easily ported/reused by directing an LLM/agent to do it
Do you think that could work to make C/C++ better at this? What things would you import/copy from elsewhere?
Strings are trivial in C++. Drawing 2D graphics is fine, many libraries do it. Creating old-fashioned component frameworks (like Qt, JUCE, etc) is easy. I implemented all those things on my own, decades before AI.
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.
> 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.
I guess this is the main issue. Either you end up reimplementing a browser (which will def have a ton of issues), or you embed a browser and you end up with bloat anyway
You don't need a full browser or a full HTML implementation. You just need enough HTML support for markdown converted to HTML and wxWidgets has that level of support for HTML backed in. I've never seen an LLM generate HTML without it being explicitly told to do so, so I don't know where this notion comes from that full HTML/CSS/JS support is needed to render LLM text outputs.
I used the wxWidgets C++ GUI for my coding agent ( https://github.com/fluxmoot/fluximp ) not directly in C++ but in Python via wxPython. While wxWidgets doesn't have a full browser level implementation of HTML/CSS/JS it has enough HTML support for rendering markdown converted to HTML just fine. I'd imagine Qt would have no problem with markdown either.
Many times, while they are doing something, I’ll be typing a prompt, and then all of a sudden I get a question with Y/N options, and by accident, I’ll type Y/N as part of a word thus “answering the question”, many times either steering in the wrong direction or stopping the agent
Neither Claude code nor Codex solve this. The only way I’ve found to prevent it is to type somewhere else and then paste, but it’s super annoying
Edit: ^^ the above is especially annoying now that Codex popups the prompts/questions within other agents' sessions
Also, when I want two agents in different sessions to talk to each other, it’s kinda janky, I have to talk to both and act as a messenger for a couple of turns before they properly coordinate. I wish I could just sort of click somewhere, and link unlink two or more sessions
Sounds even worse (and I'm generally not a fan of speech to text interfaces, as typing is a lot quicker and easier on the brain); imagine a co-worker or your wife steps in and asks a question, your "Yes" turns into an answer to your coding agent.
If you have time to do that it is great for you. But most people are application programmers who should be doing programs for end users. I do not understand why we are supposed to stop doing our job and start redefining how we build SW?
I totally agree with you and it's easier/more efficient than ever. Plus, you can build it the way you like. I'm doing the same [0] and I have big plans for it! It's currently only TUI but an agent development environment GUI is coming soon as well as cross agent/session communication.
I’m self employed, which means there is less than zero chance I could rely on self-hosted AI. $200/mo for virtually unlimited use, or $10k for a machine that will be less capable and slower?
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.
Claude doesn't allow third party harnesses unless you pay the full API price. Attempting to avoid that by pretending to be Claude code gets your account banned. Google is the same and will ban your entire Google account.
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.
What they rolled back was charging claude -p "..." and use of Claude Code as an ACP agent at API rates. But the use of OAuth2 authentication with their subscription plans still feels at least risky: https://code.claude.com/docs/en/legal-and-compliance#authent... (granted, the wording is anything but clear).
Whether and under what circumstances they actually enforce this these days, I do not know. Regardless, if your preferred harness does not support that authentication flow (which most don't), then it doesn't really help you even if you could. For what it's worth, I do not consider the Claude Code ACP adapter an adequate solution.
If you're looking for an agent implementation that is light on resources, but prefer to work in a terminal, consider also hax (https://usehax.dev/). Less than 2 MB fully static Linux binary, few MBs of RAM use in runtime. Works great with local models also (auto-detects config from running llama-server), besides the usual cloud providers.
If you’re the creator of this harness, you should disclose that. I have nothing against self-promotion, it’s just considered good practice.
Some feedback but it might be worth calling out how your harness differs from other relatively light-weight ones like Pi. I assume its got a much smaller memory footprint given yours is C versus Pi's. There are so many agentic harnesses out there that a comparison table might be a nice thing to have on the landind page.
Note: Just to be clear, I'm not accusing you of trying to hide it, given that the GitHub account for Hax is basically identical to your HN account.
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.
Thanks I'll have to set aside some time later to try it out. It's kind of a sliding scale, but pi is definitely lighter-weight when compared to harnesses like Opencode and the all-batteries included "Oh-My-Pi".
And of course, “lightweight” does have a lot of interpretations where harnesses are concerned (memory footprint, binary size, performance, system prompt, etc).
I love Hax. After a month on Codex, I switched to Hax. I've been using Hax exclusively for a few months now.
Feels so much better, so lightweight. Compiles instantly. Almost no dependencies. Like something Suckless would make. And unlike all the rest, runs easily on OpenBSD.
And as minimal as it is, it even has nice features like showing me after every prompt how much that last task cost me.
When I saw the post here about a new coding harness, I clicked in thinking, "Could anything be better than Hax?" Still no.
I don't understand the value proposition. It “works great for local models” (they all do) so you’ve got more RAM than you possibly need for any TUI you might want to run. Are people really fretting over a few MB of memory rather than evaluating these tools on their ergonomics and features?
I already found myself being limited by Memory used by Claude code, about 300MB per session. With 40 sessions that eats up quite a good chunk of my laptop's memory
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
Typical coding agents of today consume hundreds of MBs of RAM. Once you add GUI into the mix, that could easily slip into GBs. You might feel the difference, when you're trying to fit a capable local model into small amount of local RAM.
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.
OK, I like this in concept a LOT. I especially like that it's efficient and headless with an attachable GUI.
But I don't like how opinionated it is: "Therefore Prospero prime design principle: Never wait forever. Every operation has a deadline. This decision influences everything."
I respect that opinion, but I don't share it, and therefore an entire coding harness developed around that opinion is not helpful for me.
Does this support local sandboxing/isolation of the app/environment you are working on? If not I'd imagine one could figure out how to make that sort of thing work with Prospero in any case or?
As a counterpoint to a lot of the comments on this now portraying this as dated and questioning the stack behind - this is has the guts of great enterprise level software. Once you’ve serious data being thrown at something built on JS and run into OOMs, that’s when good old C(rust in the future maybe) stack shows these up.
Love to see such a strong tasteful take on software heralding back to the age of solid desktop apps.
At the risk of sounding like an ancient dinosaur- It’s not as much a feature parity but more of a maturity/ecosystem parity. I’m pretty sure rust and soon even zig are going to more than good enough. But as someone running a multi person team - it’s way easier to hire / consult on the existing Dino technologies.
Couple of notes. If a system is outputting text for humans to read, it’s not “serious data”. It’s megabytes. You can go out today and buy an off-the-shelf Apple desktop with half a terabyte of ram. My five year old laptop has 64Gb. Secondly, the sweet spot is Rust backend with typescript front end. The serious part isn’t the size of the data, it’s juggling the processes on one end, and pretty presentation to the human on the other. I’m using Tauri. As we get crates to do markdown with automatic language formatting, tables, etc I’d expect the whole thing to be written Rust
I’m on the Tauri + rust train ( for the first time ) too for the next product I’m leading. I can certainly see the benefits - will know in a few years how things end up.
A year ago I never felt my MacBook was short on resources, but these days I find myself thinking a lot about the performance of harnesses and agent tools.
i believe a harness is a personalized thing. everyone should develop their own.
doesn't take long to have a working prototype, after that you can extend it as you use it.
True. But also, polishing it still takes considerable time and thought. So using something someone else (or a community) built can still be beneficial.
There are so many harnesses, open source, teams of developers. The space is moving so fast. Why would I want to use something written by one person, in C++? How will it keep up? How do I extend it? etc.
Hey… the code looks good, I’m curious what is your development process? The parts I looked at looked almost like they were written by a human manually.
No mention of "plugin" or "extension". At this point I am not going to try one that isn't modular. Life's too short to wait for folks to prioritize my pet features, just let me do it myself.
That is old. Every harness (herdr, paseo, pi, etc) uses claude through the Agent SDK, and this draws from your subscription, not API pricing. If you're thinking of going with the "but Anthropic could ban every user doing this", if it's good enough for Google to slap it in Android Studio for everyone to use, it's good enough for you in literally any other harness.
Yes there is a huge gray area. Yes people are getting away with it. That does not mean it's allowed. Anthropic could clarify their terms any day and they don't, on purpose.
The Claude subscription does not include Claude API usage.
Claude behaves in Claude Code somewhat differently vs other coding harnesses (sometimes it's a remarkable improvement) connected directly via api. Also, it cost more than the subscription. There's quite a bit of baked in tooling and assumptions in Claude code that may be good for you, or unhelpful based on what you are doing.
Minor correction: the $20 Claude subscription doesn't include API usage, but the $100 and $200 subscriptions include a corresponding amount of monthly API credits.
I'd really like to see a comprehensive test of all of those 100s of agentic harnesses. Get a billionaire to give a million to crunch through them all within a week or so.
What a beautiful and space efficient UI. I love Dear ImGUI and the people that build interfaces with it.
Reading through the whole post, this sounds like an thoughtfully and intentionally designed product. One with strong opinions and the developer’s real lessons behind it. In the current era of slopware- especially around AI tooling - this is giving me damn near an emotional reaction. I am happy to see this.
i am looking for harness that lets me fork sessions in tree and visually support that tree. I know i can fork a session in any harness. But its hard keep track if you go more than one level deep.
I dont know if i am unique here but i often work in exploratory mode where i persue a chain of thought in a specific direction, then backtrack up and go down again arbitrarily.
Prospero was the original code name for the ps5 console that is recently jailbroken. That’s why you’re seeing a lot of other unrelated projects with this name too.
JavaScript is just about the worst thing ever and why would you use that as middleware for anything if you didn't have to? I mean, I get using Visual Studio Code, if you don't care about your business processes, intellectual property or engineers and are just outsourcing everything, but imagine actually trusting it for your coding stack like some kind of middle manager who only cares about cutting costs to the bone? Or like, you're riding the AI bubble and want to release some minimal viable product as fast as possible, but it's 2026 now. Covid was 6 years ago.
I'm a 25+ year C++ programmer, and what you're saying is nonsense. First, managing costs is an important part of engineering. More importantly, though, the use of browser engines for GUI apps isn't about JS but about the browser engine. These engines are among the best optimised and most sophisticated rich text layout engines we have. Even their high RAM usage is overstated. 1GB of RAM is 6% of the physical RAM on average hardware, and because these GUI apps are usually low-CPU, their RAM is mostly inert and can be swapped out without much impact, so really 1GB of RAM for such an app amounts to no more than 3% of the average personal machine's memory resources. Even if you can reduce that to zero, gaining 3% of memory in exchange for higher costs and compromising on presentation quality is often (not always!) a reasonable tradeoff from a pure engineering perspective.
>1 gig of ram for a gui is fine because ram is cheap I know because I program C++ and 1 gig is 6% of 16.
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.
> I don't know why you needed a paragraph to say that 1000% memory inflation is a trade-off to optimize dev costs
Because that's not what I said. My point was more that a "1000% memory inflation" is not a meaningful cost metric to begin with (to use just one toy example, perhaps you'd agree that going from 10% RAM to 100% has a very different impact than going from 1% to 10%, even though both are a "1000% inflation").
Memory (at least on a personal computer) is not rented by the hour on a per-MB basis; you buy it in bulk. What matters isn't how much memory you could have used but what you'd use the "saved" memory for. Also, when you buy a resource like RAM or CPU as a package, nominal values matter less than under what conditions one of these would reach 100% and your experience may be degraded.
For example, if you have 16GB of RAM and you only ever run one program at a time, it doesn't matter to you at all if it uses 3GB or 3MB: you've paid for 16 and the total savings of the 3MB app are zero and in this hypothetical case, there's no tradeoff at all. Now, the average user on the average hardware doesn't use only one GUI app at a time, but they're also not using 200. The only relevant question pertaining to waste is what is the value of 3% memory to your users (integrated over all of them)? In many situations (again, not all), the answer is not much. (And BTW, some developers seem to care about 3% memory more than they do about 3% CPU, even though CPU is much more expensive).
When it comes to agent harnesses, the analysis is clearer. On the one hand, people using coding agents are more likely than others to put even a little extra free RAM to some good use, but on the other hand, the cost of using the models themselves is so high that it makes the cost of RAM for the GUI negligible.
Saying that a number going up by 1000% is bad is not good engineering. Good engineering requires thinking about the actual value and cost of that number. It varies over time, over app type, over different types of users, and over different kinds of deployments (i.e. how RAM is packaged and paid for).
That doesn't make sense. If the cost of RAM is high and being used by models then yes, you should try to use less RAM. Using opposite logic is not good engineering. Seriously, what kind of argument is that? Hahaha
I'm entertaining this nonsense because I want to clarify, that I use a 20 year old web gui and it consistently eats 8 gigs of ram in Webkit because it uses CSS to update the forms. Webkit is the only option on iPads and yet it can't handle a 20 year old website because it doesn't do things in the standard ways. It's ridiculous to say "why doesn't it target web" especially after someone presents new coding harness that went out of its way to run well without it.
> That doesn't make sense. If the cost of RAM is high and being used by models then yes, you should try to use less RAM.
No, that's not the conclusion. If using models costs you, say, $10 an hour, and a GB of RAM costs you, say, $0.0001 an hour, then clearly you shouldn't spend your time on reducing the insignificant cost if you want your work to deliver the most value to users.
But again, "less RAM" is more or less meaningful whether you're reducing the RAM usage from, say, 5% to 1% or from 80% to 40%. The latter is more valuable even though it's a lower relative reduction. That's because what the users care about is in what conditions they reach 100% of either CPU or RAM, and the second 2x reduction, therefore, offers more value than the first 5x one. This is similar to how a 10% discount on a car offers far more value than a 99% discount on a pack of chewing gum. This is still the case if you're buying 100 packs, but maybe not 10,000, and the same goes for software: it may also matter how many copies of the app the user is expected to run concurrently. The point is that you can't assign a value to a 10x reduction if that's all you know.
> I'm entertaining this nonsense because I want to clarify, that I use a 20 year old web gui and it consistently eats 8 gigs of ram in Webkit because it uses CSS to update the forms.
And I'm entertaining this nonsense because you're clearly not a very experienced engineer and you may learn something. In the ninetees, when nearly all GUI apps were written in C or C++, we had plenty of examples where a C++ GUI app consumed 50% RAM. That doesn't mean that C++ is worthless, only that some software has serious resource bugs, and it sounds like that web page you're referring to is a case of that. Most web-based GUI apps today do not consume a higher portion of RAM than their C++ counterparts did 30 years ago. Today's browser-based MS Word consumes less (relative) RAM than the C++ version did in 1998, and it certainly has a far smaller negative impact on concurrently using other apps on the machine.
And, of course, there are buggy/leaky programs now just as there were then. It's silly to say that the existence of such programs means that the approach is bad, because that would apply to any sufficiently-popular language or toolkit.
Anyway, our job is to offer the most value to our users, and reducing RAM consumption by 3% or even 5% (of available RAM) is usually not where you'd find much value.
True but my point stands it's not Covid anymore. We don't need to build everything for the browser and talk through Zoom because it's easy for people who never use screen.
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.
I had just about the opposite reaction. As in "hey are we in 2000? nice!" Like back when you couldn't much afford to have stupid bloat and there was much better attention paid to "just do the thing and nothing else?"
First time I see a software licensed with the Unlicense.
I thought it meant the license was missing on GitHub but, no, it's an actual license called the Unlicense.
But then there is the Community and Pro edition so which is which on GitHub? Is the pro version hidden somewhere?
Plus a c++ code base in 2026. I think modern c++ can be made quite safe but I need some claims that it's taken seriously which I don't see.
I'm confused.
edit: I'm getting down voted here and no-one is telling me what I said wrong. These are my first impressions on the project. I think it's valuable feedback. Please reply and explain why I'm wrong instead of just down voting.
I often want click a part of the wall of text (from agent) and search for related text, open them up on the side or so. I want to open a linked file. I want to answer multiple questions in an async manner, even come back and continue answering the next day.
There are many prompt level features I want too - orchestrate with subagents, but only the tasks I select - how do I select when there is no checkbox. Or maybe delegate a subagent to dig into (read only) one portion of the chat response. Maybe codify (write) only one task in a list of tasks. So many many other small things.
As a full-time user of coding agents, the TUI barely works for me. I think splitting text, searching in text, merging text are more important in agent driven development than ever before. It is all text, all the way. This is what I am building myself, with my own gui framework.
Honestly, I just don't get the TUI obsession, other than the fact that people are multiplexing many remote sessions over ssh. So my aim with juggler was to have an architecture that could do all the multi-client remote sessions with a GUI/websockets/Y.js sync etc.
Where Claude Code and Codex have made progress recently, I feel, is with sharpening the interactivity. For example, Codex will emit a lightweight ream of "thinking", then on completion it will erase this and only show the final, coherent answer. It doesn't show much detail about which commands it runs, either. You can still drill into that, but it's usually the least important thing. Claude also does sub/side-sessions that can talk to the other sessions. So if a session finds an unrelated, pre-existing bug, it can start an adjacent session for the bug fix, and keep abreast on when the fix lands. If you start a side session to do research, it can message the other session with new findings.
I don't know if Juggler is still like it was, but I strongly recommend making it less verbose. I just couldn't deal with the noise.
TUIs can be run on minimal VMs that lack window systems. Using minimal VMs rather than heavyweight VMs allows a dev to run more VMs.
Do you not sandbox agents on VMs?
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/
On looking at Prospero it's ... simpler than this is so maybe not robust enough for your wants.
Agent UIs are all markdown, HTML, big scrolling lists, text flow, unicode chars, and all the other stuff that C++ frameworks are terrible at, but which is a doddle in HTML/CSS/JS.. You are a brave man!
This is very interesting. I know that coding string-related stuff with C/C++ can be incredibly tedious and error prone (even hard security-wise). But all the stuff in the web-related stacks/libraries in other languages, is either already somehow being transcompiled to C to execute, or could be relatively easily ported/reused by directing an LLM/agent to do it
Do you think that could work to make C/C++ better at this? What things would you import/copy from elsewhere?
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.
> 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.
I guess this is the main issue. Either you end up reimplementing a browser (which will def have a ton of issues), or you embed a browser and you end up with bloat anyway
Many times, while they are doing something, I’ll be typing a prompt, and then all of a sudden I get a question with Y/N options, and by accident, I’ll type Y/N as part of a word thus “answering the question”, many times either steering in the wrong direction or stopping the agent
Neither Claude code nor Codex solve this. The only way I’ve found to prevent it is to type somewhere else and then paste, but it’s super annoying
Edit: ^^ the above is especially annoying now that Codex popups the prompts/questions within other agents' sessions
Also, when I want two agents in different sessions to talk to each other, it’s kinda janky, I have to talk to both and act as a messenger for a couple of turns before they properly coordinate. I wish I could just sort of click somewhere, and link unlink two or more sessions
Does Próspero solve the things above?
Any pans for “swarm”/group control of agents?
But I don’t think you have it always listening, you probably tab the space bar to talk and send a prompt, walkie-talkie style, push to talk
I did mine as well and that takes 4% the resources of opencode and in a similar tui style.
I think it's great and everyone should make their own.
What's yours called? Is it also open source?
[0] https://github.com/caudra/caudra
Do not worry about vendor lock-in. Standing against big corporations was never easier in this century.
Do it. You know you can.
At least that's what I'm using in https://beolis.com (so, you can use the actual harness you like and just have a proper UI to manage agents over it).
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.
Whether and under what circumstances they actually enforce this these days, I do not know. Regardless, if your preferred harness does not support that authentication flow (which most don't), then it doesn't really help you even if you could. For what it's worth, I do not consider the Claude Code ACP adapter an adequate solution.
Way to cause confusion.
This is like starting a new country and calling it France.
Some feedback but it might be worth calling out how your harness differs from other relatively light-weight ones like Pi. I assume its got a much smaller memory footprint given yours is C versus Pi's. There are so many agentic harnesses out there that a comparison table might be a nice thing to have on the landind page.
Note: Just to be clear, I'm not accusing you of trying to hide it, given that the GitHub account for Hax is basically identical to your HN account.
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.
And of course, “lightweight” does have a lot of interpretations where harnesses are concerned (memory footprint, binary size, performance, system prompt, etc).
Feels so much better, so lightweight. Compiles instantly. Almost no dependencies. Like something Suckless would make. And unlike all the rest, runs easily on OpenBSD.
And as minimal as it is, it even has nice features like showing me after every prompt how much that last task cost me.
When I saw the post here about a new coding harness, I clicked in thinking, "Could anything be better than Hax?" Still no.
Oleksandr, I'm a fan.
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.
But I don't like how opinionated it is: "Therefore Prospero prime design principle: Never wait forever. Every operation has a deadline. This decision influences everything."
I respect that opinion, but I don't share it, and therefore an entire coding harness developed around that opinion is not helpful for me.
Love to see such a strong tasteful take on software heralding back to the age of solid desktop apps.
But I will agree besides intentionally choosing C++ for a project presumably written by an agent, this project does look nice and thought out
App-server protocol: https://learn.chatgpt.com/docs/app-server
Opencode: https://opencode.ai/docs/server/
GUI in your browser. Tiling window manager.
How come?
They want you to use and get accustomed to only their own tools. If other coding harnesses were allowed, it's far too easy to switch providers.
They can't allow that, because they only have a few months of head start.
So everyone accepts Claude code which is required for these sweet subsidized tokens.
> Unless previously approved, Anthropic does not allow third party developers to offer claude.ai login [..] for their products.
ref: https://code.claude.com/docs/en/agent-sdk.md
Yes there is a huge gray area. Yes people are getting away with it. That does not mean it's allowed. Anthropic could clarify their terms any day and they don't, on purpose.
Claude behaves in Claude Code somewhat differently vs other coding harnesses (sometimes it's a remarkable improvement) connected directly via api. Also, it cost more than the subscription. There's quite a bit of baked in tooling and assumptions in Claude code that may be good for you, or unhelpful based on what you are doing.
T3 does it this way.
Reading through the whole post, this sounds like an thoughtfully and intentionally designed product. One with strong opinions and the developer’s real lessons behind it. In the current era of slopware- especially around AI tooling - this is giving me damn near an emotional reaction. I am happy to see this.
I dont know if i am unique here but i often work in exploratory mode where i persue a chain of thought in a specific direction, then backtrack up and go down again arbitrarily.
But right above this statement, on the Professional Edition purchase page, it says its only for Windows and Mac..
and
FIVE megabytes. Wow. What are we doing everywhere else.
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.
Because that's not what I said. My point was more that a "1000% memory inflation" is not a meaningful cost metric to begin with (to use just one toy example, perhaps you'd agree that going from 10% RAM to 100% has a very different impact than going from 1% to 10%, even though both are a "1000% inflation").
Memory (at least on a personal computer) is not rented by the hour on a per-MB basis; you buy it in bulk. What matters isn't how much memory you could have used but what you'd use the "saved" memory for. Also, when you buy a resource like RAM or CPU as a package, nominal values matter less than under what conditions one of these would reach 100% and your experience may be degraded.
For example, if you have 16GB of RAM and you only ever run one program at a time, it doesn't matter to you at all if it uses 3GB or 3MB: you've paid for 16 and the total savings of the 3MB app are zero and in this hypothetical case, there's no tradeoff at all. Now, the average user on the average hardware doesn't use only one GUI app at a time, but they're also not using 200. The only relevant question pertaining to waste is what is the value of 3% memory to your users (integrated over all of them)? In many situations (again, not all), the answer is not much. (And BTW, some developers seem to care about 3% memory more than they do about 3% CPU, even though CPU is much more expensive).
When it comes to agent harnesses, the analysis is clearer. On the one hand, people using coding agents are more likely than others to put even a little extra free RAM to some good use, but on the other hand, the cost of using the models themselves is so high that it makes the cost of RAM for the GUI negligible.
Saying that a number going up by 1000% is bad is not good engineering. Good engineering requires thinking about the actual value and cost of that number. It varies over time, over app type, over different types of users, and over different kinds of deployments (i.e. how RAM is packaged and paid for).
I'm entertaining this nonsense because I want to clarify, that I use a 20 year old web gui and it consistently eats 8 gigs of ram in Webkit because it uses CSS to update the forms. Webkit is the only option on iPads and yet it can't handle a 20 year old website because it doesn't do things in the standard ways. It's ridiculous to say "why doesn't it target web" especially after someone presents new coding harness that went out of its way to run well without it.
No, that's not the conclusion. If using models costs you, say, $10 an hour, and a GB of RAM costs you, say, $0.0001 an hour, then clearly you shouldn't spend your time on reducing the insignificant cost if you want your work to deliver the most value to users.
But again, "less RAM" is more or less meaningful whether you're reducing the RAM usage from, say, 5% to 1% or from 80% to 40%. The latter is more valuable even though it's a lower relative reduction. That's because what the users care about is in what conditions they reach 100% of either CPU or RAM, and the second 2x reduction, therefore, offers more value than the first 5x one. This is similar to how a 10% discount on a car offers far more value than a 99% discount on a pack of chewing gum. This is still the case if you're buying 100 packs, but maybe not 10,000, and the same goes for software: it may also matter how many copies of the app the user is expected to run concurrently. The point is that you can't assign a value to a 10x reduction if that's all you know.
> I'm entertaining this nonsense because I want to clarify, that I use a 20 year old web gui and it consistently eats 8 gigs of ram in Webkit because it uses CSS to update the forms.
And I'm entertaining this nonsense because you're clearly not a very experienced engineer and you may learn something. In the ninetees, when nearly all GUI apps were written in C or C++, we had plenty of examples where a C++ GUI app consumed 50% RAM. That doesn't mean that C++ is worthless, only that some software has serious resource bugs, and it sounds like that web page you're referring to is a case of that. Most web-based GUI apps today do not consume a higher portion of RAM than their C++ counterparts did 30 years ago. Today's browser-based MS Word consumes less (relative) RAM than the C++ version did in 1998, and it certainly has a far smaller negative impact on concurrently using other apps on the machine.
And, of course, there are buggy/leaky programs now just as there were then. It's silly to say that the existence of such programs means that the approach is bad, because that would apply to any sufficiently-popular language or toolkit.
Anyway, our job is to offer the most value to our users, and reducing RAM consumption by 3% or even 5% (of available RAM) is usually not where you'd find much value.
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.
Can't wait to try it.
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.
I thought it meant the license was missing on GitHub but, no, it's an actual license called the Unlicense.
But then there is the Community and Pro edition so which is which on GitHub? Is the pro version hidden somewhere?
Plus a c++ code base in 2026. I think modern c++ can be made quite safe but I need some claims that it's taken seriously which I don't see.
I'm confused.
edit: I'm getting down voted here and no-one is telling me what I said wrong. These are my first impressions on the project. I think it's valuable feedback. Please reply and explain why I'm wrong instead of just down voting.