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
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..
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.
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!