I'm a long-term C++ dev, and over 30+ years I've created some successful audio dev tools (JUCE, the Tracktion DAW, the Cmajor DSP language). All of these came from me getting annoyed with something I had to use, and deciding to have a go at my own take on whatever it was.
So Juggler is my attempt at an AI code agent, after spending too many hours loving what the models could do, but hating the CLI experience, and having some opinions of what a better UX might be for this stuff.
Lots more blurb on the website and github, but a quick tech dump which might grab your attention if you're into these things:
A session is a document, not a log file. Each conversation is a Yjs CRDT tree. It can branch into sub-threads (recursively), and you can drill down, backtrack, edit, undo/redo, and inspect everything: tool calls, approvals, and the raw context JSON going to the model, etc. The UI is based around Finder-style Miller columns rather than a big doom-scroll, and is quick to navigate.
Because it's a CRDT behind a local web server, multiple clients can attach P2P to a live session: the native desktop app, a browser tab, or your phone. Run the headless server on the box where the code lives, view it from wherever.
Almost everything is a JavaScript plugin: every item in the context (read/write/bash/etc.), the LLM loop strategies, slash commands, and their UIs. You can inspect, fork, or replace any of them. I don't do much agent customisation myself, but lots of people do, and I'd love to see what they think of with this plugin API.
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.
The app's AGPLv3; the extension SDK and bundled extensions are Apache-2.0, so extensions have no copyleft strings attached. No signup, no telemetry, trying to make it frictionless for people to try it out..
It's very much a beta, and is a one-man side project. It hasn't yet had a proper kicking from the real world, but I'm confident some people with similar preferences to my own will like it!
julesrms•2h ago
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!
yowlingcat•24m ago
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.