Herdr

Every article in this series so far has been about a harness: the thing that wraps a model and turns it into an agent that edits your files. Herdr is one layer down. It does not wrap Claude Code or Codex or OpenCode, it owns the terminals they run in, keeps them alive when your laptop closes, and lets one agent wake another. It is Apache 2.0, written in Rust, and it has 41,561 stars since March. If you run more than one agent at a time, this is the layer you are currently doing badly by hand.

Not a harness, a runtime

The positioning is in the tagline: the runtime your coding agents live on. Herdr's own framing of the relationship is the cleanest summary anyone has written of this layer.

It says it supports "claude code, codex, cursor, opencode, grok and the rest", and then: "herdr doesn't wrap or replace them; it owns their terminals."

That sentence is the whole product. DeepSeek Harness competes with OpenCode and ZCode, and none of them will load each other's plugins. Herdr competes with none of them, because it sits underneath all four and does not care which you picked. In a field where every vendor is building a captive ecosystem, a genuinely neutral substrate is worth noticing.

What it actually does differently

Start with the thing that will change your day. Herdr keeps terminals running in a background server when you close the client or lose your SSH connection. Close the lid mid-agent-run, reconnect from somewhere else, and the work is still going.

Be precise about what survives a full restart, because the README is: after a machine restart herdr restores the saved layout and can resume supported agent sessions, but "the original processes do not survive". Layout and agent session state come back. A half-finished shell command does not.

The second difference is that panes are agent-aware. Every pane carries a state: working, blocked, or idle. A plain multiplexer shows you a wall of scrolling text and leaves you to work out which of your six agents is actually waiting on you. Herdr tells you. That is a small feature that becomes the entire reason to use it once you are running more than two agents.

Third, and most interesting, agents can drive it. From the README: "agents drive herdr through the cli and socket api: they can spawn panes, prompt each other, and wait until another agent is genuinely blocked."

Read that last clause again. Not poll a file, not sleep and hope: wait until another agent is genuinely blocked, because the runtime knows the difference between an agent thinking and an agent waiting. That is a coordination primitive, and it is the part no harness gives you, because a harness only sees inside itself.

The interface

Herdr takes both input styles seriously, which is unusual: "keyboard and mouse, both first-class, tmux-style prefix keys and click, drag, split." If you have muscle memory from tmux it transfers. If you would rather drag a split with a mouse, that works too.

curl -fsSL https://herdr.dev/install.sh | sh
# or
brew install herdr

herdr

Detach with ctrl+b q and reattach by running herdr again. The prefix key will look familiar for a reason.

Multi-machine is built in rather than bolted on. You can keep local work and saved SSH machines in one window with a combined agent list and independent reconnects, so a dropped connection to one box does not disturb the others. For anyone running agents across a laptop and a workstation, that removes a whole category of tmux-over-ssh misery.

The ecosystem is the signal

Herdr is six months old and already has third-party surfaces built on it, which is the thing DeepSeek Harness has in volume and ZCode does not have at all.

None of these is huge, and that is the point: they exist at all. A mobile PWA that pushes you an alert when an agent blocks is only buildable because the runtime exposes pane state over an API. The layer is doing its job.

The test we have been applying

In the harness wars piece we found that every coding harness built by a frontier lab has its issue tracker closed, and only the independent one accepted bug reports. Herdr is independent, and it behaves like it: Issues are enabled with 389 open, Discussions are on, and there are 3,201 forks.

That is a small dataset but the pattern is holding. The projects you can file a bug against are the ones with no model to sell you.

Who should install it

Install it if you routinely run two or more coding agents at once, if you have ever lost an agent run to a closed laptop or a dropped SSH session, or if you work across more than one machine. The blocked-versus-working indicator alone justifies it at three concurrent agents.

Skip it if you run one agent in one terminal on one machine. You will get a nicer multiplexer and not much else, and tmux is already installed.

The interesting case is the one the socket API opens. If you are building multi-agent workflows, herdr gives you a way for agents to spawn and coordinate each other that does not involve inventing your own message bus. That is a more serious reason to adopt it than the terminal management, and it is the part most people have not noticed yet.

Sources and further reading

• Herdr on GitHub
• herdr.dev
• collie, the mobile terminal
• zoetrope, session flow graphs
• herdr-reviewr, the diff sidebar

Ten minutes: install it, start two agents in two panes on the same repository, and watch the pane states while they work. The moment you can see at a glance which one is blocked on you and which is still thinking, you will know whether this layer is missing from your setup.

Tested on: not independently tested. Positioning, agent support, the socket API description, restart behaviour and install commands are quoted from herdr's own README. Star counts, fork counts and issue settings for herdr and the four ecosystem projects were read from the GitHub API on the date below.
Date checked: 2026-09-30