julesrms

Thanks! Really nice to see that it's hitting the spot with a lot of people.

Thanks - that's really interesting feedback!

I guess my schtick with it has always been that I wanted to see all the hidden stuff that claude and others try to hide away inside their "made a bunch of tool calls" type opaque messages. And I've heard from other people who appreciate it for that reason, but really interesting to hear that you found it stressful! I'll definitely go away and have a think about that.

I did add a feature a few weeks ago which lets you toggle whether it folds groups of commands into a single summary item (in juggler style the column view works really well here because you can still browse into those groups and see the tool calls if you want). I've found myself not using that mode because I like to see all the detail, but your comment makes me wonder if that should be the default, and if maybe I should add other "less detail" modes.

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.

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!

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.

The big hoo-har about it earlier this year was because something (opencode?) was pretending to be the claude CLI and using the API that way. Anthropic made a fuss, then GPT said "we don't mind people using their own harnesses" and everyone relaxed about it, as long as the harness goes via the claude CLI and doesn't try to cheat.

You can use your claude subscription just fine in open harnesses!

I make one (https://github.com/juggler-ai/juggler) and it'll auto-detect and use your claude CLI. I use that claude plan for 90% of my work, plus a bit of GPT, I just prefer to do it inside a nicer, less locked-in environment than claude.

There's really no moat around proprietary closed harnesses, it's trivial to jump between them, but people need to be aware that it's possible!

As usual when there's a harness release by a billion-dollar company, I like to ride its coat-tails with a little plug for mine (https://github.com/juggler-ai/juggler) since my marketing budget is $0. Juggler usually gets a warm response from HN people because it's a bit more hands-on than most of them.

I'd be interested to hear whether the 'spec' stuff works or not. I've been pondering adding a plugin for juggler based on the fact that we're rubbish at writing specs: so instead, when you prompt it, it'd get the model to list the assumptions that it's making about the task. Then the user can spot and correct any incorrect assumptions, rather than expecting the user to provide correct specs. (Haven't actually tried this yet, just speculating)

I fully understand the merits of AOT vs JIT, I've worked on compiler tech, built JIT engines, and done lots of high performance realtime stuff for decades.

But if:

- we're talking about compiled code, where the compiler has already squeezed out all the low hanging fruit in terms of performance

- it's running some kind of external process somehow watching the data flow around in memory, and is figuring out what code is doing what. This is at best incredibly expensive, even if happening in parallel

..then the chances of actually finding useful micro-optimisations that are also safe to patch while running without changing the memory layout and messing up.. is surely pretty close to zero.

I can only assume that it's not actually native code, and they've built some kind of python JIT engine which is finding efficient replacements for chunks of common python, where it starts off so slow that even the massive amount of effort required manages to pay off in a long enough run.

If you don't have part of the source code, then presumably that's because it was compiled, and there is almost no margin left for optimisation over what a modern compiler will already have done. I've written a JIT where we squeeze out a bit of gain over static compilation by vectorising to the available SIMD size, but it's marginal in most situations.

You say "think libc" - are you suggesting they could dynamically recompile bits of libc and do better than LLVM's link time optimiser already did it??

What I assumed was that you'd run this thing on some test runs, as a profiler step, and create an optimised binary. But you say they expect to run your code through an LLM all the time!?

The idea that you could run your code through an LLM (which must surely slow it down 100x at least), and then find enough missed optimisation opportunities to make up for that slowdown is nuts! (Or I've just misunderstood the whole premise!)

Honestly, the places in programs where you can get meaningful performance gain (that isn't already handled by your compiler) is all at the high-level big-O level, and that doesn't require runtime inspection.

Sorry to be cynical, a lot of smart people seem to have built this.. but I'm failing to see how it's any better than "hey claude, here's my program and a profiling tool, go do your stuff"

Compared to Trump, my cat has super intelligence.

Bullies love to force people weaker than themselves do pointless acts like this, just to reassure themselves that they have power over them. I imagine that once enough companies have capitulated to this nonsense, he'll then decide it should become "American Intelligence"

Absolutely.. If I had a project with 30k commits per day (or even per month!) I'd be keeping that secret, not blogging about it!

30k commits per day on a console app?? Are these all one-line changes?

I've written a harness myself and fair enough, it's more complicated than you might expect.. but surely at this point the claude CLI is pretty stable, and this must mainly be a ridiculous amount of test churn.

Or maybe their team of clankers is just creating busy-work to make the humans think they're essential. That's not unheard of in the human behaviours that they're trained on.

They seem to be pitching something that pretty much all the decent models can already do..?

Obviously if your model is stuck inside a CLI terminal, then not so much. But in a GUI harness (shameless plug for my own one: https://juggler.studio, but I assume others can do this too), you just ask them to answer in HTML and they'll happily draw pretty pictures inline in the conversation. I've been doing this for ages with claude, GPT, Deepseek and others.

Don't know if you'll ever see this belated reply, but you can now:

`brew install --cask juggler-ai/tap/juggler`

> You don't care about the little things

I wish that was true!

I'm not a cowboy arbitrarily making up random shortcuts. A major goal here is for a user to get near-as-dammit the same UI in a desktop app and in a remote browser. So all these shortcut choices have been a compromise between:

- what different people might expect the default to be (on mac/windows/linux/all kinds of apps)

- what a browser already uses (on mac/windows/linux/chrome/firefox/safari/etc)

- what people might have overridden random window managers and custom OS shortcuts

- what tasks are common enough that they deserve an easy-to-reach/remember key in spite of other factors

- choosing groups of shortcuts where you want the keys to be related (e.g. navigation) despite some being taken on some platforms

I obviously want the least surprising UX, and if this was just an app on one platform, it'd be easier. I've had to build a multi-platform shortcut manager that changes depending on the client, while trying to also keep as many as possible constant.

And yes, allowing users to customise the shortcuts is obviously on my list, but a) I wanted to let the app settle in and make sure I've got the right data model for storing key shortcuts first, and b) other more urgent features..

BTW `cmd+/` is the default "show the key shortcuts" in most chat environments like discord, slack, teams, google docs etc. These are much more relevant to juggler's UX when it comes to default shortcuts than things like VScode!

(...but yes, I had forgotten to add a desktop-app-only binding for `cmd+,`, so thanks for mentioning that - I've sorted that out now..)

You can connect to a juggler session from a browser on an iPad and get the full GUI on there. (Also from a phone, but although I've done my best to cram the UI into a mobile screen, it's a bit cramped)

An iOS app is on my roadmap, and pretty easy to do, because the whole GUI (including the desktop app) is just HTML being served, so shoving that into a mobile app is pretty trivial.

I mostly use claude and GPT for real coding. Because I need to test lots of models I've also got GLM and Deepseek accounts but they're really not yet up to the level where they compete with the frontier models in my experience.

> Can it also be used with pi and other tools?

You might use it instead of pi, or in addition to it. Juggler and pi are both harnesses, not things that work toghet.

Thanks - it sounds unlikely that a harness could do much to prevent hallucination, those smaller models are just way more random in their behaviour.

It's not just text, it's structured text. It often contains tables, sections, lots of things that can be drawn much more nicely.

And in juggler (and probably other harnesses too) the LLM can reply in HTML. So if I'm planning e.g. some UI changes, I might ask it "show me what this button will look like" and it'll reply with a picture of that thing in its response. No temp files to open or clean up, and fewer tokens burned

To answer your question about what I was trying to do that was different:

- a multi-client, state-machine based architecture rather than a naive LLM loop

- a bunch of UX features that I wasn't seeing in other harnesses (although of course they're all churning away in terms of UX so this changes all the time)

The difficult bits were:

- getting the data model right. This was a lot harder than it looks!

- getting an automated UI test framework in place that was robust enough to trust that incoming changes wouldn't break something. Originally I hoped to get away without this (I've never worked on a project before where we had automated UI tests!) but it was just a shitshow. I spent a couple of months getting this right, but it turned the whole project around and it's now incredibly quick and safe to make changes.

Thanks! I've had fun doing little details like that. Will keep trying to make it fun..

FWIW, making juggler plugin based feels quite normal to me, coming from the world of audio software, where that entire industry is still based around many thousands of VST/AudioUnit plugins which run native un-sandboxed code in the host apps, with access to absolutely anything they want. And it's somehow all just kind of been OK..

I totally get it. Lots of people, like you, love to set up their perfect custom, key-driven environment, and tune everything just how they want it. These tend to be the TUI fans.

I've never felt that urge, I've always been happier using Visual Studio / Xcode / VScode with default key bindings, and focused on other things. I'd rather click things inefficiently with a mouse than invest effort learning keypresses. Neither of us are wrong or right, but I think I'm trying to cater for my tribe on this project!

I've specifically designed juggler to do exactly that.

You run it on some headless machine, and point your browser at the HTTP server it creates to see the full GUI. It uses Yjs to make that connection as efficent as possible, and it works great.

The desktop app is literally doing the same thing internally - it runs a headless server process and serves the GUI to its own window. But you can stretch that over a network and it's the same experience.

I can even connect to it via a TURN server, from my phone on a cell signal, and although it's not as snappy as running locally, it works pretty well.

Well juggler literally does that - you run it headlessly on some machine (docker, whatever), it opens a HTTP port, and you can control it remotely with the exact same desktop GUI that you'd see if you ran it locally. (The desktop app is actually just running a headless process internally and serving it to its own window via HTTP).

Thanks! Would be keen to hear how that goes for you - if you find anything that starts to bloat its memory use, let me know and I'll look into it. As a native dev, this has always been something I care about

I actually just released a tarted-up version today that looks nicer still. I need to update the website screenshots..

Hmm, that's interesting - I certainly had 'homebrew' on my to-do-list, but quite low down, but you make a good argument for making it a higher priority..