herdr: a socket-first agent multiplexer that treats panes as a shared runtime

What herdr actually is and who it is for

herdr is a terminal multiplexer, but not the kind you already know. It is a background server that owns panes, and it exposes a socket API so that agents, not just humans, can drive it. The README calls it "the runtime your coding agents live on." The intended user is someone who runs Claude Code, Codex, Cursor, OpenCode, Grok, or similar tools and wants those agents to keep working when the laptop lid closes or the network drops. The key phrase is "always running": terminals live inside the server, so closing the lid or restarting the machine does not kill the sessions. You reattach from any terminal or over SSH. This is a different model from a typical tmux session, which dies with the machine unless you set up systemd or tmux-resurrect. herdr makes persistence the default, not a plugin. The second audience is agent developers. The socket API is not an afterthought; it is a first-class interface. An agent can spawn a pane, read its output, and wait until another agent is genuinely blocked. That is a concrete coordination primitive, not just a remote-control gimmick.

The socket API: panes as a coordination medium

The README describes a "pure socket api" where agents spawn panes, read output, and wait on each other. The mechanism is that herdr runs as a daemon, and the CLI and the socket API are two faces of the same server. When an agent calls the socket API, it can create a new pane, which is a terminal session inside the server. The agent can then read the output stream from that pane, and it can wait until the pane's state changes to "blocked." The README says every pane is marked working, blocked, or idle. That state is what makes waiting meaningful: an agent does not poll a process exit code; it waits for a semantic state. For example, if agent A needs input from agent B, A can spawn a pane for B, and B can mark itself blocked when it needs an answer. A can wait on that blocked state, then respond. This is a different coordination model than having agents write to files or use a message queue. The state is visible in the UI too, so a human can see which agent is stuck. The README claims "when an agent stops and needs an answer, herdr says so." That is a concrete feature: the pane's status indicator changes. The socket API is documented at herdr.dev/docs/socket-api, but the README does not include a code sample, so the exact wire format is not visible in this material.

Install and first run: a single binary and a single command

Installation is a one-liner: `curl -fsSL https://herdr.dev/install.sh | sh`, or `brew install herdr`, or `mise use -g herdr` on Linux. Windows gets a PowerShell equivalent: `powershell -ExecutionPolicy Bypass -c "irm https://herdr.dev/install.ps1 | iex"`. There is a note about "endpoint-protected Windows" that points to a beta page, so Windows support is not fully GA. After install, you start the server with `herdr`. That command starts the background server in the directory "where the work lives," which implies the server binds to a working directory and all panes are relative to it. You then run your agents inside panes, split panes, and walk away. To detach, press `ctrl+b q`; to reattach, run `herdr` again. The README does not show how to configure the server, but the docs page lists a configuration section. The development build is straightforward: `git clone`, `cargo build --release`, and `just test` for unit tests. The binary is a single Rust binary with no Electron, which the README highlights as a benefit for terminal users.

The always-running model: what it buys and what it costs

The central trade-off is that herdr is a daemon, not a foreground process. That gives you persistence across network drops and machine restarts, but it also means you have a long-lived process consuming memory and holding terminal file descriptors. The README says "close the lid, drop the network, or restart the machine; agents keep working and sessions come back." That is a strong claim, and it depends on the server being configured to survive a reboot, which the README does not explain. On a laptop, closing the lid usually suspends the machine; the server cannot run while suspended. The README says "restart the machine; sessions come back," which implies there is a persistence mechanism, but the details are in the docs, not in the README. The cost is that you now have a server process that can crash, and if it crashes, all panes die. The README does not mention crash recovery or logging. Another cost is security: a socket API that lets any agent spawn panes is a powerful attack surface. The README does not describe authentication or access control for the socket. That is a real gap. If you run untrusted agents, or if your machine is multi-user, you need to verify how the socket is protected before adopting.

Where herdr is the wrong tool

herdr is not a replacement for a full IDE or a job scheduler. It is a terminal multiplexer, so it only manages panes that run terminal commands. If your agents need a GUI, or if they need to run as system services with cron-like scheduling, herdr is not the right layer. Also, the README says herdr "doesn't wrap or replace" agents like Claude Code or Codex; it "owns their terminals." That means herdr is only as useful as the terminal-based agents you run. If you use a cloud-based agent that runs remotely, herdr adds nothing. Another limitation is the plugin system: the README mentions plugins and a marketplace, but it does not give any examples or a plugin API. The marketplace is at herdr.dev/plugins, but the README does not show how to write a plugin or what the plugin API looks like. That is a thin area. Finally, the README is short on operational details: no mention of log rotation, no mention of resource limits per pane, no mention of how many panes it can handle. The docs might cover that, but the README does not, so a careful engineer should read the docs before deploying.

Alternatives: tmux with tmux-resurrect, or a message queue

The most direct alternative is tmux, which is a terminal multiplexer that has been around for decades. tmux does not have a socket API for agents, but it does have a control mode and a client-server model. You can script tmux with `tmux send-keys` and `tmux capture-pane`, but that is a hack, not a designed interface. tmux also does not persist across machine restarts by default; you need tmux-resurrect or tmux-continuum to save and restore sessions. That is a plugin-based approach, whereas herdr makes persistence a core feature. The difference is that herdr's socket API gives agents a structured way to wait on a pane's state (working, blocked, idle), which tmux does not have. Another alternative is to skip the terminal multiplexer entirely and have agents communicate through a message queue like Redis or NATS. That gives you decoupled coordination, but you lose the terminal UI and the ability to see what each agent is doing in a pane. herdr combines the terminal view with the coordination primitive. If you already use tmux and you only need persistence, tmux-resurrect is simpler. If you need agent-to-agent waiting semantics, herdr's socket API is a different approach that tmux does not offer.

Maintenance and license: Apache-2.0, active releases, but no long-term evidence

herdr is licensed under Apache-2.0, which is permissive for commercial use and modification, with no copyleft obligations. The repository is not archived, and the last push was August 2026, with a v0.8.2 release on the same day. There are also preview builds dated a day earlier and a day later, which suggests a rapid release cycle. That is a sign of active development, but it also means the API and socket protocol may change between versions. The README does not include a changelog or a migration guide, so upgrading from a preview to a stable release could require re-reading the docs. The development process uses `just test` and `just check`, which is a standard Rust workflow. The project has a SPONSORS.md file, which implies a community funding model, but the README does not state how sustainable that is. For an engineer evaluating adoption, the maintenance cost is low in the sense that it is a single binary, but the cost of tracking changes is real. The socket API is the core interface, and if it changes, any agent integration you build will need updating. The README does not promise backward compatibility, so verify the socket API versioning before you invest in a custom integration.

Editorial conclusion

Adopt herdr if you run multiple coding agents in one terminal and need them to survive network drops or machine restarts, and if you want agents to coordinate through a socket API rather than shared files. Skip it if you rarely leave a single interactive session or if you need a mature plugin ecosystem with a large marketplace. Before adopting, verify that herdr's session-state model matches your workflow: check the docs on session-state and persistence-remote, and confirm which of your agents are listed in the supported-agents page. The core value is the socket API and the always-running server, so test that an agent can spawn a pane, read output, and wait on another agent's blocked state before committing.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes