Herdr vs pi vs tmux: Which Agent Harness Should You Run?

Official Sources#

Last updated: September 28, 2026

Pick by fleet size. For one or two agents, use pi (or any single agent) in plain tmux panes. Add Herdr when you run four or more agents from several vendors and are tired of polling panes, because it classifies each agent as working, blocked, idle, or done and lets scripts wait on that state. Keep pi as the agent inside Herdr rather than choosing between them: pi is a coding agent, tmux is a multiplexer, and Herdr is a multiplexer that understands agents, so they are not direct rivals.

On August 22, 2026, an Ask HN post put the sharpest possible question to the Herdr hype cycle: "Does herdr worth it? Harnesses like pi ship most of these features." The asker's argument, in full: "What's the gap it fills that they don't? Agent Multiplexing (per tab) is already implemented in claude code, codex, pi (with plugins)." The thread collected one substantive reply - "Harnesses are the new Javascript web framework hotness" - and little else. One point, one joke, one genuinely hard question.

This is Part 3 of our Herdr series, and it is the honest one. Feature claims trace to documentation fetched August 23, 2026 and re-checked against Herdr's current agent docs on September 28; star counts, versions, and licenses were refreshed September 28. Where a cell in a comparison is not documented by the vendor, it says so. We also cover where Herdr loses outright, because it does.

First, untangle the categories#

The HN question quietly compares three things that are not the same kind of object:

• tmux is a terminal multiplexer. It manages panes, windows, and sessions. It knows nothing about what runs inside a pane.
• pi is a coding agent. The repo describes "an AI agent toolkit: unified LLM API, agent loop, TUI, coding agent CLI." One pi process drives one agent session. Its own README is explicit that it is not a multiplexer: "No sub-agents. There's many ways to do this. Spawn pi instances via tmux, or build your own with extensions." And: "No background bash. Use tmux. Full observability, direct interaction."
• Herdr is a terminal multiplexer that tries to understand its contents. Its self-description: "the runtime your coding agents live on." It tracks which panes hold agents and classifies each as working, blocked, idle, or done.

So the real question is not "which one wins." It is: when you run several agents at once, who assembles the fleet - you, with scripts, on top of tools that stay ignorant of each other - or a layer that claims to know what an agent is?

Notably, pi's official answer to "how do I run five pis" is literally tmux (see also our take on CLIs over MCPs). That partially vindicates the HN asker before the comparison even starts. What it does not settle is the cost of the glue, which is where the differences live.

The contenders#

pi: the minimal harness that refuses to be a platform#

pi (earendil-works/pi) sits at 110,079 stars as of September 28, 2026 - about 2.7 times Herdr's count. It is a TypeScript monorepo shipping five packages: the coding-agent CLI, an agent runtime (pi-agent-core), a unified multi-provider LLM API (pi-ai, covering Anthropic, OpenAI, Google, DeepSeek, xAI, OpenRouter, and dozens more, plus subscription logins for Claude Pro/Max, ChatGPT Plus/Pro, and GitHub Copilot), a differential-rendering TUI library, and telemetry contracts.

Its verified feature surface relevant to this debate:

• Four run modes: interactive TUI, print/JSON (-p, --mode json), RPC over stdin/stdout (--mode rpc), and an embeddable SDK. This matters enormously - a pi process can report its own state as structured events instead of being inferred from screen pixels.
• Session trees: JSONL session files with branching (/tree, /fork, /clone), manual and automatic compaction, steering and follow-up message queues while the agent works.
• Extension system: TypeScript modules that can register custom tools and commands, add sub-agents and plan mode, build permission gates, add MCP support, or replace the editor UI. Shared as npm or git "Pi Packages."
• Deliberate omissions: no MCP client, no sub-agents, no permission popups, no plan mode, no built-in to-dos, no background bash. The README argues each omission keeps the core minimal and lets you shape your own workflow.

Two caveats cut against it in a fleet context. First, pi ships no built-in permission system at all - the docs tell you to containerize it (Docker, a Gondolin micro-VM, or OpenShell). Second, everything multi-agent is DIY by design: extensions can build it, packages might provide it, but nothing in the core spawns, names, watches, or waits on other agents.

Herdr: the multiplexer that claims to know what an agent is#

Herdr (herdrdev/herdr) sits at 41,257 stars, is written in Rust, ships as one binary under Apache-2.0, and its latest release is v0.9.1 (September 16). The architecture: a background server owns the terminals; your terminal is a client. Close the lid, drop the network, kill the client - panes keep running, and the server restores session shape after a full restart.

The parts that matter for the comparison:

• Agent detection with a status authority chain. For each pane, Herdr identifies the foreground process, then classifies lifecycle state using per-agent TOML "screen manifests" matched against the live bottom-of-buffer snapshot, upgraded to authoritative hook reports when an agent's integration is installed. Manifest updates arrive from herdr.dev automatically without a restart (disable with [update] manifest_check = false). Local overrides go in ~/.config/herdr/agent-detection/<agent>.toml.
• Breadth: the launch list supports 24 agent kinds - including pi itself - and the detection table covers around two dozen CLIs, from Claude Code and Codex to Kimi, Droid, and Qwen Code. Unsupported agents still run as ordinary terminal processes.
• Automation primitives: pane run, pane send-text, pane send-keys, pane wait-output --regex; and agent-level agent start --kind, agent prompt --wait --until idle|done|blocked, agent wait, agent read. Waits resolve against the classified lifecycle, not raw text. When an agent prompt targets a blocked agent, Herdr returns agent_blocked instead of typing into a dialog.
• Rollups and attention routing: state rolls up from pane to tab to workspace in a sidebar. A blocked agent makes its whole workspace look blocked. The stated workflow: start several agents, walk away, look at the sidebar to see which project needs a decision.
• Remote and embedded surfaces: herdr --remote workbox turns your local install into a thin client over SSH (bridging even image paste into the remote session), named sessions isolate independent servers, and a read-only terminal session observe stream emits framed ANSI records for third-party bridges - which is exactly what Multiplex, a 15-star Swift client for Vision Pro, iPad, and iPhone, consumes alongside tmux and plain SSH.

tmux + scripts: the baseline that keeps winning by default#

Any honest comparison starts from what a competent tmux setup already delivers in 2026: persistent sessions that survive disconnects, send-keys for scripted input, capture-pane for reading output, status bars, hooks and run-shell for automation, and a control mode (tmux -C) that desktop clients integrate against. Twenty years of maturity means it is on every server you SSH into, its behavior is fully documented and boringly stable, and it adds no new trust surface to your machine.

What tmux structurally cannot do, no matter how good your dotfiles are:

• Completion semantics. tmux does not know what "done," "blocked," or "waiting for permission" mean. You get bytes. Detecting that Claude Code finished a turn means capturing the pane and grepping for whatever string your agent currently renders - a regex you maintain against someone else's UI updates.
• Notification policy across agents. Activity flags and terminal bells are per-pane and content-blind. There is no notion of "this workspace contains a blocked agent that has been waiting eleven minutes."
• Cross-agent vocabulary. Every agent draws its idle state differently. Scripts normalize them one grep at a time, and each agent update is a small outage for your glue.

That is precisely the gap Herdr productizes. The question the HN thread really asks is whether that gap is worth a new dependency.

Capability matrix#

Capability claims below come from each project's own documentation, fetched August 23, 2026. "Not documented" means we could not verify it in the official sources above.

Note on the stars row: tmux predates GitHub stars culture and lives on its own infrastructure, so the number is omitted rather than invented. The honest reading of the two modern counts: pi is currently the far larger project; Herdr is the smaller, newer, faster-moving one (releases have moved from 0.5.x to 0.9.1 within a few months).

One more landscape data point. Zellij (35,582 stars) is the other multiplexer people name in this conversation. Its core remains a general-purpose workspace - agent awareness arrives only through third-party plugins like zj-radar (a sidebar showing Claude Code and Codex status) and zellij-claude-teams (a tmux shim). Nothing agent-native is built in. Meanwhile Claude Code and Codex continue adding their own parallel-session features, which is the trend the HN asker leaned on - but those are per-vendor silos. Neither tells you anything about the other tool running in the next pane.

Who should pick what#

The synthesis the HN thread missed: pi and Herdr compose because they attack opposite halves of the problem. pi makes one agent excellent and self-reporting; Herdr makes twenty heterogeneous agents legible. The asker's claim that pi "with plugins" ships Herdr's features is true only in the sense that TypeScript is Turing-complete - the extensions can express it, but you would be building, testing, and maintaining a private multiplexer. Whether that is worth avoiding depends entirely on fleet size. If you are heading toward a fleet, the Intro to Agents 101 course covers the orchestration, approval-gate, and sandboxing patterns that make many-agent systems manageable.

The honest case against Herdr#

If this piece were marketing, it would end above. It is not, so here is where Herdr loses, fairly stated:

1. It watches terminals; it does not understand agents. Classification is inference. The docs are candid that blocked detection is deliberately strict - an unfamiliar approval prompt shows as idle, not blocked, until a manifest learns that screen shape. Misclassification affects visible status and waits, though the docs state it should not cause Herdr to send input or act destructively. pi's JSON/RPC modes, by contrast, report state from inside the process. Ground truth beats inference whenever both exist - Herdr's own hook system is an admission of this.
2. It phones home by default. Automatic remote manifest checks hit herdr.dev without a restart gate. It is opt-out ([update] manifest_check = false) and it is detection rules rather than code execution, but a default network dependency for classification behavior deserves scrutiny, especially next to pi's aggressively pinned, shrinkwrapped supply chain.
3. It is young and moving fast. A release cadence that took it from 0.5.x to 0.9.1 in a few months, a YC-stage company behind it, and a plugin marketplace that has not launched yet. APIs this fresh churn. Anything you script against agent prompt --wait today is a bet on the project's trajectory - which is exactly what our earlier ecosystem analysis weighed.
4. Most of it is dead weight for small fleets. If you run one or two agents and enjoy the cockpit, Herdr sells you a solution to a problem you do not have. The deadeye reply on the thread - harnesses as the new JavaScript framework churn - lands hardest here. New layers need problems that are real, not aspirational.
5. It does not escape tmux's shadow. The docs support running Herdr inside tmux as the outer environment. That is pragmatic, and also a reminder: the 20-year-old incumbent still frames the category, and Herdr has to justify replacing something free, universal, and stable rather than merely improving on it.

None of these kill the product. They define its honest boundary: Herdr wins when heterogeneity and scale make manual glue expensive, and loses when they do not.

FAQ#

Is pi a competitor to Herdr?#

Not directly. pi is a coding agent - one process driving one agent session across dozens of providers. Herdr is a multiplexer that hosts many agents in persistent panes and classifies their state. They overlap only in the phrase "agent harness." Herdr's own documentation treats pi as a supported resident: it can launch pi with --kind pi, read its lifecycle, and restore its sessions.

Does Herdr replace tmux?#

Functionally yes for agent fleets - detach, reattach, panes, and a ctrl+b prefix all work as tmux users expect. Literally no: Herdr documents running inside tmux as an outer environment, and tmux remains the right tool where ubiquity and stability matter more than agent awareness.

Can Herdr manage pi agents?#

Yes, and unusually well. Herdr's agents table grants pi "lifecycle hooks when installed; otherwise screen manifest" authority with both state and session roles - the same tier as its Claude Code and Codex support. Running pi inside Herdr pairs pi's structured internals with Herdr's fleet view.

What was the Hacker News thread actually asking?#

Ask HN user abeauvois asked whether Herdr is worth it given that Claude Code, Codex, and "pi (with plugins)" already implement per-tab agent multiplexing. The thread drew one notable reply joking that harnesses are the new web frameworks. Our verdict: the premise is half right - pi ships the pieces, not the product, and the per-vendor tab features in Claude Code and Codex do not span tools.

Do I need Herdr if Claude Code already runs agents in tabs?#

Only if you run agents from more than one vendor. Native tabbing is a silo: it knows about Claude Code sessions, not the Codex or Gemini CLI pane beside them. Herdr's entire value proposition is a uniform state vocabulary across heterogeneous agents.

What can tmux still do that Herdr cannot?#

Be everywhere and never surprise you. tmux is preinstalled or one command away on effectively every server, its behavior is frozen-solid and fully documented, and it carries no vendor network calls. If your scripted setup already handles completion detection acceptably, switching buys you polish, not capability.

---

Part 1 of this series took apart Herdr's architecture pane by pane, Part 2 turned it into a working fleet setup, and our plugin ecosystem analysis measured what its YC-batch velocity actually proves. Read them together, then make the call the HN thread couldn't: the harness question is not which tool is best - it is how many agents you run before the glue you wrote yourself becomes the second job.

Continue Reading#

• Pi 1.0 Release Guide: MCP, Codemode and Pi Durable - what changed in Pi on October 1 and what breaks on upgrade
• Herdr Deep Dive: The Agent Terminal Multiplexer - the architecture, pane by pane
• Herdr Setup Guide: Agent Fleet Workflows - from install to a working fleet
• Herdr YC Plugin Ecosystem Analysis - what the plugin velocity proves
• Claude Code vs Codex vs Cursor vs OpenCode - the agents you would be running in those panes
• CLIs Over MCPs - why the terminal keeps winning for agents
• Best CLI Tools for AI Developers - where these harnesses sit against the rest of the terminal stack