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: <a href="https://github.com/juggler-ai/juggler" rel="nofollow">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..
My personal quiet grumbling is that everyone got on the TUI bandwagon without any rational reason. I find it borderline psychotic. Or maybe humans are much more like sheep than we care to admit: we just follow the flock into the (UI) ravine. So your GUI is a nice escape.
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
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.
> 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.
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
I won't say Pi looks particularly impressive, but for example OpenCode looks beautiful to me and I prefer it to any graphical interface. The screenshots of your tool are nice but they feel like too much. With a good TUI like OpenCode and even Pi (which is decent) I fell like the code is front and foremost.
> And to be honest: what do you even need from a harness\agent for it to have a gui?
Nothing absolute that I couldn't live without. But TUI is essentially a design written for the lowest common denominator. It doesn't matter that I have had high resolution displays for years, average TUI is designed as if I'm using computer older than me.
I live in an office when I'm at work. Doesn't mean it's a great experience.
I love the terminal for terminal things. I'm not convinced agenetic coding is best implemented in a terminal - for it to work well, you're basically reinventing a toolkit wheel. Why not just use a nice graphical toolkit? It feels a bit like the current trend for pixelated graphics - both retro and worse.
if only there were a way to tunnel web servers over that very SSH connection and use a proper web UI, something HN has always been obsessed with.... oh well i guess we're stuck with a VT100! :( there's nothing we can do!
I'm currently using an R-studio server session running on a server half way around the world, via a gui web interface. It's fast and smooth. How on earth could that be?
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.
Or maybe people genuinely like TUIs? Most folks came of age after the TUI had already lost popularity to the eye candy and only recently learned the merits of the terminal. I personally have always loved a good TUI and enjoy the terminal. I can’t count the number of people who worked in a TUI and were pushed to a modern GUI say (usually in the 00’s) how much more productive they were in the TUI version.
What would you say are the merits of the terminal that a TUI encapsulates?
My opinion is that TUI is just a GUI with less fidelity. Being composed of text characters provides no additional benefit other than a retro style. The benefits of the terminal are outside of TUIs - composing scripts, piping data, bash etc.
Text interfaces can offer precision and breadth of tooling that guis don't.
I do a fair amount of CAD so I'll use that example. Nobody who uses CAD professionally is clicking all the little buttons for tools. They're using commands, shortcuts, scripts, etc.
A GUI is slow and clunky. A textual interface, once learned, has way more degrees of freedom.
I don't think anyone referring to GUI means 'no commands/shortcuts/scripts', like, all of those that all CAD programs are GUIs that have commands, shortcuts, etc.
My two cents is that having all of your text be monospaced is not really ideal for agentic workflows where you do in fact read a lot of prose and in the future may want diagrams, rendered from a full browser's capabilities, etc.
I think I like the aesthetic of using a TUI because it makes me feel more like whatever 'real programmer' means to me... but I recognize its also cope.
> They're using commands, shortcuts, scripts, etc.
Yes, power users often use shortcuts and automation, but how is that an argument against GUIs?
It simply depends a lot on the actual task. Certain things absolutely require a (high fidelity) graphical interface. Other things can be done just as well (and with less distraction) in a simple TUI. You can't generalize.
have you ever used, for example, vs code or Excel? both have robust GUI and keyboard capabilities. Andexcel has vba and now python and other scripting, and vscode is eminently extensible.
One small example - ChatGTP desktop intercepts highlighted text selection with "Ask ChatGTP" bubble. I have my own app that materializes a menu on highlighted text, but ChatGTP blocks it. No issues with that in the terminal. I am not a terminal junkie, but these opinionated paper cuts are annoying.
Vim keybindings, one of the most powerful and widely supported ways of interacting with information, basically impose the "grid of text" nature that define TUIs anyway, so my message prompt has to look like a terminal. The rest of the UI can be whatever, but grid-of-text works well for structured output, especially code blocks, as well.
TUIs compose with tmux. Pi's homepage says "use tmux" twice on it. It fits right into an already-mature ecosystem including a clipboard (powered by Vim visual / line / block mode) and easy integration with shells, editors, and other tools. GUIs generally have to re-invent all those wheels (tabs, splits, sessions, etc.) and it never integrates as well with other tools in a totally cross-platform way.
> What would you say are the merits of the terminal that a TUI encapsulates?
GUI scripting is still not a thing today. That's the biggest issue with GUIs.
Plus the mouse is genuinely bad for ergonomics.
Plus if you type _fast_ then TUIs are a great starting point.
Plus what's the equivalent of scrollback for a bunch of mouse clicks?
Plus TUIs are much more I/O efficient, which means running them over ssh/mosh/whatever is a great option.
Plus the shell is a programming language -- the GUI isn't just hard to macro-record/script: it doesn't even have a programming language you'd use for that.
All the agentic coding models are multimodal and can understand pictures quite well. I routinely paste in primitive paint drawings to augment my textual descriptions and show an agent what I mean, and it seems pretty effective. This can be to rough out a UI layout but it can also be useful in pure backend work drawing diagrams, or in any domain where code manipulates geometric data.
For an example, see my MSPaint drawings in the README (scroll near the bottom) for this tiny little project: <a href="https://github.com/rspeele/meshorient" rel="nofollow">https://github.com/rspeele/meshorient
I redrew those for the README but IIRC, I drew something similar when explaining how the feature would work to the agent.
And in reverse, after describing an architecture or an algorithm to it, I'll sometimes ask it to draw a diagram for me to demonstrate its understanding. If it draws the picture in line with what I intended, I conclude that it has gained the necessary context to proceed. If not, I know I explained something wrong or at least insufficiently and need to provide clarification. There are some domains where a picture is worth a thousand words.
It also helps cut through the Claudese. "Your decision is needed for one edge case, found by the gate. When a T-joint meets an endcap that the mesher solves by a fan, should this bisect a fan slice or raise a warning?" I'm sorry Claude, I am not from Missouri but you are going to have to Show Me this one with a picture.
Of course you can save pictures to files and open them with external tools, but it's nicer to have them inlined into the chat history when that's exactly what they are: part of the conversation.
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
i love vim and i love vim-tmux-navigator keybinds letting me navigate quickly between panes in my terminal: ctrl-{h,j,k,l} to switch panes. i love that tui agents fit right in among my shells and vims. i love that my setup works just as well on my machine and on any remote machine over ssh or mosh. i’ve been working like this since 2012. although i did start using vscode for $DAYJOB since our devex team supports it (has good vim keybinds at least)
Our architecture team started with vscode and windows because it’s “how it’s been done” but within a year they all migrated to ghostty or another terminal on Mac because it’s so much faster and efficient.
im with you. I have tried all the TUIs and immediately bounce off of them due to how utterly awful even just basic operations like text editing are. I use Vscode copilot chat because in the before-times I was perfectly happy with vscode. I cannot comprehend how people can now give all of that up for TUIs. It also has its Agents Window, Copilot CLI etc... and you can use any api keys, subscriptions etc... that you want.
And, of course, most of the tools have created their own GUIs anyway, which are far worse than VS Code (even when they've forked VSCode itself!)
I think the "borderline psychotic" phrasing is apt.
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!
I grew up running and calling dialup BBSs, learning to program in the MS DOS shell world with QBasic and Turbo Pascal "IDE"s, dialing up and later telnetting into a Lynx browser (early on when I couldn't afford a PPP link with lawn mowing money).. the "terminal" and thereby TUI applications (they weren't called that at the time as far as I know, but that's definitely what they were) are home, for at least me. I just wish more TUIs had single keystroke hotkeys (indicated by the hotkey's letter in the menu item title being a different color or intensity) like the old BBS and other menus. I could login and download a QWK packet quicker than the time it took for the modem to finish the DTMF tones. I'm excited about how many new things allow me to stay in the interface my brain formed around. YMMV
I don't actually know what you're referring to, but from context I can guess that you're referring to something like the Juno dialup "at&t" links they used to actually send the emails. The PPP L/P were encoded in the .into files and they were great free PPP links while they lasted.
Most GUIs can't be navigated by a fluent keybind system. And if they do have keybinds, they are their own, and not consistent with what others use, or you can't modify them. And then there is the issue of making it hard to run multiple copies at the same time (I can't just click the app icon again to start a second copy, Juggler does solve for this though), nor can I keep two copies together side by side easily. Being able to copy and paste text is hit or miss.
I love good GUI apps. They are hard to do well.
Juggler, for example, already collides with a Keyboard Shortcut I use across the desktop, so CMD + J can't be used. It also uses CMD + / for keyboard shortcuts? Tha's a choice. It doesn't respect Mac's preferences/settings shortcut (CMD + ,)
You can be on a chat window, and there is no way without using the mouse that I see where you can start typing into the chat box. Juggler tells me to type / and I can run a command. I type / and nothing happens. What that really means is I have to use my mouse to put the cursor in the small chat box down below.
This isn't to say Juggler is bad. Rather, it's got a long way to go for the GUI to be something that has the fluency of something like vim.
TUIs generally have to solve for that. You have to offer up those features. You can't rely on laziness. So at the very least, there generally are keyboard shortcuts and they need to be obvious.
Feel free to think that people don't have a rational reason for TUIs, but it buys you a lot for free. And this isn't an indictment on Juggler. It works. It's functional. It doesn't feel natural, nor does it respect conventions.
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!
fwiw, you can cater to both. It's not an exclusive thing. Having a gui is not bad. It's just effort to make it good. Take for example the CMD + , not opening settings/preferences on Mac. That's convention on the platform.
> 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.
No, you don't "get it." Like me? I don't want to set things up. I don't want to customize. I thrive off convention. And there are apps that follow these conventions. They do this out of respect for people who enjoy the defaults they enjoy elsewhere in other applications.
> I've always been happier using Visual Studio / Xcode / VScode with default key bindings
That's not true though, because you don't even use the same default/convention key bindings they use. By doing things your own way, you are making it so it's harder for your users to adopt your application.
> "mine does that too, but with lovely graphics.",
But it doesn't. You don't care about the little things, so how are you going to get the bigger things correct?
Listen, it's great that you built a tool that you love. I love doing that, too. But if you want users, you have to respect them. And that means making it easier for them to use your app.
And if our app just doesn't work because / doesn't do what it says it's going to do, that's an issue. And if your app doesn't allow for customizing keyboard shortcuts, it's disrespecting users who have those set for something else.
> but I think I'm trying to cater for my tribe on this project!
Just realize that tribe is juggler-ai users, or people who don't use defaults. People who are fine with default key bindings, can't effectively use your app.
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..)
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).
I work over SSH often from various other OSs, TUIs don't need any additional abstractions to make that work, I just SSH in from any computer/OS and everything works. All I need is SSH and the terminal based apps. It's not psychotic, it's literally a feature that cannot be found with GUIs.
hate to make a "me too" comment but TUIs working over ssh is what makes them so great. Also, when combined with something like screen it's icing on the cake.
LLM error: failed to start claude CLI: claude executable not found. Searched $PATH, the login shell, and known install locations (~/.local/bin, ~/.claude/local, ~/.npm-global/bin, /opt/homebrew/bin, /usr/local/bin). Set JUGGLER_CLAUDE_PATH to its absolute path if it lives elsewhere
I think any tool that needs claude CLI is a no-go in my list. Claude is a closed source binary with idk what it does in there, IIUC. Maybe I am not the target market for this.
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!
This project looks great, well done, BUT it seems very odd to be "grumbling" about Pi when you're explicitly targeting a separate audience (GUI users).
There are other GUI tools like Juggler that are quite popular, like cmux, that it seems better placed as an alternative to.
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!
Why do you want attention? Are you trying to sell this? Make money? Just want personal fame?
The reason there is so much noise in is area is because these tools are a dime a dozen and trivial to create with AI. I don’t think it realistic anymore to expect a rush of users and make money off of these. The supply is going to far outstrip the demand.
Last Saturday I asked Claude to create a Claude Code clone for me with a few customizations that I personally prefer. It did so in less than an hour, and works just as well as Claude Code. I’m not looking for attention on it - I’m happy I made it, and just myself as a user is gratification enough. I think this is the future of software development, and I think having expectations of attention from others just because you made another tool is setting yourself up for disappointment.
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
for whatever it's worth, thanks for your work on Juggler! i really like the concept (especially the miller columns are really nice), and a small detail but i appreciate the musician's touches you put in the notification chime (randomized according to selected scale)!
It looks like a good system, great if it works for you - but we now live in a period where I could build a similar tool to handle MY preferences in a weekend if I wanted to.
And, it would almost be EASIER than learning to use a new tool. I prefer PI because I didn't want batteries included in the terminal. Any decisions about what a user might want is a decision made on the user's behalf that dilute that core.
Juggler looks good - not personally for me. But that's OK, it's got 675 stars and a bunch of forks. That's attention, no?
I think people vastly overestimate how hard it is to get a tool right even in the age of AI. Yes, it's very easy to get a throwaway tool done in a session. For anything above trivial complexity (like a coding harness) you will immediately notice warts with it.
It's true: with proper planning, thought, and focus, you might be able to generate enough code in one weekend to create a tool that is at parity with something like Pi - but chances are the amount of focus, planning, and thought is going to be greater than one weekend worth. And I don't know about you - but I don't really want to spend my weekend building a coding harness, I have other ideas and projects I'd rather execute.
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 think you probably meant to write “underestimate”. But I think you are overestimating how difficult it is!
I’m not exaggerating when I say all I had to do was prompt “build me an LLM coding harness like Claude code, but make it so that I can resume sessions from OpenCode and Pi as well” and that’s it, and it was done within an hour.
Didn’t have warts? Sure, a couple of really minor things. One of the things I realized quickly was that it didn’t have a WebFetch tool built in, so I prompted “add a webfetch tool” and it did it within 5 minutes. Warts are trivially fixed.
The things that really differentiate software now are the ideas behind them, not the implementation. So if (like the OP) you’re looking at a tool and going “well mine does that too…”, so what? If it’s just a re-implementation of the same ideas, anyone can recreate it (and add on their own customizations to boot).
Personally, I am getting frustrated with the amount of people trying to pitch me their tool they made. Tools are a dime a dozen. They’re cattle now, not pets. Share with me your ideas, and I’ll share with you mine, but I don’t care about your tool.
> Did it have warts? It’s been working nearly flawlessly, but there have been a couple of really minor things. One of the things I realized quickly was that it didn’t have a WebFetch tool built in, so I prompted “add a webfetch tool” and it did it within 5 minutes. Warts are trivially fixed.
Sure, and then tomorrow it's compaction, then worktrees, then an annoying buffer scrolling bug, image clipboard handling, etc etc. I don't buy for a minute that a one-liner prompt creates a perfect program because I know from experience it doesn't. You are inheriting the maintenance of a non-trivial program. That's perfectly fine if you want to tinker and spend time on that but I would rather offload that to someone who wants to spend more time thinking about those problems than I do.
> Personally, I am getting frustrated with the amount of people trying to pitch me their tool they made. Tools are a dime a dozen. Share with me your ideas, and I’ll share with you mine, but I’m not gonna adopt your tool.
I'm not sure I follow this line of thinking. Obviously, juggler is the result of an author who has spent a great deal amount of time thinking about an idea. It is the manifestation of the author's ideas. I agree that the amount of vibe coded slop out there that people think is marketable is ridiculous, but Juggler doesn't really look like that. It's still worthwhile to evaluate well thought out tools IMO.
> Sure, and then tomorrow it's compaction, then worktrees, then an annoying buffer scrolling bug, image clipboard handling, etc etc. I don't buy for a minute that a one-liner prompt creates a perfect program because I know from experience it doesn't.
Every thing you listed works out of the box. Believe it or not, it’s true! And creating tools like this is only going to get easier as LLM models progress.
Your comment very much reminds me of comments from 2023 saying that LLMs would never be able to write working code, or be able to generate lifelike pictures, or be able to find security issues… but look around you, they’re doing all of those things already!
I'm using these tools everyday just like you and everyone else and I 100% know they don't produce code that works perfectly out of the box. That's horseshit.
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.
Fwiw, as a terminal-dweller I have trialled cmux - it didn't hit the spot for me obviously, but I filed as away as a tool to recommend to my wife/siblings who are pretty technical but don't code, but want to dip their toes in this age of llms. That's a growing demographic I haven't really seen many tools trying to serve - Juggler's not explicitly aimed at that market but it looks much much better suited than cmux or other guis I've seen, so I'll probably be giving it a go.
Hey, this looks amazing. Sorry for my ignorance, and my lack of initiative for not testing this myself, but I wanted to ask - how is this different than for example just using Claude directly?
Sorry if this question is condescending, I just want to understand what is your vision for this tool :)
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..
You can use any (Anthropic API-compatible) provider and any model with Claude Code, it's just a matter of changing the env vars in the settings json...
My company is lame, and I can only really install software via Homebrew without a lengthy approval and packaging process.
Have you thought about adding Juggler to Homebrew?
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..
We're phasing homebrew out in my organization, so I wouldn't focus on tailoring to it. .dmg files are fine and good. but homebrew sort of fell apart with its automatic updates that break things. If I am looking to install a single package, I'm not expecting homebrew to install 200 of them. Yet that's what's happening now, and is the reason I'm advocating phasing homebrew out. My two cents.
When I read "lovely graphics" I was expecting visualizations or images. I was curious so I scrolled through your screenshots and I didn't see any, just a lot of text screens. By graphics did you mean GUI text formatting?
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.
We need to pay attention to the new Cambrian explosion of software. The attitude of "everyone already uses VSCode" should disappear, and people should be open to try more niche products.
After all, being a developer is no longer a moat, and smaller ecosystems can thrive now.
I just tested it out, that's some low memory footprint. Even less than pi. I run multiple opencode sessions and it eats my ram. I will continue to try to use this.
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
Been a happy Juggler since I first saw it on here. I really think it is much more approachable for people who are intimidated/overwhelmed by the terminal and just want an all in one solution that is intuitive, pre-configured, and also works great. I really like the "auto approve" strategy given lots of people have no idea when something like a `sed` is going to write or read.
However, I likely wouldnt suggest Pi (or even opencode) to someone who I would also suggest Juggler. They just dont feel like the same type of user, in my opinion.
I do think you could take a look at ChatWise, Kelivo, Rikkahub, Jan, and Waku if you wanted to see who your real competitors are. Again, in my opinion.
Those are full standalone GUIs with workspaces and built in tools that help you get things done without requiring any terminal commands.
Keep in mind that the creator of Pi has done a ton of advocacy for it... talks, podcasts, demos, etc.
Marketing really matters here. Sometimes a tool can take off on its own with just a little bit of prodding (hn/reddit announcements and the like), but in this era where there is just way too much choice that is difficult to differentiate, the S/N is just too opaque.
Think about Matt Pocock for a moment - the guy is literally famous for 'his' grill-me skill. A skill. And something he really did not come up with, as the core tenant has been a a prior-art prompt template going back to 2023, but no one seems to question or point that out as he has been so pervasive online promoting this as his invention that it just drowns out any dissent.
Marketing is tough. I have a pi-adjacent integrated environment (<a href="https://rcarmo.github.io/projects/piclaw" rel="nofollow">https://rcarmo.github.io/projects/piclaw) and it might as well not exist in that ecosystem :)
By way of differentiation, consider that a single GUI can seamlessly and visually manage agents across several machines, while TUI is likely to remain separate terminals. In the fullness of it I don’t want to think which machine is hosting which agentic conversation (or a group of related conversation). A diffrent UX paradigm.
Well, I wouldn't've found your project if you didn't mention it here, so good job! It looks good, minimal, I like that you're using javascript instead of that thing typescript.
Unrelated, I found that when an open model (qwen3-coder:30b) drives an mcp tool (chrome-devtools-mcp@latest), it hallucinates the tool calls, and the docs say they never promised that tool calls would make sense or be valid. To me, this is a blocker and is the reason I've stopped looking at harnesses like pi. The tool calls are just fine if a closed LLM, gpt-5.* drives them, but I need a free and open LLM. Have you run into this issue, have you addressed it?
Looks good thanks will give it a go. How do you personally use it? In a sandboxed environment? What providers are you using? Can it also be used with pi and other tools?
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.
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.
This is fairly off-topic but I thought you were familiar alright! I used JUCE back in college for a POC synthesizer and I remember it being the absolute best for plugin development. Incredibly enough it was my first point of contact with C++ and it was a joy to develop with.
I have not revisited VSTs post LLMs or even stayed close to music since I lost my collection and rock climbing has consumed most of my last decade, but kudos to putting such unique tooling out there when the rest of the ecosystem looked so byzantine. It's wild how people built so many incredible virtual instruments back in the day.
Going through those memories I'm now curious how the scene is like today where wild idea projects are more within reach.
julesrms · · focus · HN ↗
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..
fatata123 · · focus · HN ↗
[dead]
vorticalbox · · focus · HN ↗
It’s great that’s plugins all the way down the issue I find is I haven’t missed anything enough to need a plugin.
jonenst · · focus · HN ↗
KolmogorovComp · · focus · HN ↗
jon23d · · focus · HN ↗
julesrms · · focus · HN ↗
kraktoos · · focus · HN ↗
julesrms · · focus · HN ↗
konart · · focus · HN ↗
I hardly use anything aside from neovim and a browser. (okay corporate Mattermost fork and video terminal too).
For me switching between different cli\tui tools feels like a continuation of whatever I was doing, while going to something GUIsh is not.
And to be honest: what do you even need from a harness\agent for it to have a gui?
julesrms · · focus · HN ↗
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.
konart · · focus · HN ↗
They can even show images these days.
Some of the elements can't be recreated 1 to 1 ofc, like borders with delicate margin\padding adjustment, but this is about it I think.
To each his own, yeah. From my experiment GUIs tend to overcomplicate things and display too much info you didn't need in the first place.
konart · · focus · HN ↗
experience
voakbasda · · focus · HN ↗
albondiga90210 · · focus · HN ↗
julesrms · · focus · HN ↗
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
maupin · · focus · HN ↗
flaunf221 · · focus · HN ↗
Nothing absolute that I couldn't live without. But TUI is essentially a design written for the lowest common denominator. It doesn't matter that I have had high resolution displays for years, average TUI is designed as if I'm using computer older than me.
epihelix · · focus · HN ↗
I love the terminal for terminal things. I'm not convinced agenetic coding is best implemented in a terminal - for it to work well, you're basically reinventing a toolkit wheel. Why not just use a nice graphical toolkit? It feels a bit like the current trend for pixelated graphics - both retro and worse.
lionkor · · focus · HN ↗
8aKXcbOAOz · · focus · HN ↗
svennek · · focus · HN ↗
KetoManx64 · · focus · HN ↗
epihelix · · focus · HN ↗
julesrms · · focus · HN ↗
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.
lionkor · · focus · HN ↗
grosswait · · focus · HN ↗
almostarockstar · · focus · HN ↗
My opinion is that TUI is just a GUI with less fidelity. Being composed of text characters provides no additional benefit other than a retro style. The benefits of the terminal are outside of TUIs - composing scripts, piping data, bash etc.
idiotsecant · · focus · HN ↗
I do a fair amount of CAD so I'll use that example. Nobody who uses CAD professionally is clicking all the little buttons for tools. They're using commands, shortcuts, scripts, etc.
A GUI is slow and clunky. A textual interface, once learned, has way more degrees of freedom.
kaibee · · focus · HN ↗
My two cents is that having all of your text be monospaced is not really ideal for agentic workflows where you do in fact read a lot of prose and in the future may want diagrams, rendered from a full browser's capabilities, etc.
I think I like the aesthetic of using a TUI because it makes me feel more like whatever 'real programmer' means to me... but I recognize its also cope.
spacechild1 · · focus · HN ↗
Yes, power users often use shortcuts and automation, but how is that an argument against GUIs?
It simply depends a lot on the actual task. Certain things absolutely require a (high fidelity) graphical interface. Other things can be done just as well (and with less distraction) in a simple TUI. You can't generalize.
nchmy · · focus · HN ↗
stasomatic · · focus · HN ↗
bloppe · · focus · HN ↗
TUIs compose with tmux. Pi's homepage says "use tmux" twice on it. It fits right into an already-mature ecosystem including a clipboard (powered by Vim visual / line / block mode) and easy integration with shells, editors, and other tools. GUIs generally have to re-invent all those wheels (tabs, splits, sessions, etc.) and it never integrates as well with other tools in a totally cross-platform way.
cryptonector · · focus · HN ↗
GUI scripting is still not a thing today. That's the biggest issue with GUIs.
Plus the mouse is genuinely bad for ergonomics.
Plus if you type _fast_ then TUIs are a great starting point.
Plus what's the equivalent of scrollback for a bunch of mouse clicks?
Plus TUIs are much more I/O efficient, which means running them over ssh/mosh/whatever is a great option.
Plus the shell is a programming language -- the GUI isn't just hard to macro-record/script: it doesn't even have a programming language you'd use for that.
nilamo · · focus · HN ↗
rspeele · · focus · HN ↗
For an example, see my MSPaint drawings in the README (scroll near the bottom) for this tiny little project: <a href="https://github.com/rspeele/meshorient" rel="nofollow">https://github.com/rspeele/meshorient
I redrew those for the README but IIRC, I drew something similar when explaining how the feature would work to the agent.
And in reverse, after describing an architecture or an algorithm to it, I'll sometimes ask it to draw a diagram for me to demonstrate its understanding. If it draws the picture in line with what I intended, I conclude that it has gained the necessary context to proceed. If not, I know I explained something wrong or at least insufficiently and need to provide clarification. There are some domains where a picture is worth a thousand words.
It also helps cut through the Claudese. "Your decision is needed for one edge case, found by the gate. When a T-joint meets an endcap that the mesher solves by a fan, should this bisect a fan slice or raise a warning?" I'm sorry Claude, I am not from Missouri but you are going to have to Show Me this one with a picture.
Of course you can save pictures to files and open them with external tools, but it's nicer to have them inlined into the chat history when that's exactly what they are: part of the conversation.
julesrms · · focus · HN ↗
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
jitl · · focus · HN ↗
ramgine · · focus · HN ↗
nchmy · · focus · HN ↗
And, of course, most of the tools have created their own GUIs anyway, which are far worse than VS Code (even when they've forked VSCode itself!)
I think the "borderline psychotic" phrasing is apt.
wookmaster · · focus · HN ↗
julesrms · · focus · HN ↗
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!
boie0025 · · focus · HN ↗
ljosifov · · focus · HN ↗
boie0025 · · focus · HN ↗
boie0025 · · focus · HN ↗
jasonlotito · · focus · HN ↗
I love good GUI apps. They are hard to do well.
Juggler, for example, already collides with a Keyboard Shortcut I use across the desktop, so CMD + J can't be used. It also uses CMD + / for keyboard shortcuts? Tha's a choice. It doesn't respect Mac's preferences/settings shortcut (CMD + ,)
You can be on a chat window, and there is no way without using the mouse that I see where you can start typing into the chat box. Juggler tells me to type / and I can run a command. I type / and nothing happens. What that really means is I have to use my mouse to put the cursor in the small chat box down below.
This isn't to say Juggler is bad. Rather, it's got a long way to go for the GUI to be something that has the fluency of something like vim.
TUIs generally have to solve for that. You have to offer up those features. You can't rely on laziness. So at the very least, there generally are keyboard shortcuts and they need to be obvious.
Feel free to think that people don't have a rational reason for TUIs, but it buys you a lot for free. And this isn't an indictment on Juggler. It works. It's functional. It doesn't feel natural, nor does it respect conventions.
julesrms · · focus · HN ↗
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!
jasonlotito · · focus · HN ↗
> 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.
No, you don't "get it." Like me? I don't want to set things up. I don't want to customize. I thrive off convention. And there are apps that follow these conventions. They do this out of respect for people who enjoy the defaults they enjoy elsewhere in other applications.
> I've always been happier using Visual Studio / Xcode / VScode with default key bindings
That's not true though, because you don't even use the same default/convention key bindings they use. By doing things your own way, you are making it so it's harder for your users to adopt your application.
> "mine does that too, but with lovely graphics.",
But it doesn't. You don't care about the little things, so how are you going to get the bigger things correct?
Listen, it's great that you built a tool that you love. I love doing that, too. But if you want users, you have to respect them. And that means making it easier for them to use your app.
And if our app just doesn't work because / doesn't do what it says it's going to do, that's an issue. And if your app doesn't allow for customizing keyboard shortcuts, it's disrespecting users who have those set for something else.
> but I think I'm trying to cater for my tribe on this project!
Just realize that tribe is juggler-ai users, or people who don't use defaults. People who are fine with default key bindings, can't effectively use your app.
julesrms · · focus · HN ↗
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..)
multiplegeorges · · focus · HN ↗
How can a GUI replicate this workflow? I know it could, technically, but not as easily.
julesrms · · focus · HN ↗
multiplegeorges · · focus · HN ↗
TJTorola · · focus · HN ↗
chasd00 · · focus · HN ↗
Fidelix · · focus · HN ↗
Cursor has this, and there are others that can attach to ssh or open their UI via a tunnel or web interface.
SSH is mighty convenient though, so I am not necessarily saying your point is incorrect.
nijave · · focus · HN ↗
sznio · · focus · HN ↗
feffe · · focus · HN ↗
unrented7977 · · focus · HN ↗
cryptonector · · focus · HN ↗
Wut?
demo4567 · · focus · HN ↗
But maybe this will be good as a meta harness. For my whole disk. I will take a look
demo4567 · · focus · HN ↗
LLM error: failed to start claude CLI: claude executable not found. Searched $PATH, the login shell, and known install locations (~/.local/bin, ~/.claude/local, ~/.npm-global/bin, /opt/homebrew/bin, /usr/local/bin). Set JUGGLER_CLAUDE_PATH to its absolute path if it lives elsewhere
I think any tool that needs claude CLI is a no-go in my list. Claude is a closed source binary with idk what it does in there, IIUC. Maybe I am not the target market for this.
julesrms · · focus · HN ↗
julesrms · · focus · HN ↗
demo4567 · · focus · HN ↗
konart · · focus · HN ↗
But it's GUI, so a no go by default. TUI > GUI
gazpachotron · · focus · HN ↗
[dead]
lucideer · · focus · HN ↗
This project looks great, well done, BUT it seems very odd to be "grumbling" about Pi when you're explicitly targeting a separate audience (GUI users).
There are other GUI tools like Juggler that are quite popular, like cmux, that it seems better placed as an alternative to.
julesrms · · focus · HN ↗
cobolcomesback · · focus · HN ↗
The reason there is so much noise in is area is because these tools are a dime a dozen and trivial to create with AI. I don’t think it realistic anymore to expect a rush of users and make money off of these. The supply is going to far outstrip the demand.
Last Saturday I asked Claude to create a Claude Code clone for me with a few customizations that I personally prefer. It did so in less than an hour, and works just as well as Claude Code. I’m not looking for attention on it - I’m happy I made it, and just myself as a user is gratification enough. I think this is the future of software development, and I think having expectations of attention from others just because you made another tool is setting yourself up for disappointment.
julesrms · · focus · HN ↗
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
gcr · · focus · HN ↗
julesrms · · focus · HN ↗
NichoPaolucci · · focus · HN ↗
It looks like a good system, great if it works for you - but we now live in a period where I could build a similar tool to handle MY preferences in a weekend if I wanted to.
And, it would almost be EASIER than learning to use a new tool. I prefer PI because I didn't want batteries included in the terminal. Any decisions about what a user might want is a decision made on the user's behalf that dilute that core.
Juggler looks good - not personally for me. But that's OK, it's got 675 stars and a bunch of forks. That's attention, no?
boredtofears · · focus · HN ↗
It's true: with proper planning, thought, and focus, you might be able to generate enough code in one weekend to create a tool that is at parity with something like Pi - but chances are the amount of focus, planning, and thought is going to be greater than one weekend worth. And I don't know about you - but I don't really want to spend my weekend building a coding harness, I have other ideas and projects I'd rather execute.
julesrms · · focus · HN ↗
cobolcomesback · · focus · HN ↗
I’m not exaggerating when I say all I had to do was prompt “build me an LLM coding harness like Claude code, but make it so that I can resume sessions from OpenCode and Pi as well” and that’s it, and it was done within an hour.
Didn’t have warts? Sure, a couple of really minor things. One of the things I realized quickly was that it didn’t have a WebFetch tool built in, so I prompted “add a webfetch tool” and it did it within 5 minutes. Warts are trivially fixed.
The things that really differentiate software now are the ideas behind them, not the implementation. So if (like the OP) you’re looking at a tool and going “well mine does that too…”, so what? If it’s just a re-implementation of the same ideas, anyone can recreate it (and add on their own customizations to boot).
Personally, I am getting frustrated with the amount of people trying to pitch me their tool they made. Tools are a dime a dozen. They’re cattle now, not pets. Share with me your ideas, and I’ll share with you mine, but I don’t care about your tool.
boredtofears · · focus · HN ↗
Sure, and then tomorrow it's compaction, then worktrees, then an annoying buffer scrolling bug, image clipboard handling, etc etc. I don't buy for a minute that a one-liner prompt creates a perfect program because I know from experience it doesn't. You are inheriting the maintenance of a non-trivial program. That's perfectly fine if you want to tinker and spend time on that but I would rather offload that to someone who wants to spend more time thinking about those problems than I do.
> Personally, I am getting frustrated with the amount of people trying to pitch me their tool they made. Tools are a dime a dozen. Share with me your ideas, and I’ll share with you mine, but I’m not gonna adopt your tool.
I'm not sure I follow this line of thinking. Obviously, juggler is the result of an author who has spent a great deal amount of time thinking about an idea. It is the manifestation of the author's ideas. I agree that the amount of vibe coded slop out there that people think is marketable is ridiculous, but Juggler doesn't really look like that. It's still worthwhile to evaluate well thought out tools IMO.
cobolcomesback · · focus · HN ↗
Every thing you listed works out of the box. Believe it or not, it’s true! And creating tools like this is only going to get easier as LLM models progress.
Your comment very much reminds me of comments from 2023 saying that LLMs would never be able to write working code, or be able to generate lifelike pictures, or be able to find security issues… but look around you, they’re doing all of those things already!
boredtofears · · focus · HN ↗
julesrms · · focus · HN ↗
- 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.
lucideer · · focus · HN ↗
Fwiw, as a terminal-dweller I have trialled cmux - it didn't hit the spot for me obviously, but I filed as away as a tool to recommend to my wife/siblings who are pretty technical but don't code, but want to dip their toes in this age of llms. That's a growing demographic I haven't really seen many tools trying to serve - Juggler's not explicitly aimed at that market but it looks much much better suited than cmux or other guis I've seen, so I'll probably be giving it a go.
tadziokas · · focus · HN ↗
Sorry if this question is condescending, I just want to understand what is your vision for this tool :)
julesrms · · focus · HN ↗
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..
vekker · · focus · HN ↗
arshxyz · · focus · HN ↗
evandena · · focus · HN ↗
julesrms · · focus · HN ↗
victor_pudeyev · · focus · HN ↗
dfc · · focus · HN ↗
julesrms · · focus · HN ↗
Shorel · · focus · HN ↗
We need to pay attention to the new Cambrian explosion of software. The attitude of "everyone already uses VSCode" should disappear, and people should be open to try more niche products.
After all, being a developer is no longer a moat, and smaller ecosystems can thrive now.
ziphyrien · · focus · HN ↗
krisgenre · · focus · HN ↗
figmert · · focus · HN ↗
julesrms · · focus · HN ↗
james2doyle · · focus · HN ↗
However, I likely wouldnt suggest Pi (or even opencode) to someone who I would also suggest Juggler. They just dont feel like the same type of user, in my opinion.
I do think you could take a look at ChatWise, Kelivo, Rikkahub, Jan, and Waku if you wanted to see who your real competitors are. Again, in my opinion.
Those are full standalone GUIs with workspaces and built in tools that help you get things done without requiring any terminal commands.
andersonpico · · focus · HN ↗
julesrms · · focus · HN ↗
brandall10 · · focus · HN ↗
Marketing really matters here. Sometimes a tool can take off on its own with just a little bit of prodding (hn/reddit announcements and the like), but in this era where there is just way too much choice that is difficult to differentiate, the S/N is just too opaque.
Think about Matt Pocock for a moment - the guy is literally famous for 'his' grill-me skill. A skill. And something he really did not come up with, as the core tenant has been a a prior-art prompt template going back to 2023, but no one seems to question or point that out as he has been so pervasive online promoting this as his invention that it just drowns out any dissent.
julesrms · · focus · HN ↗
rcarmo · · focus · HN ↗
DenisM · · focus · HN ↗
Best of luck!
eloisant · · focus · HN ↗
There are so many ways to visually manage your agents sessions with a terminal app.
victor_pudeyev · · focus · HN ↗
Unrelated, I found that when an open model (qwen3-coder:30b) drives an mcp tool (chrome-devtools-mcp@latest), it hallucinates the tool calls, and the docs say they never promised that tool calls would make sense or be valid. To me, this is a blocker and is the reason I've stopped looking at harnesses like pi. The tool calls are just fine if a closed LLM, gpt-5.* drives them, but I need a free and open LLM. Have you run into this issue, have you addressed it?
julesrms · · focus · HN ↗
zennit · · focus · HN ↗
julesrms · · focus · HN ↗
> 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.
sleight42 · · focus · HN ↗
But, seriously, I'll fire this up!
julesrms · · focus · HN ↗
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.
nidnogg · · focus · HN ↗
I have not revisited VSTs post LLMs or even stayed close to music since I lost my collection and rock climbing has consumed most of my last decade, but kudos to putting such unique tooling out there when the rest of the ecosystem looked so byzantine. It's wild how people built so many incredible virtual instruments back in the day.
Going through those memories I'm now curious how the scene is like today where wild idea projects are more within reach.