As this post gradually sinks downwards on the HN front page, I'd just like to say thanks to everyone who've made all the lovely comments, it's great to get some feedback to show I haven't been wasting my time building this!

And as I said, this whole project was 100% done by me in my spare time, with zero money behind it, and no real plan for what happens to it now!

If you like it, please spread the word, as I don't have a marketing budget! If it manages to get a big enough userbase then hopefully I'll be able to figure out some way to make it a full-time gig, as it's been really fascinating to build!

This looks really interesting and a unique take on the AI agent orchestration. I think we need a bunch of experiments in this area as it's clear we are entering a new paradigm and the tools for it are lacking. The session tree in particular has merits.

I've got my own attempt with OrcaBot (short for orchestration of bots). It's also been a 6 month solo build experiment. I'm not trying to plug.. just that I'm also neck deep in Steve Yegge's Stage 8 AI-assisted coding chart and understand how much thought and effort went into this.

Thinking about where this is all going with talking to AI like fully autonomous employees similar to @Claude can you see a comms app type approach that combines something like slack with your tree/thread structure? It's somewhat orthogonal to your "inspect everything" but could intersect by bringing click through/open in options...

> Using a code agent involves editing big chunks of multi-line text, and getting hosed with information that you need to scan, navigate, and understand. I find a terminal UX horrible for all those tasks, and Juggler is resolutely a GUI app.

Thank you for building software made for actual productive usage instead of weird ricer clout and other performative nonsense.

> Yes, it's another AI coding agent. The industry definitely needed one more.

It actually does need more of them. The current count of harnesses that don't suck is a float somewhere around 0.3, maybe.

Keep doing what you're doing!

I'd love to have software that is actually made to solve problems instead of somehow pretend-granting me some identity. Or just being made by people with no taste in general.

My god the agent harness space is so bad. As if no one in there has ever seen a software in their whole life.

@julesrms thank you for lending more credibility to the idea that agent conversations need to be natively branching. It's crazy that we're almost 3 years in on this LLM joyride and we still don't have the ability to do, like, reddit/slack-style "aside" convo threads.

~~edit~~

wait, are you doing that? Love JUCE btw

Miller columns rather than a big doom-scroll

Sold, this is my biggest annoyance with Cline.

Go backend, Wails for windowing (no Electron), plain type-checked JS (strict JSDoc), Yjs for the documents. Usual BYOK provider support: Claude (CLI or API), OpenAI/Codex, Gemini, Ollama, OpenRouter, DeepSeek, etc.

Double sold

As a longtime sound engineer I'm pretty familiar with JUCE and your other productions, so I will be trying this with confidence.

This looks cool! I'll check it out. Out of curiosity: I assume you've also used agents to help build this, and on the site you mention working on this for ~6 months. Most one-man projects I see that use ai seem to focus on creating and presenting a concept as soon as possible (to a lot of people I think the main benefit of stuff like vibing is that you really quickly get something that you can have others test out).

On the site you also mention being pretty opinionated about the tools you use / build, which I imagine is part of the reason why you spend more time on this before releasing it. What was your experience using ai to build a larger project with a very specific idea / taste in mind?

Very interesting. I tried to make a tree based agent two years ago but back then the LLM couldn’t manage to navigate the tree effectively. But today everything is different: better LLMs, and we have better understanding on how to instruct them.

I’ll try it and maybe I’ll be inspired to make my current home brewed agent more document focused again.

One drawback is much higher token usage because we get a very good saving in the cached data.

A little heads up: in your web page, the header download button force double screen with on mobile (iPhone 17 pro). No big problem but always an annoying when a page scrolls in two directions.

ACP support would be a big deal and would make this a real contender for me. It looks super nice, but the idea of re-writing my Pi plugins is a real blocker.

I’m generally happy with my agent and want to keep that, but I do think the UI could be better and this looks like a neat step that way.

This looks nice, and I like the more opinionated take on how "communicating" with an agent should work.

The post talks a lot about what this is and how it works. I'm curious, from your usage of it, how does it change your way of working with the LLMs? How does working with it go differently from Claude Code?

Specifically: Everything is a tree. That's interesting, but how do you end up using it? Attack the same problem different ways?

I always like testing out new things to put into my workflow. the first thing I will say is that its a welcome change to have an app 40 MB rather than over 400

Nice to see people wanting to strike a balance between automated AI and staying involved. I have been frustrated by push to fully autonomous long horizon agents because the lack of course correction seems to burn tokens with worse results

> Because it's a CRDT behind a local web server

I think that’s the secret to stability. I see too many projects that try to embed the harness into their UI. I think that’s completely wrong because it leaves no interface for changing or reasoning about the system.

The harness needs a lot of love and it should be as small and as possible (at least somewhat). I dream of a world in which we have some standard interfaces here, including for the UI.

Really glad to see an harness other than Pi that seems to be non-vc-backed FOSS and by a competent maintainer

Edit: seems like the remote connection feature may not work...

Mmm I added my Gemini Key and selected the model, but the Add Provider pop-up keeps appearing. In the Default Model tab it says: Provider is configured but has no API key. EDIT: it seems I have having network issues, the model selector in the chat input says it could not load models and yeah, now aistudio is also not loading.....story of my life hhhh EDIT2: not sure whats going on, my connection is back but now the Provider API key tab in settings is completely empty...

This is really nice, thanks for sharing! If you don't mind a little feature request, I'd love to have a "thinking level" selector on the GUI for models that have it.

I really like how easy it is to verify exactly what happened on each tool call, inspect the thinking blocks, etc.

UI is clean. could install in Mac. Adding context files at the top is clean. It worked. Currently I use zed, vscode (for UI). along with claude, codex, Hermes. Not sure If I will continue to use. But I see it is a clean and good UI, and integrating to my exiting cli's. All the best.

This is a product I have wanted to exist for quite a while, and tried to create myself, but lack the skill.

Thank you for building this!

Nicely done! Would you consider adding an Agent SDK login for Claude for those who don't have an API budget and want to avoid potential issues with Anthropic's capricious policies around CLI use in third-party apps?

Nothing to say regarding this release, but thanks so much for creating Tracktion (first DAW I ever used back in 2006) and JUCE (I love and use many audio plugins created with it)! Have a great day!

Great work, it is very funny that I did just the opposite :)

Got fed up with Zed, Cursor, and the other GUI agentic tools and created a console TUI agent for my own use.

Could you include screenshots on your github page?

Looks cool, I am also trying to figure out how to enhance the CLI user experience but on web with cloud gpus

I thought "Wails" was gonna be short for "Wuby on Wails" lmao

Cool project actually, but I noticed the author said "No Electron" as if Electron is synonymous with JavaScript.

My biggest concern about it actually is using Go to render web front-ends in HTML/CSS hahah so I'm not sure "No electron" is selling me.

With codex & Claude, I bearly used any of other IDE even for an indie mobile developers, I have not open xcode for ages. To me, any IDE to build project will be just a chat in LLM.

Why not use JUCE for UI? :)

Sweet! I was just looking for something like this, this past weekend. Lots of command line stuff, but not much in the way of GUI apps. Excited to check this out! Thanks!

Sorry but it's not real BYOK to me as there is no UI/method provided to modify the providers, instead the app provides limited provider list and only allow custom API keys. I personally have a big list of providers under a CliProxyAPI service for easier management working with multiple coding agents and multiple serious or experimental providers, so I combine them whatever I want to have different experience, also much easier to work with so much API keys.

For example, I have my codex pointing to the CPA endpoint and the actual running model is a openai compatible one from an specific provider with specific base URL. I hope this could be considered add into roadmap.

Hey Jules! This looks awesome, excited to check it out :) Hope you're doing well! Tom

For running headless is it possible to not require installing libwebkitgtk-6.0.so.4

Is this using ACP?

> Wails for windowing (no Electron)

Awesome.

> AGPL

Even more awesome.

Just wanted to add a follow-up to what I posted above..

In terms of who might be interested in this: I've watched amazing communities spring up around open agents like Opencode and Pi. People are getting into those because of their extensibility and being model-independant. They're great projects, but like many people I know, I really hate being stuck in the terminal for this kind of tool. I also had some ideas around what an agent's UX could be like if every item in the context was a plugin (with its own custom UI).

So I guess if you're a claude/codex user but want to escape the terminal (and let's face it, their GUI apps are also basically the same UX as a terminal but with nicer fonts), I'm trying to do something different here, would be really keen to hear what the enthusiasts think of it!

Does it support sandboxing?

It's a clever name, but I'm not seeing from the screenshots how it will help me juggle the 20 different projects that I've got going on, each with four or five tasks on them.

Having now given it a quick spin, I like the UI concept and could definitely see myself working with this. I ran into a bug(?) almost immediately though, I hooked up Deepseek 4 Pro, gave it a small task and got this

``` LLM error: POST "https://api.deepseek.com/v1/chat/completions": 400 Bad Request {"message":"The `reasoning_content` in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"} ```

I'm unsure about putting my Anthropic key in there as I've lost track of what they ban you for or whether that eats money from outside of my subscription.

Oooh, and nicer support for codefences would be good.

Seems to work when I click the juggler.app in Ubuntu 24.04 (Noble Numbat) GNOME's desktop. Running same app via terminal does not launch the app. Appear to be a sandbox issue common in Noble Numbat. In this case, WebKitGTK's sandbox failing to initialize properly via bubblewrap.

Jupyter-rtc is built on y.js too.

There's a sqlite CRDT: cr-sqlite,: https://news.ycombinator.com/item?id=41921992

vlcn-io/cr-sqlite: Convergent, Replicated SQLite. Multi-writer and CRDT support for SQLite https://github.com/vlcn-io/cr-sqlite

Notes on sandboxing agents: amla sandbox, agentvm, bwrap at least; debugging mcp servers, and signing agent traces in a standard format: https://news.ycombinator.com/item?id=48893850

--

Can juggler: Design and verify a guitar effect pedals and a wavetable synth with JUCE on a low power chip?

JUCE on embedded controllers; Rust embedded RTOS-like features, a DSP and low power draw:

> Ambiq Apollo4 Plus | ARM Cortex-M4F | ~4–10 µA / MHz | more efficient than an RP2040 Pi Pico. The hardware FPU handles audio math at a fraction of the power footprint.

> STM32U5 Series | ARM Cortex-M33 ~110 µA / MHz | energy-saving modes, math accelerators (Cordic for sines/cosines), audio peripherals

> STM32L4 Series | ARM Cortex-M4F | ~100 µA / MHz | mature, ultra-low-power, robust I2S audio support, sleep state

grame-cncm/faust: Functional programming language for signal processing and sound synthesis / [that compiles to microcontroller DSP code, LLVM IR,] https://github.com/grame-cncm/faust

Then a Rust-based OS for microcontrollers; to isolate devices and device drivers from other processes;

I'd like to learn this too (so this is worth researching)

Rust packages for DSP:

embedded-hal, embedded-io, rand_core

Navigating the Embedded Rust Ecosystem https://www.theembeddedrustacean.com/p/navigating-the-embedd...

https://google.github.io/comprehensive-rust/bare-metal/micro...

hubris > Flash instructions already mention an STM32 F but not yet U or L: https://github.com/oxidecomputer/hubris#flash

Task: Add support for STM32U and STM32L to hubris

"Navigating the Embedded Rust Ecosystem" https://www.theembeddedrustacean.com/p/navigating-the-embedd...

The micro:bit has a speaker and something like a DSP and rust support, though it's not going to run JUCE and BespokeSynth ; kk Just rtic, cortex-m-rt, and nrf52833-hal (for micro:bit v2) might be sufficient but there's already microbit_bsp:

microbit_bsp is a board support package (BSP) library for the micro:bit v2 and newer: https://docs.rs/microbit-bsp/latest/microbit_bsp/

Another task; Develop and test a board support package for low-power chips for hosting effects from JUCE compiled with or like Faust.

But then contain agent sessions;

e.g. Hubris has no shared memory so audio streams must be shoveled over message passing

--

Back to agent sandboxing;

It looks like WebKitGTK uses bubblewrap on linux unless running in a flatpak, because flatpaks don't have permission to create namespaces so bwrap can't run.

Bubblewraplauncher.cpp: https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIP...

FlatpakLauncher.cpp: https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIP...

CF workers support nested agent isolates since 2026-03: https://blog.cloudflare.com/dynamic-workers/

dloss/awesome-agent-sandboxes: A curated list of sandboxing solutions for AI agents https://github.com/dloss/awesome-agent-sandboxes

Interesting. Just opened it up to use, while I had a codex terminal session running - my first instinct was to want to see my pre-existing open session in the GUI instead and be able to drive it in either spot. Is that something I can do?

Also when I opened a new session (in the Juggler GUI) at my root where all my projects live, my instinct was to navigate to a project directory first or to have it open there. Not sure how to do this, without changing the global setting for my projects root. That's how I think through claude code/codex coding sessions via the terminal wondering if that mental model is wrong.

I asked which skills it could access, and it turns out it couldn't access any of my global skills already - I thought that part would just work since it accesses my codex subscription. is that something you plan to add.

The "session is a document, not a log file" framing is the part I'd underline. Being able to inspect and edit the raw context JSON going to the model is criminally rare, most tools treat the context as a black box, and on long runs context bloat is the single biggest cause of the model quietly drifting. Making it inspectable and prunable is a real lever, not a gimmick.

The thing I'm curious about: once you branch, backtrack, or edit a node in the CRDT tree, how do you reconcile that with the model's linear context on the next turn? If you reconstruct the transcript from the tree each turn, does editing anything upstream blow away provider prompt caching, since the Anthropic/OpenAI caches key off an exact prefix match? That's the tension I keep hitting: tree-shaped editing is exactly what you want for control, but it fights the flat-prefix caching that keeps long sessions cheap and fast. Curious whether you just eat the re-cache cost or do something cleverer.

Either way, Miller columns over a doom-scroll is the right instinct. Nice work.

Love the "session is a document, not a log" model — linear scrollback is the worst part of long agent sessions.

When you fork a sub-thread, does the model get the full parent context up to the branch point, or can you trim what carries over? Context bloat across a lot of branches feels like the hard part.

Please ask your LLM Agent to replace all that JavaScript code with SwiftUI, or at least C++ with native graphic libraries for real native GUI performance.