Show HN: Superset – Terminal to run 10 parallel coding agents
96 points| avipeltz | 2 months ago |superset.sh
- Superset makes it easy to spin up git worktrees and automatically setup your environment
- Agents and terminal tabs are isolated to worktrees, preventing conflicts
- Built-in hooks [0] to notify when your coding agents are done/needs attention,
- A diff viewer to review the changes and make PRs quickly
We’re three engineers who’ve built and maintained large codebases, and kept wanting to work on as many features in parallel as possible. Git worktrees [1] have been a useful solution for this task but they’re annoying to spin up and manage. We started superset as a tool that uses the best practices we’ve discovered running parallel agents.
Here is a demo video:
https://www.youtube.com/watch?v=pHJhKFX2S-4
We all use Superset to build Superset, and it more than doubles our productivity (you’ll be able to tell from the autoupdates). We have many friends using it over their IDE of choice or replacing their terminals with Superset, and it seems to stick because they can keep using whatever CLI agent or tool they want while Superset just augments their existing set of tools.
Superset is written predominantly in Typescript and based on Electron, xterm.js, and node-pty. We chose xterm+node-pty because it's a proven way to run real PTYs in a desktop app (used by VSCode and Hyper), and Electron lets us ship fast. Next, we’re exploring features like running worktrees in cloud VMs to offload local resources, context sharing between agents, and a top-level orchestration agent for managing many worktrees or projects at once.
We’ve learned a lot building this: making a good terminal is more complex than you’d think, and terminal and git defaults aren’t universal (svn vs git, weird shell setups, complex monorepos, etc.).
Building a product for yourself is way faster and quite fun. It's early days, but we’d love you to try Superset across all your CLI tools and environments, we welcome your feedback! :)
amortka|2 months ago
hoakiet98|2 months ago
101008|2 months ago
Most of these agents solutions are focusing on git branches and worktrees, but at least none of them mention databases. How do you handle them? For example, in my projects, this means I would need ten different copies of my database. What about other microservices that are used, like redis, celery, etc? Are you duplicating (10-plicating) all of them?
If this works flawlessly it would be very powerful, but I think it still needs to solve more issues whan just filesystem conflicts.
avipeltz|2 months ago
For example: • if you’re using Neon/Supabase, your setup script can create a DB branch per workspace • if you’re using Docker, the script can launch isolated containers for Redis/Postgres/Celery/etc
Currently we only orchestrate when they run, and have the user define what they do for each project, because every stack is different. This is a point of friction we are also solving by adding some features to help users automatically generate setup/teardown scripts that work for their projects.
We are also building cloud workspaces that will hopefully solve this issue for you and not limit users by their local hardware.
jitl|2 months ago
For my current project (Postgres proxy like PGBouncer) I had Claude write a benchmark system that’s worktree aware. I have flags like -a-worktree=… -b-worktree =… so I can A/B benchmark between worktrees. Works great.
jpalomaki|2 months ago
For some cases test-containers [1] is an option as well. I’m using them for integration tests that need Postgres.
[1] https://testcontainers.com/
reactordev|2 months ago
For databases, if you can’t see a connection string in env vars, use sqlite://:memory and make a test db like you do for unit testing.
For redis, provide a mock impl that gets/sets keys in a hash table or dictionary.
Stop bringing your whole house to the camp site.
desireco42|2 months ago
scottydelta|2 months ago
Recently I gave Catnip a try and it works very smoothly. It works on web via GitHub workspaces and also has mobile app. https://github.com/wandb/catnip
How is this different?
saddlepaddle|2 months ago
The mobile app is a pretty cool feature though - will definitely take a peek at that soon.
avipeltz|2 months ago
thorum|2 months ago
dgunay|2 months ago
mlnj|2 months ago
sathish316|2 months ago
Parallel agents are useful for:
1. Offloading minor refactoring work
2. Offloading non-overlapping features
3. Offloading unit or integration test additions
4. Exploring multiple ways to build a feature with maybe different coding models
5. Seeing how Claude code thinks for extremely ambitious ideas and taking only the gist of it
Most of these tools don’t make working with Git merges or conflicts to main simpler in their UX. Even in Cursor, it helps to be good at using git from the command line to use Parallel agents effectively (diff, patch, cherry-pick from worktree to main etc)
saddlepaddle|2 months ago
For bug fixes and quick changes I can definitely get to 5-7 in parallel, but for real work I can only do 2-3 agents in parallel.
Human review still remains the /eventual/ bottleneck, but I find even when I'm in the "review phase" of a PR, I have enough downtime to get another agent the context it needs between agent turns.
We're looking into ways to reduce the amount of human interaction next, I think there's a lot of cool ideas in that space but the goal is over time tools improve to require less and less human intervention.
Leynos|2 months ago
eigenvalue|2 months ago
I’ve been able to productively run 12+ agents from CC, Codex, Gemini-cli at the same time this way and it works really well.
avipeltz|2 months ago
agentifysh|2 months ago
saddlepaddle|2 months ago
jgalt212|2 months ago
nateb2022|2 months ago
avipeltz|2 months ago
But it on the roadmap and glad to know theres interest there :)
sathish316|2 months ago
Superset will be a good alternative for someone who is using only ClaudeCode or CLIs. But for someone using Cursor, How does this differ from Cursor’s Agents UI, which supports local background agents using Git worktrees?
saddlepaddle|2 months ago
I'd need to do a refresher but for Cursor agents you can choose any model but you're tied to their tooling right? I've heard they're really solid I just find people have their cli preferences and being terminal-first let's anyone bring their favorite agent along for the ride
xmonkee|2 months ago
saddlepaddle|2 months ago
I liked this video a lot for a general idea of how it's possible, the main thing we need for 10 agents at once to be possible is less of a need for human intervention for agents, but I think it'll happen sooner (it may even be possible now with the right tools) than later.
https://youtu.be/o-pMCoVPN_k?si=cCBqufdg3nWcJDHD
kaffekaka|2 months ago
I feel that maybe a couple of things in parallel could be useful at certain times, but more often the need is not for "one more jira ticket in the pipeline" but rather things like meetings, discussing strategy, clarifying things so they can be built at all as opposed to actually having ten crystal clear tasks to unleash the bot army on.
kridsdale1|2 months ago
maxdo|2 months ago
It is really hard to justify tools like these, where you need CC+this tool+ some other tools to make it more productive , and you need to deal with billing where cursor gives you access to all models possible + BYOK.
Not trying to be negative ... but why hustle?
saddlepaddle|2 months ago
theturtletalks|2 months ago
Conductor
Chorus
Vibetunnel
VibeKanban
Mux
Happy
AutoClaude
ClaudeSquad
All of these allow you to work on multiple terminals at once. Some support work trees and others don’t. Some work on your phone and others are desktop only.
Superset seems like a great addition!
ahmadyan|2 months ago
scottydelta|2 months ago
avipeltz|2 months ago
kridsdale1|2 months ago
kimos|2 months ago
hoakiet98|2 months ago
kaffekaka|2 months ago
This kind of workflow feels a lot like "making the horse ten times faster", instead of using the power of AI to make developers stronger to build things that were previously too difficult or not worth the effort.
I guess I don't really see the intersection of "simple enough for parallel agents" vs "valuable enough to be worth the parallelization overhead".
smoyer|2 months ago
saddlepaddle|2 months ago
I do tend to like the niceties of our GUI tho, if you get a chance to compare your cli / our GUI would love to hear what you think!
sathish316|2 months ago
https://gist.github.com
fragmede|2 months ago
hoakiet98|2 months ago
onion2k|2 months ago
hoakiet98|2 months ago
memoriuaysj|2 months ago
I have my own VM's with agents installed inside, is there a tool which supports calling a codex/claude in a particular directory through a particular SSH destination?
Basically BringYourOwnAgentAndSandbox support.
Or which supports plugins so I can give it a small script which hooks it up to my available agents.
saddlepaddle|2 months ago
scottydelta|2 months ago
Since it’s open source and based on GitHub workspaces, it’s free and works very smoothly.
avipeltz|2 months ago
bingemaker|2 months ago
avipeltz|2 months ago
For more complex setups if your app has hardcoded ports or multiple services that need coordination you can use setup/teardown scripts to manage this. Either dynamically assigning ports or killing the previous server before starting a new one (you can also kill the previous sever manually).
In practice most users aren't running all 10 agent's dev servers at once (yet), you're usually actively previewing 1-2 at at time while the other are working (writing code, running tests, reviewing, etc). But please give it a try and let me know if you encounter anything you want us to improve :)
normie3000|2 months ago
unknown|2 months ago
[deleted]
roggenbuck|2 months ago
saddlepaddle|2 months ago
avipeltz|2 months ago
kridsdale1|2 months ago
saddlepaddle|2 months ago
nickphx|2 months ago
hmokiguess|2 months ago
hoakiet98|2 months ago
Agent_Builder|2 months ago
[deleted]
basemi|2 months ago
https://superset.apache.org/
avipeltz|2 months ago
lesser-shadow|2 months ago
[deleted]