AI Deck

herdr vs. Superset ─ How Agent Multiplexers Differ, and Which One Fits You

  • AI
  • CodingAgent

AI coding agents have reached the practical stage, and the role of the terminal is starting to shift. It used to be the place where humans wrote code. Now it is becoming the place where you run several agents in parallel and review what they produce.

tmux and screen were designed around human multitasking. They have no idea what is happening inside a pane. Whether an agent is stalled waiting for approval or has already finished its work, the terminal sees the same thing: a process that is running.

To close that gap, a new kind of multiplexer has appeared ─ one that treats agents as first-class objects. There are two: herdr and Superset. The names come up side by side, but under the hood they are close to opposites. Let’s look at each architecture, then compare them along three axes: persistence, external control, and conflict avoidance.

herdr ─ a single binary that lives inside your existing terminal

herdr describes itself as an “agent multiplexer that lives in your terminal.” The line in its README ─ “one rust binary, no electron — runs in whatever terminal you already use” ─ sums up its position neatly.

It ships as a single Rust binary, with Rust accounting for 85% of the codebase. Rather than claiming to be a terminal app of its own, it launches inside the Ghostty, iTerm2, kitty, WezTerm, Alacritty, or Warp you already use. Linux and macOS are stable; Windows is in preview beta. The repository (ogulcancelik/herdr) was created on March 27, 2026, and as of July 2026 it has more than 15,000 stars. Development rests on a single maintainer, though ─ the classic bus factor of one.

One thing people get wrong is assuming herdr is “a tool for people who hate the mouse.” The opposite is true: it treats the mouse as a first-class citizen. You click to focus a pane, drag to resize, and drag-select text to have it copied to the clipboard automatically. Keyboard control runs through a tmux-style prefix (ctrl+b by default) as the primary path, but nothing about the design tries to take the mouse away from you.

Agent state, tracked across five values

What separates it from a plain pane splitter is that it tracks the state of the agent running in each pane. There are five states.

  • idle ─ finished, confirmed, and waiting
  • working ─ actively running
  • blocked ─ waiting for input, approval, or a decision
  • done ─ finished, but no human has looked at it yet
  • unknown ─ can’t be classified

These five values roll up through the sidebar. If even one agent is blocked, the entire pane, tab, and workspace shows as blocked, and done does not clear until a human confirms it. Even with ten panes open, “which one is waiting on me right now” collapses into a single line in the sidebar.

There are two detection methods, and they are used exclusively of each other, because the official docs state the design principle plainly: avoid dual sources of truth. The default is screen manifest detection, which identifies the pane’s foreground process and matches the lower part of the screen buffer against a TOML manifest to classify it. The other is lifecycle hooks; if hooks are installed, they become authoritative and screen detection is not run alongside them.

What’s interesting is that for Claude Code, Codex, GitHub Copilot CLI, Cursor Agent CLI, Droid, and Qoder CLI, herdr deliberately does not let hooks be authoritative. The official reasoning: those hooks don’t cover the full lifecycle and can miss things like the outcome of a permission prompt or an escape interrupt. State classification is left to screen detection, and the hooks supply only the session identity used for session restore. For Pi, OpenCode, Hermes Agent, and others, hooks do act as the authority.

The blocked determination is intentionally strict: it marks blocked only when the screen matches a known approval UI, and falls back to idle for unfamiliar UI shapes. If a verdict doesn’t sit right with you, herdr agent explain <target> will show you the final state, the type of authority used, the rule that matched, and the reason for any fallback. Note that if you launch tmux inside herdr, the agents inside that tmux won’t be detected.

Superset ─ bundling everything into a macOS desktop app

Superset is a desktop GUI app built with TypeScript and Electron. Its official engineering post, “The Terminal That (Almost) Never Dies: Building a Persistent Terminal Daemon for Electron,” lays out the architecture. macOS is the only supported OS right now; Windows and Linux are listed as coming soon.

The pitch is “Run 10+ parallel coding agents on your machine,” followed by “Each agent runs in its own isolated Git worktree. No merge conflicts, no stepping on each other’s changes.” It takes the collision problem of parallel agents head-on, and answers it with worktree isolation.

It stays neutral about agents, letting you invoke the major CLI agents across the board: Claude Code, Codex, Cursor Agent, OpenCode, Amp, Gemini CLI, GitHub Copilot, Droid, and more. As of July 2026 it has over 12,000 stars. The license is Elastic License 2.0 ─ the source is public, but it is not an OSI-approved open source license. Pricing comes in three tiers: Free, Pro ($20/seat/month), and Enterprise.

It has the features you’d expect from a GUI app: a diff viewer that takes you from review through stage, commit, and push in one UI (double-click a diff line and your editor opens at that spot), a Superset CLI with --json output and automatic CI environment detection, Automations that let you schedule recurring runs with RFC 5545 RRULE, and an In-App Browser for previewing your dev server.

Comparison 1. Session persistence

If you’re going to run agents for a long time, you want them to survive closing the app or the terminal. The two answers to that requirement reflect the architectural split directly.

herdr uses a server-client model. Detaching with ctrl+b q leaves your agents running, and herdr reattaches. The same holds over SSH, and named sessions are managed with herdr session list / attach / stop / delete <name>. Remote use comes in two flavors: the tmux-style approach of SSHing into the server and running herdr there, or herdr --remote ssh://you@server:2222, which turns your local herdr into a thin client streaming the remote UI.

It isn’t magic, though. Processes do not survive a server reboot. Layouts are restored, but screen contents come back only if you have pane screen history enabled, and conversations resume only if the agent itself supports native session restore.

What Superset solved was an Electron-specific problem. In a standard Electron plus node-pty setup, the PTY is spawned in the main process, so closing the app kills your sessions. Superset manages PTYs in an independent daemon detached from the main process over a Unix socket, so closing the app doesn’t kill them. Restart, and you reconnect straight to the sessions that are still running. That implementation is what the “(Almost) Never Dies” in the blog title refers to.

Comparison 2. Letting AI drive the tool

You want the agents themselves to operate the tool. Here too, the two answers contrast sharply.

herdr’s answer is a local socket API. It opens a Unix domain socket at ~/.config/herdr/herdr.sock and speaks NDJSON (newline-delimited JSON); on Windows it’s a named pipe. Run herdr api schema --json and you get the JSON Schema for every tool and event, with methods grouped into workspace / worktree / tab / pane / agent / events / plugins namespaces. There are three layers of access: an Agent skill that teaches the agent inside a pane how to use it, a CLI wrapper for shell scripts and human debugging, and the raw socket API for custom tools and long-lived event subscriptions.

Actual commands look like this.

Terminal window
herdr agent start reviewer --cwd ~/project --split right -- pi
herdr pane split --direction right
herdr wait agent-status w1:p1 --status done
herdr pane run w1:p2 "npm test"
herdr pane read w1:p2 --source recent --lines 50
herdr notification show "build failed" --body "api workspace" --sound request

Feed the official SKILL.md to your agent with npx skills add ogulcancelik/herdr --skill herdr -g, and the agent inside a pane can split the pane next to it, launch another agent there, wait for it to finish, and read its logs. Agents calling agents. As a guard against runaway behavior, agents refuse to operate herdr unless the environment variable HERDR_ENV=1 is set. Plugins can hook events like worktree.created via herdr-plugin.toml.

Superset’s external interface is MCP, but not as a local server embedded in the app. It’s offered as a cloud HTTP endpoint (https://api.superset.sh/api/v2/agent/mcp). The exposed tools are tasks_* / workspaces_* / agents_* / terminals_create / automations_* / projects_list ─ there are no tools for editing files.

That difference matters. herdr’s API is for operating the workspace inside your terminal; Superset’s MCP is for operating higher-level management units like tasks and workspaces. If the word “MCP” makes you picture agents rewriting files directly, the reality won’t match.

Comparison 3. Avoiding conflicts

Run several agents against the same repository and, naturally, they collide. This is the area Superset pushes hardest on.

Superset automatically isolates each agent in its own git worktree. It grows worktrees on top of your existing local repository, so there’s no need to re-clone. On top of that, the setup field in .superset/config.json lets you automate things like dependency installation whenever a worktree is created.

One gotcha: dropping in a .superset/setup.sh does not make it run automatically. You have to call it explicitly from the config.

{
"setup": ["./.superset/setup.sh"]
}

Configuration resolves across three levels ─ worktree, repository, and user home ─ and config.local.json lets you layer on personal extensions. Reviewing those isolated branches falls to the diff viewer, so the whole flow stays inside the GUI.

herdr isn’t without worktree management either. herdr worktree create --branch NAME is built in. On Hacker News it was even called out as “the killer feature is git worktree management,” so treating this as a weakness would be inaccurate.

What herdr gives you, though, stops at the ability to cut a worktree. There’s no automatic file locking or mutual exclusion; everything past that point is left to you. There’s no jj (Jujutsu) support ─ git worktree only.

Comparison table

AxisSupersetherdr
App formTypeScript / Electron desktop GUISingle Rust binary (a TUI running inside your existing terminal)
OS supportmacOS onlyLinux / macOS stable, Windows in preview beta
LicenseElastic License 2.0 (source-available)AGPL-3.0-or-later plus commercial dual license
PricingFree / Pro $20/seat/month / EnterpriseAGPL build is free. Commercial by inquiry
PersistencePTYs in an independent daemon detached from the main processServer-client model. Survives detach, reattach over SSH
External controlCloud HTTP MCP endpointLocal Unix domain socket (NDJSON)
Conflict handlingEach agent auto-isolated in its own worktreeCut worktrees with herdr worktree create (no automatic file locking)
State visibilityGUI dashboardFive states rolled up into the sidebar (idle / working / blocked / done / unknown)
GitHub stars (July 2026)12,000+15,000+

The “isn’t tmux enough?” question

There are two Hacker News threads about herdr. “Herdr: One terminal to rule them all” drew roughly 400 points and over 170 comments; “Herdr: Agent multiplexer that lives in your terminal” drew roughly 170 points and over 110 comments. The reception was not uniformly enthusiastic.

The question that came up most was “why won’t tmux or zellij do?” A large share of replies argued you could get the same thing with bell notifications and status bar hooks.

One level-headed summary made the rounds: you can click everything with the mouse, there’s a tmux-style popup UI, agent state is displayed, selection copies to the clipboard automatically, remote SSH attach is easy, and it looks good ─ beyond that, it’s pretty much tmux. That’s a realistic baseline expectation to carry into any evaluation of herdr.

There were criticisms too: reports of perceptible input latency, the constraint of git worktree only with no jj support, and the lack of declarative layout startup along the lines of tmuxinator. A “vibecoded” (i.e. just written by AI) argument broke out as well.

Which one to pick

Rather than staring at a feature table, you’ll decide faster by reasoning backward from where you work and what constrains you.

herdr suits you if:

  • You already work inside the terminal and want to keep using the terminal you know
  • Linux is your main platform, or you want to use it on Windows (Superset is macOS-only)
  • You want agents to keep running on the far side of an SSH connection or on a server
  • You want to assemble your own workflow out of shell scripts and a socket API

Superset suits you if:

  • You want everything in one GUI window, and you’re on macOS
  • You want to review in a visual diff viewer and finish stage, commit, and push on the same screen
  • You want your team standardized on one tool (Pro is $20/seat/month)

A note for organizations with license review

Neither one is necessarily “open source, so drop it in freely.”

herdr is dual-licensed under AGPL-3.0-or-later and a commercial license. The AGPL build is free, but AGPL tends to trigger review at companies. Google’s public policy declares an “aggressively-broad ban” on AGPL software and forbids installing AGPL-licensed programs on work machines without permission from its Open Source Programs Office. If you want it for work, a commercial license inquiry becomes one of your options.

Superset’s Elastic License 2.0 lets you read the source, but it is not an OSI-approved open source license either. Whether you’re using it as a personal dev environment or installing it on a company machine ─ that single question changes the paperwork you need.

Closing thoughts

Until now, the awkwardness of AI agents has been papered over by humans doing shell gymnastics. Arranging panes by hand, eyeballing when something finished, cutting branches so nothing collides. That manual work is starting to be absorbed by the infrastructure layer, the multiplexer ─ that’s the shift herdr and Superset are pointing at.

Still, it’s worth remembering that the most common reaction on Hacker News was “isn’t tmux enough?” The line “beyond that, it’s pretty much tmux” reads like a putdown, but it’s also an accurate summary. The delta is small. Whether that small delta pays off in the daily reality of running several agents at once depends on your workload and where you work.

Start by naming one thing that’s actually annoying in your current setup. If it’s “I can’t tell which agent is waiting on me,” herdr’s state display helps. If it’s “my branches keep colliding,” Superset’s automatic worktrees help. If neither describes you, “stick with tmux” is a perfectly reasonable conclusion.


References

← Blog