# Superset: an agentic IDE that runs 100+ coding agents in parallel worktrees > Superset is a macOS desktop app and CLI from superset-sh that puts each CLI coding agent in its own git worktree. It is built for engineers already paying for Claude Code, Codex or similar, and it costs you a git worktree per task. **superset-sh/superset** — Superset is an agentic IDE to orchestrate 100+ coding agents in parallel. Run any agent with your own subscription. - Repository: https://github.com/superset-sh/superset - Website: https://superset.sh - Stars: 14,636 · Forks: 1,309 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/superset-sh-superset ## The problem Superset solves: one agent is fast, five agents is bookkeeping Running a single CLI coding agent is easy. Running five of them on the same repository is not, because they all want the same checkout. You end up stashing, switching branches, and losing track of which terminal holds which task. Superset's answer is to give every task its own git worktree with its own branch, terminal and environment, then put a sidebar, a diff viewer and a terminal in front of all of them. The README states the app runs CLI-based agents such as Claude Code and Codex, and that you run them with your own subscription rather than through a Superset-hosted model key. That last point defines the audience. Superset is not a model provider and does not sell inference. It is a control surface for agents you already have credentials for. If you have never installed a CLI agent, Superset has nothing to drive. If you have three of them and a backlog, the worktree isolation is the feature that matters, because two agents editing the same file in the same working directory is the failure mode it removes. ## How the worktree-per-task model actually works The architecture visible in the repository is a monorepo: apps/ and packages/ at the top level, with turbo.jsonc, bun.lock and a packageManager field pinned to bun@1.3.14 in package.json. The dev script filters on @superset/api, @superset/web and @superset/desktop, so the desktop app, a web surface and an API are separate build targets, and a relay app exists too (dev:relay filters @superset/relay). The isolation itself is git-native. Each workspace is a worktree, so the agent's edits land on a branch that no other agent shares. The README describes the flow as: run agents in parallel, watch them in the sidebar, review changes in the built-in diff viewer, then commit and push. The CLI is the second entry point into the same system, and the README says it can create workspaces, launch agents, read their terminals and manage automations, with the framing that if an agent can run a command, it can drive Superset. Remote access is the third path. The README describes connecting another machine and reaching its workspaces from the desktop app, the CLI or a phone, plus waking offline hosts with a custom command. docker-compose.yml shows what backs a self-hosted setup: postgres:17, a local Neon HTTP proxy on port 4444, redis:7-alpine, and a serverless-redis-http shim on port 8079 whose comment explains that @upstash/redis speaks Upstash's HTTP REST protocol rather than the Redis wire protocol. That comment is the most informative line in the repository about how the hosted pieces fit together. ## Installing Superset and creating your first workspace The README's primary install path is a download, not a package manager command. It links to the latest GitHub release with the label Download for macOS, so the desktop app is distributed as a release artifact and macOS is the platform the README advertises. The topics list also names macos. There is no documented Windows or Linux desktop build in the repository. For CLI use, releases are versioned separately from the desktop app. The release list shows desktop-v1.28.0 and cli-v1.28.0 both published on 2026-09-09, plus a desktop-canary channel published on 2026-09-10. Documentation lives at docs.superset.sh, and the CLI getting-started page is at docs.superset.sh/cli/getting-started. The README does not print the install command for the CLI binary, so check that page rather than guessing at a package name. If you want to run the stack from source, the repository states its own requirements. The dev scripts below come from package.json and expect Bun at the pinned version. ```bash # from package.json: packageManager is bun@1.3.14 bun install ``` The postinstall hook runs ./scripts/postinstall.sh. For a local environment the .env.example file is explicit that you do not need production values: it says to run ./.superset/setup.local.sh or copy .env.local.example to .env, which uses fake-but-valid placeholders and a local Postgres container. ```bash cp .env.local.example .env ./.superset/setup.local.sh ``` Bring up the supporting services with the compose file. Ports are parameterised, so LOCAL_PG_PORT, LOCAL_NEON_PROXY_PORT, LOCAL_REDIS_PORT and LOCAL_SRH_PORT can be overridden. ```bash docker compose up -d ``` Then start the desktop-oriented dev target, which the predev:desktop script guards with a port check. ```bash bun run dev:desktop ``` What you should see: the port check script runs first, then turbo starts the @superset/api and @superset/desktop targets alongside the root package. Once the app is up, the README's workflow is to create a workspace, which creates the worktree and branch, then launch an agent inside it and watch the sidebar status change from working to done. ## Where Superset gets in the way The worktree model has a cost the README does not discuss. Every workspace is a separate checkout with its own terminal and environment, so a task that touches a large dependency tree multiplies that cost by the number of agents you run. The README states the target of 100+ agents and does not state a resource ceiling, so the practical limit is your machine, and you will find it by running out of disk or CPU rather than by reading a documented number. Second, the platform story is narrow. The download link says macOS, the topics list says macos, and nothing in the repository describes a Windows or Linux desktop client. If your team is on Windows, the desktop app is not an option today. Third, the licence is not a standard permissive one. The README badge reads Elastic License 2.0, package.json declares "license": "Elastic-2.0", and the repository metadata reports NOASSERTION because the LICENSE.md text is not a recognised SPDX identifier. Elastic License 2.0 is source-available, not open source in the OSI sense, and it restricts offering the software as a hosted service. That is a real constraint for a platform team, not a formality. Finally, the documentation is uneven. The README links to docs.superset.sh for workspaces, agent integration, terminal, diff viewer, browser, automations, remote access, CLI and keyboard shortcuts, but the README itself does not document rollback of a workspace, conflict handling when two agents touch the same file, or what happens to a worktree when an agent is killed mid-task. Treat those as unverified until the docs say otherwise. ## Superset compared with a plain git worktree script The honest alternative is not another agentic IDE. It is a shell script: git worktree add for each task, a tmux session per worktree, and your terminal's own diff tool. That approach has no licence, no Electron app and no release channel, and it works on any platform git runs on. What it lacks is the parts Superset builds around the worktrees: the sidebar that shows which agent is working and which is done, the completion chimes and dock badges, the in-app diff viewer with commenting, per-workspace port detection for dev server previews, and the CLI that lets one agent drive another workspace. The trade is maintenance. A worktree script is yours to keep working; Superset is a product with its own release cadence, and the release list shows desktop and CLI versioned separately, with a canary channel alongside stable. If you need cross-platform parity or a permissive licence, the script wins. If your bottleneck is watching ten terminals and remembering which one finished, the monitoring and diff layers are the reason to take on a dependency. ## Maintenance cadence, licence and upgrade cost The repository is not archived, and the last push was on 2026-09-10, so this is a project that is being worked on right now. Releases follow a desktop and CLI split: desktop-v1.28.0 and cli-v1.28.0 on 2026-09-09, and a desktop-canary build on 2026-09-10. The canary channel means you can opt into pre-release desktop builds, which is useful if you are tracking a fix and risky if you are not. Upgrade cost is mostly a function of how you installed it. The desktop app updates through its release artifacts, so you re-download or let the app update itself; the README does not describe an auto-update mechanism, so verify that before rolling it out to a team. The CLI is a single binary per the README, and it has its own version line, so a desktop upgrade and a CLI upgrade are two separate decisions. If you build from source, you are pinned to bun@1.3.14 and the dependency set in package.json, including turbo 2.10.9 and typescript 6.0.3, and you inherit the postinstall script on every install. On licensing, the operative fact is that the project declares Elastic-2.0 in package.json and shows an Elastic License 2.0 badge in the README, while the repository metadata reports NOASSERTION. Elastic License 2.0 permits use and modification but restricts providing the software to others as a hosted or managed service. If you plan to embed Superset in something you sell, read LICENSE.md yourself. This is a description of what the files say, not legal advice. ## Conclusion Adopt Superset if you already run several CLI agents by hand and lose time on branch juggling, because the worktree-per-task model and the CLI are the parts that pay off. Skip it if you are on Windows, if you want an Apache-licensed BI tool, or if a single agent at a time is enough. Before trusting it, verify two things yourself: that the release you download matches the desktop-v1.28.0 or cli-v1.28.0 line you intend to run, and that your machine has the disk and CPU headroom for one worktree and one agent process per task, since the README states 100+ agents is the target and does not state a ceiling. ## FAQ ### How do I install Superset? The README's install path is a macOS download link pointing at the latest GitHub release, with documentation at docs.superset.sh. For source builds the repository expects Bun at the pinned version bun@1.3.14, and the .env.example file directs local development to ./.superset/setup.local.sh or a copy of .env.local.example. ### How do I use Superset? The README's workflow is to create a workspace, which gives the task its own git worktree, branch, terminal and environment, then launch a CLI agent such as Claude Code or Codex inside it. You watch agent status in the sidebar, review changes in the built-in diff viewer, and commit and push from there. ### How do I use the Superset app? The desktop app is the primary surface: parallel workspaces, a sidebar with working indicators and dock badges, a terminal with tabs and splits, a diff viewer, an in-app browser with per-workspace port detection, and scheduled automations. The README also describes remote access from the desktop app, the CLI or a phone. ### What is Superset in coding? In this project, Superset is an agentic IDE that orchestrates CLI coding agents in parallel, each isolated in its own git worktree so agents do not interfere with each other. The README frames it as running Claude Code, Codex or any CLI agent side by side and merging the winning branch. ### How do I install Superset on Windows? There is no documented Windows desktop build. The README's download link is labelled Download for macOS, the topics list names macos, and nothing in the repository describes a Windows client, so the desktop app is not available there as far as the project states. ### How do I use the Superset dashboard? The README does not describe a dashboard. The closest surfaces it documents are the sidebar that tracks every agent's status and the built-in diff viewer for reviewing changes, both inside the desktop app rather than a separate web dashboard. ## Sources - [Issues](https://github.com/superset-sh/superset/issues) - [Project website](https://superset.sh) - [README](https://github.com/superset-sh/superset/blob/main/README.md) - [Releases](https://github.com/superset-sh/superset/releases) - [superset-sh/superset on GitHub](https://github.com/superset-sh/superset) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/superset-sh-superset