Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE

github.com

Post reply on HN
Print view View original

61–70 of 128 posts

Re: Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE

#61

Post by westurner »

Jupyter-rtc is built on y.js too.

There's a sqlite CRDT: cr-sqlite,: https://news.ycombinator.com/item?id=41921992

vlcn-io/cr-sqlite: Convergent, Replicated SQLite. Multi-writer and CRDT support for SQLite https://github.com/vlcn-io/cr-sqlite

Notes on sandboxing agents: amla sandbox, agentvm, bwrap at least; debugging mcp servers, and signing agent traces in a standard format: https://news.ycombinator.com/item?id=48893850

--

Can juggler: Design and verify a guitar effect pedals and a wavetable synth with JUCE on a low power chip?

JUCE on embedded controllers; Rust embedded RTOS-like features, a DSP and low power draw:

> Ambiq Apollo4 Plus | ARM Cortex-M4F | ~4–10 µA / MHz | more efficient than an RP2040 Pi Pico. The hardware FPU handles audio math at a fraction of the power footprint.

> STM32U5 Series | ARM Cortex-M33 ~110 µA / MHz | energy-saving modes, math accelerators (Cordic for sines/cosines), audio peripherals

> STM32L4 Series | ARM Cortex-M4F | ~100 µA / MHz | mature, ultra-low-power, robust I2S audio support, sleep state

grame-cncm/faust: Functional programming language for signal processing and sound synthesis / [that compiles to microcontroller DSP code, LLVM IR,] https://github.com/grame-cncm/faust

Then a Rust-based OS for microcontrollers; to isolate devices and device drivers from other processes;

I'd like to learn this too (so this is worth researching)

Rust packages for DSP:

embedded-hal, embedded-io, rand_core

Navigating the Embedded Rust Ecosystem https://www.theembeddedrustacean.com/p/navigating-the-embedd...

https://google.github.io/comprehensive-rust/bare-metal/micro...

hubris > Flash instructions already mention an STM32 F but not yet U or L: https://github.com/oxidecomputer/hubris#flash

Task: Add support for STM32U and STM32L to hubris

"Navigating the Embedded Rust Ecosystem" https://www.theembeddedrustacean.com/p/navigating-the-embedd...

The micro:bit has a speaker and something like a DSP and rust support, though it's not going to run JUCE and BespokeSynth ; kk Just rtic, cortex-m-rt, and nrf52833-hal (for micro:bit v2) might be sufficient but there's already microbit_bsp:

microbit_bsp is a board support package (BSP) library for the micro:bit v2 and newer: https://docs.rs/microbit-bsp/latest/microbit_bsp/

Another task; Develop and test a board support package for low-power chips for hosting effects from JUCE compiled with or like Faust.

But then contain agent sessions;

e.g. Hubris has no shared memory so audio streams must be shoveled over message passing

--

Back to agent sandboxing;

It looks like WebKitGTK uses bubblewrap on linux unless running in a flatpak, because flatpaks don't have permission to create namespaces so bwrap can't run.

Bubblewraplauncher.cpp: https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIP...

FlatpakLauncher.cpp: https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIP...

CF workers support nested agent isolates since 2026-03: https://blog.cloudflare.com/dynamic-workers/

dloss/awesome-agent-sandboxes: A curated list of sandboxing solutions for AI agents https://github.com/dloss/awesome-agent-sandboxes

Re: Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE

#62

Post by sbloz »

This looks nice, and I like the more opinionated take on how "communicating" with an agent should work.

The post talks a lot about what this is and how it works. I'm curious, from your usage of it, how does it change your way of working with the LLMs? How does working with it go differently from Claude Code?

Specifically: Everything is a tree. That's interesting, but how do you end up using it? Attack the same problem different ways?

Re: Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE

#64

Post by julesrms »

m_kos wrote: post #63

Nicely done! Would you consider adding an Agent SDK login for Claude for those who don't have an API budget and want to avoid potential issues with Anthropic's capricious policies around CLI use in third-party apps?

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)

Re: Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE

#65

Post by paldepind2 »

julesrms wrote: post #48
paldepind2 wrote: post #47

Earlier quoted context omitted.

Can you go more in depth on why LLM conversations should branch reddit-style? That doesn't seem immediately clear to me, and I'd be afraid that the different branches would step on each others toes? (also I'm assuming what you're describing here goes beyond the "fork" feature found in many agent harnesses).

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, an…

Ah, ok. Visibility into subagents makes perfect sense. From the "reddit-style" description I was imagining something where the user was conversing non-linearly with the agent at different points in some big tree.

Re: Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE

#66

Post by julesrms »

sbloz wrote: post #62

This looks nice, and I like the more opinionated take on how "communicating" with an agent should work. The post talks a lot about what this is and how it works. I'm curious, from your usage of it, how does it change your way of working with the LLMs? How does working with it go differently from Claude Code? Specifically: Everything is a tree. That's interesting, but how do you end up using it? Attack the same proble…

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!

Re: Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE

#68

Post by julesrms »

mannanj wrote: post #51

Interesting. Just opened it up to use, while I had a codex terminal session running - my first instinct was to want to see my pre-existing open session in the GUI instead and be able to drive it in either spot. Is that something I can do? Also when I opened a new session (in the Juggler GUI) at my root where all my projects live, my instinct was to navigate to a project directory first or to have it open there. Not s…

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

Re: Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE

#69

Post by alok-g »

julesrms wrote: post #2

Just wanted to add a follow-up to what I posted above.. In terms of who might be interested in this: I've watched amazing communities spring up around open agents like Opencode and Pi. People are getting into those because of their extensibility and being model-independant. They're great projects, but like many people I know, I really hate being stuck in the terminal for this kind of tool. I also had some ideas aroun…

Have you looked at Kilo code too. It is also model-independent but not terminal based. https://kilo.ai

PS: I agree that tree is a better approach than scroll chat, and other ideas Juggler has.

Re: Show HN: Juggler – an open-source GUI coding agent, by the creator of JUCE

#70

Post by sbloz »

julesrms wrote: post #66
sbloz wrote: post #62

This looks nice, and I like the more opinionated take on how "communicating" with an agent should work. The post talks a lot about what this is and how it works. I'm curious, from your usage of it, how does it change your way of working with the LLMs? How does working with it go differently from Claude Code? Specifically: Everything is a tree. That's interesting, but how do you end up using it? Attack the same proble…

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…

I see. That seems pretty similar to plan mode + "implement with subagents". The display for that in terminal apps is pretty bad, but it's low friction.

One more question around yDoc and remote access if you don't mind. Do you have thoughts on a tool like this for "LLM pair programming" or just general collaboration?

Working with teams on smaller projects with these tools is really hard because anyone can build anything. If I'm going to type up a bug or request to send to a team member to build I might as well send it to the LLM instead. A multi-user environment in a tool like this could be interesting. Seeing team members sessions in real time could be neat.

Post reply on HN