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!
But the architecture is such that this core functionality is just a plugin, and anyone can write their own custom approval filter plugin, and make it do whatever you want
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...
However I see all those people out there trying to build these huge agent orchestration schemes, and if juggler's extension system can do that (or could be made to do that with a few tweaks) I'd be really interested in helping that to happen
But with regard to Juggler and orchestration, have you seen "claude agents" (started in the terminal as claude agents instead of just claude). I ask because your tree like approach has similarities to how claude agents manages claude agents/subagents doing tasks with the ability to drill down in to each at a time which is why for me its not such a leap from what you already have.
~~edit~~
wait, are you doing that? Love JUCE btw
Another really elegant thing that pops out of subthreads is that to do a compaction, you simply move the entire conversation into a subthread, and let the subthread summarise itself (which they do anyway). So we get compaction as part of the architecture, and you can also dig into that old thread if you need to revisit any of it
If the off topic messages change files, then it's a bit more complex.
Say you're studying something: STEM topics, Liberal arts topics, a codebase, a textbook, etc XYZ. You're in the flow of discussing a main topic. Invariably, the main topic is built on top of atomic subelements. For example, discussions about Bonds invariably invoke discussions of Present Value, Yield to Maturity.
The branching is because you have a side query that is a potentially unbounded stack of "wait, but why this?" You highlight a segment of text in the current chat, click a button that pops a new conversation over to the right, and continue your "related but off-topic question." You have both context threads in view at once: the main topic & the side topic. You should be able to do this N layers deep.
The alternative is that you get to play scrollbar warrior in the current regime of LLM-designs. It's not really conducive to deep understanding.
This kind of conversation applies naturally to software development too: "wait, so we're working on feature X/refactor X/bugfix X, but that requires us to answer this subthread. And sure these days Claude Fable can probably do it all with the right harness, but does that mean you _understand_ what it just did?
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?
Surprisingly, I've really enjoyed the experience. I have friends who lament that they probably won't be hand-writing code much more, but although I've always loved the craft of coding, I discovered that a lot of the fun I get is just in the end result, not how I got there.
Why is that, can you elaborate a bit?
Also one question about economics of writing such tools using AI - How much it costs you?
PS: It looks great, I want to try it today :)
I guess personally I spend just over 100/month on LLM subs
Yeah, I guess that will be the future. I'm not sure if its a good thing or not. I hope it will not affect my job position.
Last question, which LLM provider you use and the model?
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.
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.
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.
To my understanding, Juggler is a frontend to your agent and would replace your editor. That's the selling point I got, a better UI than text for orchestrating your agents.
ACP servers are agents (like if you look at the spec you have to implement an entire agent's worth of endpoints, from creating sessions and sending messages to handling starting MCP servers the client specifies).
I don't get the sense that the point of Juggler is to make the world's best agent (rather it's to make the world's best interface to agents), but OP would know way better than me.
What you're describing sounds like an ACP proxy, which probably exists but is a different class of thing.
If you just want to drive OpenCode via Juggler rather than your text editor, you also want Juggler to be an ACP client (it can be both an HTTP server and ACP client, I have some stuff at home that does that).
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?
But TBH for most smaller tasks I tend to create a conversation, do a linear task, and bin it.
Because a plugin can also use the sub-thread system, maybe people will come up with some interesting uses for them that I haven't thought of, my own use tends to be quite simple!
One more question around yDoc and remote access if you don't mind. Do you have thoughts on a tool like this for "LLM pair programming" or just general collaboration?
Working with teams on smaller projects with these tools is really hard because anyone can build anything. If I'm going to type up a bug or request to send to a team member to build I might as well send it to the LLM instead. A multi-user environment in a tool like this could be interesting. Seeing team members sessions in real time could be neat.
It'll certainly let multiple people share the same live session, so that tab list would act pretty much like a live shared kanban board. If you're all happy working on the same folder at the same time, then that would work! I guess that just by adding something like per-tab worktrees it could actually be a pretty good team server.. hmm.. Hadn't really looked at it like that yet, but that' interesting
For some more unsolicited feedback: if that's how you use it why not pitch it that way/ make that way of working more obvious? Bug tracking and todo's jump to mind for me. For example: I want to write a prompt to fix this bug at some point but I need to think more about it. Right now I just need a place to jot it down for now so I don't forget.
Re: collab - managing edits and other state (builds/lints/test processes) is definitely a tricky problem. "Frictionless" worktrees is an interesting idea. That often seems like the "right" solution for how I'm working but it's too annoying to do for smaller changes. Doing that well would be a reason for me to give this a try.
And the collab side of things I'm only just now really having space to start pondering.
``` 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.
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.
Ta for the heads-up, I'll tweak the website!
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.
Edit: seems like the remote connection feature may not work...
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.
I've kind of followed the claude model where you have to give it a project folder, and at the moment I've made it so that it has one project/session per window.
I'm pondering whether to let a window contain tabs which each have a different project folder.. this would be easy to do, but feels somehow messier. Opinions welcome on that.
And yeah, I need to make it scan for skills - it's probably an hour's work to implement that, just haven't had time to do it yet! Probably will be done this week
I definitely wouldn't use any coding agent, GUI (yours included) without my skills. They are where most of my effort has gone, and what make the session effective. Without them, I'm spending a lot more time hand-holding and re-doing work with the AI.
So I created a system that seems a bit opposed to yours, or at least I'll take inspiration from you and probably update it. It's an overlay that I can resize, and an accompanying web view, of all my running coding agent terminal sessions. I can find old ones too, but mostly I want to know when something finished running or if it's waiting for me on something and if so what. It's not published anywhere but if you want to try it or see screenshots I can share.
I really like how easy it is to verify exactly what happened on each tool call, inspect the thinking blocks, etc.
While I've put huge effort into things like its architecture and extension API, it's really trying to just build a lovely UI/UX that has been my motivation on this.
I've settled on JUCE as my cross-platform app framework (not just plugins) of choice, so it'd be interesting to hear about your experience with building this app out .. could you tell us a bit more about the architecture and any impactful decisions you made along the way with regards to tooling/integration? Is there now a juce-go-module or something like that, which you've wired up to JUCE' web view functionality?
There's no c++ in it, it's all Go/Javascript. And all the UIs are HTML. JUCE is a great choice for some things, but this wasn't one of them!
Well, my first run wasn't very pretty .. installed it on a MacBook Air M5 with 16Gigs of RAM, set it up to access the local ollama instance (because I'm cheap like that), gave it a local JUCE app with a prompt to "analyze the project for issues porting from 32-bit to 64-bit" .. plugged in the laptop as it started processing, and then the system froze. I guess Juggler doesn't like display/USB enumeration events while its busy having ollama chug up all the resources .. well, that produced a system crash .. so came back, set it all back up again, and was .. after a few minutes .. told "the 'ls' tool is not available on this system" .. hmm .. I guess I might have missed a few setup steps in my rush to get it cranking on my JUCE project ..
In any case, will tinker with it some more, looks really great and a nice way to organize AI into a functional UI - especially better than some of the other things I've been using lately (hermes, mostly..) ..
[edit] sorry - misread your post. It basically does the exact same thing that the Agent SDK does, so is equivalent to using it (but being Go, I couldn't use it directly)
Another VPN: $ [ERROR] computeProviders: list models from gemini failed: failed to list models from Gemini: HTTP 400
Got fed up with Zed, Cursor, and the other GUI agentic tools and created a console TUI agent for my own use.
But TBH I think a lot of the GUI agent tools so far have been pretty much terminal apps wrapped in a thin GUI layer, which is why they don't seem to add any value over just doing the same UX in a terminal
Thank you for building this!
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.
I come from a hardcore, real-time C++ background and the idea of a product not being a single self-contained binary is just too far for me to go!
(But I don't think the choice of JS back-end should make the slightest difference to anyone using this. I could swap electron in there in the future and probably no-one would notice)
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!
PS: I agree that tree is a better approach than scroll chat, and other ideas Juggler has.
I mention all this to say someone like you picking up the desire to build an agentic platform really piques my interest. Right now I am using Opencode for most of the stuff I am trying to do at $WORK and it does a good job on the whole at having sufficient functionality. But the release pace is blistering and it does feel bloated - both in terms of functionality as well as system prompts.
Moreover, I observed all of the same issues you mentioned and certainly wanted more of a tree like experience as well as a more UI forward experience. In order to get the functionality I wanted (good worktree support, sandboxing, etc) I eventually just had to let go of using opencode's UI and embrace the TUI because it was the only thing I could embed into a workflow that let me set up all of that in a sane manner. But problems still remain with the "doom scroll" experience when to your point clearly a tree based experience would be better.
I was ready to just settle with my cobbled together opencode flow and maybe migrate to Pi later on and just accept i'd have to roll my own GUI harness for my nontechnical team members. But seeing what you've put together so far (and knowing it's you who wrote it so I'm probably going to just see a step function level better quality in architecture/efficiency) is going to make me reassess in a good way. Some things that I'll be considering:
- Worktree support
- Sandbox support
- Skills/subagent handling
- Hashline based editing (feel like this is a huge part of why people get better results from pi/omp over opencode/codex/claude code)
- Ability to customize tool calls + have rich embeds
- Web UI support (if i'm building this out for team members, native GUI can get messy and web client is ideal)
- Long horizon efficiency (IE i regularly get to 200k-400k context length sessions; while the model handles it fine, opencode gui will get laggy while the tui keeps chugging along)
For a lot of this stuff, it's less critical that all of this works perfectly out of the box and more critical that the architecture makes it easy to build (ie as with Pi ecosystem). What I'm after long term is something a bit like https://github.com/ColeMurray/background-agents in capability but without the overly tight coupling and design decisions that product has made.
The way I want to get there is to find the right base (whether that's Pi, OpenCode, or your project Juggler) and build the background agent harness layer. Previously it was just Pi and OpenCode and neither was really perfect (GUI story was probably the weakest for both) but it's great that I have another option to diligence that might actually be a better fit for what I'm trying to do.
Excited to see how this develops and kick the tires on it myself. The tree paradigm feels like the killer feature to me; not sure of anything else besides pi/omp that has it.
I've got things like worktree/sandboxing/skills on my TODO list.
I'd heard of hashline based editing - I will dig into that, and it's probably easy to add, though TBH I've not had any hassle with the editing tools so far.
If you get stuck into customising tool calls + their UIs, would love to hear how you get on, as that's one of the big goals for this. I've implemented all the built-in tools as plugins so hopefully it'll cover everything you need.
In terms of long-horizon stuff, yes, I also often hit 3-400k and haven't had any issues, but let me know if you spot anything untoward
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.
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
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.
Where I've found editing to be the most useful is e.g. when I've had a long task that got a bit rambling and digressed, and then I go away and need to resume it later. Leaving it means the provider will have lost the cache for it, but rather than spending a lot of tokens to /compact or just to continue the entire thread, you can go through and delete all the useless bits, maybe just leaving enough content in there for the LLM to figure out how to continue, and then get back on track quite cheaply
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.
So I've just made it so they don't inherit! If we find a situation where inheriting is useful and safe, it'd be easy to add again.