Yes, it’s another AI code agent. The industry definitely didn’t need one more. But this comes from someone who’s spent 30+ years building tools that C++ and audio devs actually use — JUCE, the Tracktion DAW, the Cmajor DSP language. And this time, instead of another audio framework, he built the GUI he wished he had in his code agents.
Juggler launched today via Show HN, and the pitch is refreshingly self-critical: the industry didn’t need another code agent, but the author built one anyway, after getting fed up with the CLI experience that most agents force you into.
The problem: your agent’s terminal is a doom-scroll
Every CLI-based code agent hits the same UX ceiling. You get a single linear transcript. If you’re lucky, you can rewind it. Sub-agents run invisibly, like they’re just another tool call — you can’t see what’s happening inside. Context compaction silently erases history you might need later. And everything — tool calls, approvals, the raw JSON going to the model — ends up buried in the scrollback.
Juggler’s answer is architectural, not cosmetic: your session isn’t a transcript, it’s a tree.
A conversation you can actually navigate
Underneath, a Juggler session is a Yjs CRDT document, not a log file. Any point in the conversation can branch into a sub-thread. Sub-threads can branch again, recursively. You navigate, inspect, edit, back up, and compare using Miller columns Finder-style — the root on the left, selected items expanding into properties and children to the right.
This isn’t just better navigation. It solves two real problems at once:
- Sub-agent visibility. When an agent fires off a sub-task (fetch a page, explore a code question), Juggler turns that sub-thread into a navigable, first-class part of the tree, instead of a black box.
- Compaction, for free. You move a conversation into a sub-thread and let it summarize itself — which is what sub-threads do anyway — and you get compaction as a side effect of the structure, with the original thread fully intact if you need to dive back in.
Everything is a plugin — even the basic tools
Juggler’s core just handles the document and orchestration. Almost everything else — context items (read-file, replace-text, bash, etc.), LLM loop strategies (plan, research, or your own), and slash commands (/clear, /compact) — is a JavaScript extension you can inspect, fork, or replace. Even the basic tools ship as plugins, not hardcoded behavior.
That’s the “workbench” framing: if you want a custom orchestration UI for your own workflow, Juggler is a platform to build it on, not just a chat window with extra buttons.
Model support
Juggler is explicitly not tied to a single provider:
| Provider | Access method |
|---|---|
| Claude Code | CLI or API |
| OpenAI | Codex plan or API |
| Gemini | API |
| Ollama | Local |
| OpenRouter | API |
| Z.AI | API |
| Deepseek | API |
BYOK in all cases, and the author makes clear that adding a new provider is straightforward enough to accept community PRs.
One session, many clients
Juggler looks like a native desktop app, but it’s actually a local webserver behind a live collaborative session — the desktop app is just one more client. A browser tab is another. A different machine is another. Run the headless juggler server where your code lives, and connect from the desktop app, a browser, or your phone, all seeing the same document in real time.
How to install it
Grab a build from the Releases page or from juggler.studio. Each download includes two pieces: the native desktop app, and juggler, the headless CLI server for long-running, remote, or network-accessible sessions.
macOS — download the .dmg, drag Juggler to Applications, open it. The app and server start together. First launch may hit Gatekeeper — right-click → Open → Open solves it.
Windows — run Juggler-<version>-setup.exe. Installs the desktop app and juggler.exe together, optionally adding it to your PATH.
Linux — download the server binary and run it from a terminal; connect via browser or desktop app.
To run it headless:
juggler # prints a connection URL and QR code
By default the server is localhost-only. Hit p in the terminal (or launch with --public) to enable LAN access — there’s no password in LAN mode, so only do it on networks you trust. Accessing your server beyond your LAN isn’t included in the open-source repo; that’s reserved for the official binaries from juggler.studio.
Compiling from source is one command once you’ve cloned:
git clone --recurse-submodules https://github.com/juggler-ai/juggler.git
cd juggler && make build
Stack: backend in Go, Wails for windowing (explicitly no Electron), frontend in HTML/JS type-checked via JSDoc instead of TypeScript, Yjs for the documents.
Licensing
The core app is AGPLv3. The extensions SDK and included extensions are Apache-2.0 — so you can build extensions, even closed ones, without copyleft obligations. No signup, no telemetry.
What it doesn’t have yet
It’s a single-person project in early beta, launched today, so treat it accordingly. From the HN thread: ACP (Agent Client Protocol) support isn’t there yet, though the author bumped it to the top of his TODO list the same hour someone asked for it. Sandboxing and worktrees support are on the roadmap but not shipped. Linux currently needs libwebkitgtk for the headless server JS execution. None of this is disqualifying for a day-one release — it’s just not yet a “download and forget about it” tool.
Is it worth trying?
If you’re comfortable with your terminal-based agent workflow, there’s nothing here that forces a change. But if you’ve ever wanted to actually see what a sub-agent is doing instead of trusting blind, or wished you could branch a conversation instead of losing context to compaction, Juggler is worth the five minutes it takes to download and point it at a project.
Has anyone tried it with Claude Code yet? Let us know how it went in the comments. 