HN user
Connecting to juggler remotely from a browser is baked into its whole architecture! The entire GUI is identical in the desktop app or browser, local or remote. So I'm not really sure I see much point in making it a server. But as a client, sure, will add that.
(oh, and I should mention: The next build will have a generic openAI provider, which might actually be exactly what you need)
Oh, I'm fully expecting people to ask for all kinds of weird custom providers, and they're easy to add. For launch I just focused on getting the provider API solid, and implementing the mainstream ones. Feel free to open an issue on GH if you want to request something that it doesn't do
ACP hadn't crossed my radar before some people mentioned it here, but it's an easy add to make juggler an ACP client - I'll do that in the next couple of days
Well, it's good to have the choice of whether to edit the document and break the cache, or not.
Ta for the heads-up, I'll tweak the website!
Mainly claude opus, with some fable for special occasions. And GPT5.6 is also good. But this stuff changes all the time.
Excellent. The audio dev industry is a really nice community!
Well, once the LLMs are better and faster at writing code than the humans, coding by hand becomes a hobby rather than a job..
I guess personally I spend just over 100/month on LLM subs
FYI I've got a plan for this now, I'll make it fallback to using node/bun as its javascript engine if GTK isn't available. So watch out for the next release if this is a showstopper for you..
yeah, sounds like your network's in a muddle somehow
Hmm, if you spot anywhere you think the app could be more helpful in diagnosing the problem let me know..
Yeah, if you edit then you do blow the cache.
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
Originally I allowed the LLM to decide whether a subthread inherits the parent context, but had to back out of that one. I found quite expensively that if the parent context includes an instruction to do a task in a subthread, it could fly off into an infinite recursion of subthreads all burning tokens to delegate the task to a subthread!
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.
Yeah, someone else reported that and I've got a (hopeful!) fix coming in the next release..
A thinking level setting is already in my TODO list top ten!
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)
I'll try to live up to the 'competent' bit!
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..
It's in my list of things to add next! (Though you can run it inside a sandbox tool of course)
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
Awesome to hear it. I built something that fitted my own mental model, and am assuming others out there have a similar one!
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!
Message received, I'll make ACP the top item on my TODO list!
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