Herdr Is a Terminal Multiplexer Built for AI Agents

There's a specific kind of chaos that comes with running multiple AI coding agents in parallel. You've got Claude Code chewing through a refactor in one pane, Codex debugging something in another, maybe a Gemini CLI session doing research in a third. And then you go heads-down on something and surface fifteen minutes later to find that one of them has been sitting on a permission prompt the entire time, waiting for you, while the others finished their tasks and quietly rejoined the ambient noise of your terminal.

tmux doesn't know the difference. To tmux, an AI agent is just another process. That's where Herdr enters.

Herdr is an open-source, Rust-powered terminal multiplexer purpose-built for running multiple AI coding agents side by side. It looks and feels like tmux: you get spaces, tabs, split panes, and persistent sessions. But it layers something on top that tmux can't offer: it actually understands what your agents are doing.

What "agent-native" actually means here

The core feature is a sidebar that tracks the live state of every agent Herdr has detected across all your panes. Four states: Working (actively processing), Blocked (waiting on you for a permission prompt or an answer), Idle (ready for input), and Done (finished a task you haven't reviewed yet). That last distinction is worth pausing on. The difference between Idle and Done is whether you've acknowledged the result. A finished agent stays flagged until you look at it, instead of silently dropping back into the stack.

AICodeKing, who covered Herdr in a recent video, puts the core value proposition plainly: "The real problem is not running the agents. The real problem is knowing what they are doing."

Detection works two ways. For agents that expose lifecycle hooks, Herdr takes a direct signal from the agent itself. For agents that don't, including Claude Code at the moment, it watches the terminal buffer and pattern-matches against known UI states. When Claude Code throws a permission prompt, Herdr recognizes it visually and marks that agent as Blocked. The project has been deliberately conservative here: it only fires the Blocked state when it matches a known approval or question UI, which limits false positives. You can install per-agent integrations (a single command: herdr integration install claude) to get fuller coverage and background notifications when a pane's state changes.

Herdr detects roughly 20 agent CLIs out of the box, per the video: Claude Code, Codex, OpenCode, Cursor Agent, Copilot CLI, Grok CLI, Quen Code, Kilo Code, Devin, Kiro, and more. Gemini CLI and Cline are detected but described as less tested. Agents not on the list still run fine as ordinary terminal processes; you just lose the state tracking. Per opentechhub.io, Herdr is fully local and single-binary, which matters if you're not enthusiastic about your code touching external infrastructure.

The automation layer is the interesting part

State visibility is useful. The automation layer is where Herdr gets structurally interesting, and where it moves beyond what tools like Collaborator offer in a GUI context.

Herdr exposes a CLI and a local socket API. The wrinkle: your agents can call that API too. An agent running inside a Herdr pane can split panes, start other agents, send them prompts, wait for them to reach a specific state, and read their output back. This makes Herdr not just a dashboard for your agents but an orchestration surface they can drive themselves.

The concrete workflow AICodeKing walks through is instructive. You tell Claude Code to implement a feature. Claude Code then runs herdr pane split to open a new pane, launches a Codex agent there with herdr agent start reviewer --kind codex, sends it a prompt with herdr agent prompt reviewer --wait, and reads the feedback with herdr agent read reviewer. One instruction from you. Two agents coordinating the entire review cycle between themselves.

As the video puts it: "This is the kind of multi-agent pipeline that people usually duct tape together with tmux send keys and a prayer. Here it is just a supported first-class API."

The API includes named agents (herdr agent rename gives an agent a stable identifier like "reviewer" or "tester"), which means multi-agent scripts can address agents by role rather than by volatile pane IDs. That's a small design decision that makes a real difference in anything more complex than a two-agent setup.

Persistence and remote mode

Herdr uses a client-server model. The server holds the actual terminals; your terminal client attaches to it. Close your laptop, come back later, reconnect, and everything is still running. Standard stuff for multiplexers.

What's less standard is native agent session restore. For supported agents, Herdr can resume the actual agent conversation after a server restart, using mechanisms like Claude Code's built-in resume functionality. Your agent's context survives the restart. That's enabled by default. There's also an experimental pane history replay feature that saves terminal output across restarts, though it ships disabled because scrollback can contain secrets and tokens.

Remote mode lets you point a --remote flag at an SSH host and run the server on a dev box or VPS while controlling everything from your local terminal. Your agents get that machine's compute and filesystem; your local theme and keybindings still apply. Combined with the persistence model, you can leave a fleet of agents running on a remote server overnight and check on them from wherever you happen to be.

Where it's rough

Herdr is pre-1.0 software. That means version upgrades can require stopping the running server, which kills active panes. That's the tax you pay for using fast-moving early software, and it's worth naming plainly rather than burying.

The screen-matching detection for agents without lifecycle hooks (Claude Code included) is heuristics, not ground truth. It's conservative and reportedly works well in practice, but it's still heuristics. Windows support lags behind Mac and Linux, and Windows can't be a remote target yet. Nesting tmux inside a Herdr pane breaks agent detection inside that session, which means you should let Herdr be your multiplexer rather than layering it on top of an existing tmux setup.

Per bitdoze.com's review, none of these are particularly unusual for a project at this stage, and they're worth weighing against what Herdr already does well rather than treating them as disqualifying.

Who this is actually for

The video draws an honest line here: if you run one agent at a time, tmux is fine. A plain terminal is fine. You don't need a dedicated multiplexer with an agent-aware sidebar and an orchestration API.

The people for whom Herdr changes the calculus are developers already running three or four agents in parallel and currently managing that coordination manually: tabbing between panes, running their own send-keys scripts, losing track of which agent finished and which one is stuck. For that workflow, the state sidebar alone is a meaningful upgrade. The automation API is the ceiling, not the floor.

The open-source angle matters too. Herdr is AGPL-licensed, runs entirely locally, and is vendor-agnostic across the agents it supports. It's not trying to push you toward any particular model provider's stack. For a tooling ecosystem that moves fast and has strong opinions about lock-in, that positioning is worth something.

The question that lingers is whether the agent CLI ecosystem will converge on standardized lifecycle hooks quickly enough that Herdr's screen-matching fallback becomes a footnote rather than a central coping mechanism. If agent tooling matures and starts exposing richer process APIs, Herdr's detection layer gets much more reliable. If it doesn't, the heuristics will need to keep pace with however many new agent UIs keep appearing. Either way, the underlying problem Herdr is solving isn't going away.

---

Dev Kapoor covers open source software and developer communities for Buzzrag.