julesrms

> You don't care about the little things

I wish that was true!

I'm not a cowboy arbitrarily making up random shortcuts. A major goal here is for a user to get near-as-dammit the same UI in a desktop app and in a remote browser. So all these shortcut choices have been a compromise between:

- what different people might expect the default to be (on mac/windows/linux/all kinds of apps)

- what a browser already uses (on mac/windows/linux/chrome/firefox/safari/etc)

- what people might have overridden random window managers and custom OS shortcuts

- what tasks are common enough that they deserve an easy-to-reach/remember key in spite of other factors

- choosing groups of shortcuts where you want the keys to be related (e.g. navigation) despite some being taken on some platforms

I obviously want the least surprising UX, and if this was just an app on one platform, it'd be easier. I've had to build a multi-platform shortcut manager that changes depending on the client, while trying to also keep as many as possible constant.

And yes, allowing users to customise the shortcuts is obviously on my list, but a) I wanted to let the app settle in and make sure I've got the right data model for storing key shortcuts first, and b) other more urgent features..

BTW `cmd+/` is the default "show the key shortcuts" in most chat environments like discord, slack, teams, google docs etc. These are much more relevant to juggler's UX when it comes to default shortcuts than things like VScode!

(...but yes, I had forgotten to add a desktop-app-only binding for `cmd+,`, so thanks for mentioning that - I've sorted that out now..)

You can connect to a juggler session from a browser on an iPad and get the full GUI on there. (Also from a phone, but although I've done my best to cram the UI into a mobile screen, it's a bit cramped)

An iOS app is on my roadmap, and pretty easy to do, because the whole GUI (including the desktop app) is just HTML being served, so shoving that into a mobile app is pretty trivial.

I mostly use claude and GPT for real coding. Because I need to test lots of models I've also got GLM and Deepseek accounts but they're really not yet up to the level where they compete with the frontier models in my experience.

> Can it also be used with pi and other tools?

You might use it instead of pi, or in addition to it. Juggler and pi are both harnesses, not things that work toghet.

Thanks - it sounds unlikely that a harness could do much to prevent hallucination, those smaller models are just way more random in their behaviour.

It's not just text, it's structured text. It often contains tables, sections, lots of things that can be drawn much more nicely.

And in juggler (and probably other harnesses too) the LLM can reply in HTML. So if I'm planning e.g. some UI changes, I might ask it "show me what this button will look like" and it'll reply with a picture of that thing in its response. No temp files to open or clean up, and fewer tokens burned

To answer your question about what I was trying to do that was different:

- a multi-client, state-machine based architecture rather than a naive LLM loop

- a bunch of UX features that I wasn't seeing in other harnesses (although of course they're all churning away in terms of UX so this changes all the time)

The difficult bits were:

- getting the data model right. This was a lot harder than it looks!

- getting an automated UI test framework in place that was robust enough to trust that incoming changes wouldn't break something. Originally I hoped to get away without this (I've never worked on a project before where we had automated UI tests!) but it was just a shitshow. I spent a couple of months getting this right, but it turned the whole project around and it's now incredibly quick and safe to make changes.

Thanks! I've had fun doing little details like that. Will keep trying to make it fun..

FWIW, making juggler plugin based feels quite normal to me, coming from the world of audio software, where that entire industry is still based around many thousands of VST/AudioUnit plugins which run native un-sandboxed code in the host apps, with access to absolutely anything they want. And it's somehow all just kind of been OK..

I totally get it. Lots of people, like you, love to set up their perfect custom, key-driven environment, and tune everything just how they want it. These tend to be the TUI fans.

I've never felt that urge, I've always been happier using Visual Studio / Xcode / VScode with default key bindings, and focused on other things. I'd rather click things inefficiently with a mouse than invest effort learning keypresses. Neither of us are wrong or right, but I think I'm trying to cater for my tribe on this project!

I've specifically designed juggler to do exactly that.

You run it on some headless machine, and point your browser at the HTTP server it creates to see the full GUI. It uses Yjs to make that connection as efficent as possible, and it works great.

The desktop app is literally doing the same thing internally - it runs a headless server process and serves the GUI to its own window. But you can stretch that over a network and it's the same experience.

I can even connect to it via a TURN server, from my phone on a cell signal, and although it's not as snappy as running locally, it works pretty well.

Well juggler literally does that - you run it headlessly on some machine (docker, whatever), it opens a HTTP port, and you can control it remotely with the exact same desktop GUI that you'd see if you ran it locally. (The desktop app is actually just running a headless process internally and serving it to its own window via HTTP).

Thanks! Would be keen to hear how that goes for you - if you find anything that starts to bloat its memory use, let me know and I'll look into it. As a native dev, this has always been something I care about

I actually just released a tarted-up version today that looks nicer still. I need to update the website screenshots..

Hmm, that's interesting - I certainly had 'homebrew' on my to-do-list, but quite low down, but you make a good argument for making it a higher priority..

It does seem like devs are splitting into the TUI and GUI tribes. Like tabs and spaces. We will probably never reconcile our differences or learn to empathise with the other side.

Woah there, I never said the 's' word!

Pi is a great project, and people love it for good reason, I have nothing negative to say about it or its fans. I'm just trying to do something that appeals to the more GUI-oriented folks. And yes, I'd really love to know if there's something that's making people bounce off the product, because it may be trivial to fix!

You can choose any font you want for your terminal, but only one at a time!

The native format of LLM interactions is markdown, and showing that in a terminal is a poor imitation of what it looks like rendered properly.

An interesting thing you can do in juggler is ask the LLM to reply in HTML instead of markdown, and they can then do things like illustrate points visually for you. LLMs are actually great at being able to express things visually to the user, but being stuck in terminals so much, people haven't really leaned on that very much

Yes indeed. In the case of juggler, if you check my CV you'll see that I'm very far from being a vibe coder - I've been shipping hugely complex products for 30 years, I've written frameworks, entire UI libraries, audio libraries, a DAW, a couple of compilers.. But this took me about a year to get right. I must have re-architected the whole thing more than 10 times, it took every bit of my experience to not screw up the data model. It's actually one of the most difficult and interesting projects I've done. So yes, if you can get claude to churn out a juggler-like app in a weekend, it probably ripped off the source code!

I'm not a noob in the software biz, I've been doing this kind of thing for over 30 years, and I understand expectations!

Like many things I've made, this started as a scratch-an-itch project, but now feels like it's unique and useful to enough people that it's worth a shot at turning it into a business. Exactly how to monetise it, not sure, but regardless of that step, step 1 is definitely just getting it out there!

There's a lot of "What's the point in making an app, one day we'll just ask claude for the tools we want and it'll write them in a weekend" but I think: a) For things like this you're going to get a better result by taking an app that's roughly the right shape, but customisable, and asking claude to customise it b) If we do end up in a world where nobody sells software apart from openAI and Anthropic, then that's a bad, bad place to be

I guess I'm mainly just talking about typography, nice interactions and movements, designed layout of information, rather than pictures. But it is interesting at this point to start thinking about what could be shown graphically.

I know.. I'm no stranger to doing talks, it's on my to-do-list to get out there and punt this a bit more!

> And to be honest: what do you even need from a harness\agent for it to have a gui?

Oh, it's just so much nicer! Personally I'm a graphics/typography nerd, so just having nice fonts, smooth movement, use of sizes, colours and graphics to differentiate and display types of information... Some people obviously don't care about this kind of look and feel nicety, but even so a GUI has so many more opportunities for displaying information in a clear but dense way.

Thanks! My grumbling is really just that the sheer amount of noise and churn in this area at the moment is making it hard to get any attention, despite there being so many millions of potential users out there. Unlike many of the others, I'm just one bloke, not a VC-funded outfit with a marketing budget!

Well, if you're only ever going to use claude models, then just use claude.

What I'm trying to do here is offer a tool where everything you do is provider agnostic, so you can use claude for some tasks, GPT for others, local models for others, without having to switch environments.

And also, when you run out of tokens in your claude 5 hour window, you can just flip over to Sol and finish the task..

Claude CLI is just one of the dozen or more LLM provider options juggler offers. It tries to auto-detect it because of course that's what most people will have, but of course you don't have to use it!

Appreciated! You may be naturally terminalist, but I reckon there are a lot of closet GUI lovers out there..

That doesn't mean you need a TUI! Juggler runs in headless terminals and VMs - you run it as a headless server process, and it serves the exact same desktop GUI via HTTP to any number of clients

Every few weeks Pi hits #1 here and I quietly grumble "mine does that too, but with lovely graphics.", so I'm saying it out loud: https://github.com/juggler-ai/juggler

Like Pi, it's plugins all the way down, provider-agnostic, minimal system prompts, threaded sub-agents, code-mode, multi-client remote sessions, worktrees, a context window you can actually see and edit, etc etc

Where Pi is way ahead is the plugin ecosystem, and that takes people, which is hard to get amid the current deluge of agent action. So if there's any spare oxygen trailing off this thread, I'd love any Pi-heads who fancy a bit of GUI action to come and kick the tyres..

Until the AIs are running entire companies unattended, then at some point, some human has to transfer some instructions into some actionable representation than the agents can build. That human might one day be a manager rather than a developer, but that transfer of intent is always going to be the problem to solve.

And IMHO while humans are still in charge of these processes, the way that most people can best design and explain what they want is via conversation, exploration, iteration, etc. Not by a single fire-and-forget prompt!

OK, but by the time you've worked out the correct prompt to tell your meta-agent how to iterate on optimising the right prompt for your actual agent, perhaps you could have just tried a few things and got it going!