Yes, definitely considering that kind of angle to it. It's all evolving, I've only really been properly dogfooding in it for a couple of months, so still working out best practices.
And the collab side of things I'm only just now really having space to start pondering.
The default mode it uses for approving LLM tools is already read-only - it has a quite complicated (but conservative) bash parser that tries to let things that are definitely read-only get approved without bothering the user. It also has a tool for exploring the codebase where the LLM provides javascript code that runs in a sandbox with a read-only filesystem class.
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
TBH I've found myself using juggler's tabs like a kanban board.
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
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!
No, it talks directly to the GPT API, it doesn't control the codex app in any way.
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've mainly used the tree stuff when tackling a large plan - tell the LLM to do things using sub-threads, so the parent gets the summaries and orchestrates them.
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!
It does! It'll automatically detect and use the claude CLI. That's my main daily driver.
[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)
Totally. I spent a long time on the architecture of this thing, must have redesigned in 10 times to evolve it to this point. It was a really interesting challenge, but seems kind of obvious in hindsight..
An agent like claude might run a subagent (e.g. to fetch and summarise a web page, or explore a code question) as if it's a tool, so you can't really see what's going on inside it. Juggler makes these sub-threads part of the overall structure, so you can navigate into them.
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
An LLM conversation contains a massive mess of markdown, code, HTML, images, god-knows-what else, it needs to reflow and animate. Neither JUCE or any other non-HTML UI framework would be realistic for that!
I think that's basically the same as juggler's subthreads. As it progresses I'll work my way through all these kinds of thing and dig into whether there are things I can add or tweak to match their features. I'm aiming to make juggler's extension API flexible enough to support pretty much anything
I know! But 3 years is a very short time for a whole new category of tools to find the best design. It's incredible how quickly a lot of the big agents were dragged into existence, I'm amazed they worked at all..
TBH I'm not coming from the same angle as all the gas-town fever-dream agent swarming stuff. I'm much more on the hands-on coding side, I tend to do one thing at a time and still do the git commits myself. So that's the UX I'm dogfooding..
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
Hmm, that's odd. Would like to dig into that more if you can find any more clues about what went wrong. Feel free to message me if you want to discuss it
And the collab side of things I'm only just now really having space to start pondering.