Herdr Adds the Agent State tmux Never Had

I moved to tmux about fifteen years ago and I have not looked back. I have also spent a fair number of words arguing that changing tools too often is a tax most teams pay without noticing, and that the question worth asking about any new tool is narrow and unglamorous: what class of operational pain does it delete, and is that worth relearning how things fail?

So when a new terminal multiplexer shows up with 18,000 stars and a launch post, my first instinct is suspicion. The multiplexer problem has been solved since 1987. Prettier panes are not a reason.

Herdr is the first one in a long time where I think the honest answer is that it does delete something. Not panes, not persistence — tmux has both. What it adds is a thing tmux was never built to have: semantic state about what the process in the pane is actually doing, wrapped in a control surface another program can drive. That’s worth a post. It is not yet worth a migration.

What I am and am not telling you

I have not installed or run Herdr. Everything below comes from the project’s documentation, its repository, and public discussion. I am reading architecture, skeptically. No latency numbers, no memory figures, no opinion on how it feels after a week. That matters here, because the interesting claim — that Herdr knows whether an agent is idle, working, blocked, or done — is exactly the kind that degrades in the field. Docs tell you the design. They do not tell you the hit rate.

The thesis: Herdr adds an operational primitive, not an aesthetic. Semantic agent state plus a programmable control plane. Take those away and it is another multiplexer, and you already have one.

What it actually is

Herdr calls itself an agent multiplexer that lives in your terminal, and architecturally it will feel familiar to anyone who has run tmux: a client/server split, persistent PTYs, workspaces containing tabs containing panes, detach and reattach. It ships as a single Rust binary with no Electron and runs inside the terminal emulator you already use rather than replacing it. The panes hold real processes in real PTYs, not a reconstructed chat transcript. The default prefix is ctrl+b, chosen so Herdr does not steal input from shells, editors, or a tmux session outside it. The site states it requires no account and sends no telemetry — the project’s stated design, not something anyone has audited.

As I write this on July 19, the repository was created on March 27 this year, sits at roughly 18.2k stars and 1,170 forks, and shipped v0.7.4 on July 15. GitHub shows 71 open issues against 761 closed and 44 contributors — though that number flatters the picture, since the creator accounts for 982 commits and the next two entries are automation bots at 54 and 43. The v0.7.4 notes show both halves of a fast-moving four-month-old project: additions alongside a long tail of fixes across copy mode, input handling, agent detection, WSL, Windows persistence, and plugins. Active development and unresolved edge cases are the same signal.

The state tmux never had

Here is the pain I recognize. Run three or four coding agents at once and the actual work becomes polling. You cycle panes asking the same question over and over: is this one still thinking, or has it been sitting on a permission prompt for six minutes? tmux cannot help, and it is not tmux’s fault. tmux knows a pane has a process and that bytes came out of it. Whether those bytes mean “working” or “waiting for you” is outside its model.

Herdr answers that, and how it answers is the part worth understanding — the marketing version (“Herdr knows what your agents are doing”) is not what the docs describe.

Detection starts with the foreground process. From there, authority depends on the integration, and it splits into two tiers. For Pi, OMP, Kimi Code CLI, OpenCode, Kilo Code CLI, Hermes Agent, and MastraCode, lifecycle hooks or plugins can act as authoritative state reporters — the agent tells Herdr what it is doing. For Claude Code, Codex, GitHub Copilot CLI, Devin CLI, Droid, Qoder CLI, and Cursor Agent CLI, the integration primarily restores native session identity, and lifecycle state still gets inferred from screen manifests: TOML descriptions matched against a live snapshot of the bottom of the buffer, plus terminal titles and OSC progress sequences.

Inference has a failure mode, and to the project’s credit the docs name it. Blocked detection is deliberately strict: Herdr marks a pane blocked when the snapshot matches a known approval, question, or permission UI, and an agent shipping a prompt shape nobody has written a manifest for yet falls back to idle. Strict is right, because a status board that cries wolf is worse than none. But it means the quiet failure is the exact case you cared about — an agent waiting on you, displayed as an agent with nothing to do.

The mitigations are reasonable. Detection manifests update from herdr.dev automatically without a restart, so new prompt shapes land without a release, and [update] manifest_check = false turns that off if you would rather not have the background check. There is also a herdr agent explain command for inspecting which source is driving a pane’s state — the sort of thing that tells me somebody has debugged this in anger. One boundary inverts what you might assume, though: Herdr runs happily inside tmux as the outer environment, but it does not inspect tmux sessions launched inside a Herdr pane. Nest it that direction and it sees tmux, not the agent behind tmux.

The API is the more important feature

The state model gets the attention; the control surface is what makes me take Herdr seriously. It exposes a socket API — newline-delimited JSON over a Unix domain socket, or a named pipe on Windows — and the CLI wraps the same surface. Through it you can manage workspaces and tabs; split, resize, read, and send input to panes; list, inspect, start, and send to agents; export and apply layouts; manage Git worktrees; control plugins and integrations; and bootstrap an external client with a session snapshot.

Two verbs matter more than the rest. You can wait — for output, or for a semantic agent-state change. And you can subscribe to events scoped to workspaces, tabs, panes, agents, layouts, and worktrees.

Those turn a terminal into something a program can operate. Not screen scraping, not send-keys and a sleep 3 and a prayer. A script can block until a pane’s agent goes from working to blocked, read the pane, decide, and send input back. I made essentially this argument about MCP: a system stops being an application and becomes infrastructure the moment another process can inspect and operate it through a defined surface. Same for OpenCode V2 and its HTTP API. The pattern repeats because it is the actual dividing line.

To be precise about something easy to get wrong: this is not MCP. Different protocol, different surface, no relationship beyond programmability. The API has edges too — plugin event hooks are a separate plugin-side mechanism rather than a subscription scope, and attaching to an agent is a CLI helper, not a socket method. Better Stack’s independent overview lands on a similar split: state tracking is the practical capability today, CLI-driven orchestration the experimental one.

Persistence and remote, stated exactly

Here I want to be pedantic, because “your work survives” is the claim every multiplexer makes and Herdr’s version has real internal structure. Detaching the client keeps the server and every pane process running — shells, servers, tests, agents. This is the strong path, and the one you use daily.

Restarting the server does not preserve arbitrary processes. What comes back is structure — layout, working directories, focus — and panes without a stronger restore path return as fresh shells in their saved directories. Supported integrations can resume native agent sessions across a restart, depending on version. Pane screen history can replay recent terminal content, but it is off by default for the right reason: that buffer can contain secrets, tokens, prompts, and command output. Live handoff of running panes between servers is experimental, opt-in, and best effort, and herdr update --handoff does not apply to Homebrew, mise, or Nix installs.

Five different mechanisms, five different guarantees. Anyone who compresses that into “everything survives restarts” is selling.

Remotely you can do the classic thing — SSH in, run Herdr there — or run herdr --remote, a local thin client over SSH that keeps your local keybindings and bridges desktop behavior like clipboard image paste. Remote attach covers Linux and macOS on x86_64 and aarch64. Remote installation prompts before placing a helper binary, and a non-interactive run fails rather than quietly modifying the host — which tells you someone thought about running this against machines they do not own.

So why not tmux, or Zellij, or a few hooks?

For one or two agents, Herdr does not clear the bar. You can see both panes. You know what they are doing because you are looking at them. A tmux status line plus a couple of hooks gets you surprisingly far, and the migration debt buys you very little.

The calculus changes when polling becomes the job — several agents across local and remote machines, and the recurring cost is checking on them and switching to whichever one stalled. That is a measurable, repeating operational pain, and semantic state plus an event stream removes a category of it rather than relocating it.

The skeptics on Hacker News — where the two Herdr threads pulled 166 and 404 points — were largely right on their own terms. Several asked whether tmux or Zellij plus hooks already covers enough. Others raised the point I find hardest to argue with: running more concurrent agents does not create more attention. One commenter put it directly — the bottleneck is review and decision making. Multiplexing agents better moves that queue without shortening it, and nothing in Herdr’s design answers that.

What surprised me is that the pro-Herdr case did not rest on agents at all. Mouse-first ergonomics and sane defaults came up as often as the agent status sidebar, and several people said they use it purely as a tmux replacement with no agents involved — a stronger adoption signal than the orchestration pitch. Not everyone agreed: one user called the keybindings all over the place, charitably blaming collision avoidance. Anecdotes from a comment section, not measurements.

The parts that should slow you down

The project is pre-1.0 and four months old with one primary author, and a fast release cadence cuts both ways.

Native Windows is preview-only beta. It uses ConPTY rather than the Unix PTY model, and behavior around live working directory, image paste, graphics, cursor rendering, and plugins is partial or unverified. Direct terminal attach, herdr --remote from the Windows binary, live server handoff, Unix foreground process groups, and signed-binary handling are not supported there. Windows users can SSH into a Linux or macOS host, which is what I would do anyway.

Plugins deserve a hard look. A plugin is an executable workflow package declared by a herdr-plugin.toml manifest, supplying actions, event hooks, panes, keybindings, and link handlers. Herdr validates manifest structure and shows you install commands to review, but it does not sandbox or audit what a plugin does — the docs say so outright, and note that the entire Herdr CLI is the plugin API. Plugins run with your privileges and can drive your whole terminal runtime. The marketplace indexes public repositories tagged herdr-plugin automatically; the project states this is discovery, not review, and the advertised 150-plus community plugins counts listings, not vetted software. Treat installing one like npx-ing a random MCP server. Same trust decision.

Licensing is AGPL-3.0-or-later, with commercial licenses offered to organizations that cannot comply. That is a legitimate model and not a footnote: if you work somewhere with a policy against AGPL, this conversation ends at legal, not engineering. GitHub’s API reports the license as “Other” with no SPDX identifier, so an automated scan may flag it oddly even though the LICENSE file is unambiguous.

What I would actually do

I am not switching, and I am not telling you to. My tmux config has fifteen years of scar tissue in it, and nothing I read removes enough pain to justify throwing that away on a four-month-old pre-1.0 project.

But I would run it in parallel, and if you operate several terminal agents across machines, I think you should too. Herdr coexists with tmux rather than demanding a clean break, which makes evaluation cheap and honest. Give it the agents, keep tmux for what matters, and answer one question over a few weeks: does semantic state remove enough polling and context switching to pay for learning how a new system fails? If your agents report state authoritatively, the answer is more likely yes. If they are inferred from screen manifests, you are betting on pattern matching against UIs that change without warning — watch for the idle-that-was-really-blocked case specifically.

What I keep returning to is that Herdr has a reason to exist. Most tools in this space are a nicer-looking version of something I already run. This one found a real gap — terminals know about processes, and nobody’s terminal knows about work — and built a control plane around it instead of a status bar. Whether the execution holds up is a question the next year answers, not a blog post.

New is not a reason. Having a reason is a reason. Herdr has one.