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!

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)

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.

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.

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"

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.

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.

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

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..)

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.

> 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.

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

- 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.