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?"
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.
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 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?
Why would anyone aside from a C hobbiest want to use this? And what does terminal native even mean?
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.
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
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.
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.
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.
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.
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.
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.
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!
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.
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.
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 a very important part of engineering. More importantly, though, the use of browser engines for GUI apps isn't about JS, but about the browser engine, and 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 compromising on costs and presentation quality is often (not always!) a very reasonable tradeoff from a pure engineering perspective.
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.
56 comments
[ 13.6 ms ] story [ 563 ms ] threadApp-server protocol: https://learn.chatgpt.com/docs/app-server
Opencode: https://opencode.ai/docs/server/
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.
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.
But right above this statement, on the Professional Edition purchase page, it says its only for Windows and Mac..
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.
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.
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).
Why would anyone aside from a C hobbiest want to use this? And what does terminal native even mean?
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.
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
Do not worry about vendor lock-in. Standing against big corporations was never easier in this century.
Do it. You know you can.
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.
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).
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.
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
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.
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!