Most agent tooling is still built around a single conversation: one agent, one task, one terminal, one stream to babysit. Fine for small tasks, bad for real engineering work.
Herdr is interesting because it treats that as the default shape of the work.
The simplest way to describe it is: Herdr is tmux for coding agents. More precisely, it is an agent multiplexer that runs inside your existing terminal. It gives each agent a real PTY, keeps processes alive where the work is happening, shows agent state, and exposes a CLI plus a local socket API.
That distinction matters. Herdr is not another desktop agent app. It is a binary you run where the code and terminals live: a server, a Mac Mini, a VM, a dev machine under your desk. Close the laptop, detach, ssh back later, reattach, even from a phone. The work did not die because your terminal window did.
Coding agents changed the cost of starting work. I can ask one agent to explore a bug, another to write a failing test, another to draft a migration plan. The bottleneck is supervision.
The problem is that normal terminals do not understand supervision. tmux and Zellij give you persistence and panes, but they do not know whether an agent is blocked, working, done, idle, or just sitting there after printing a question three screens ago. Desktop apps often understand the agent state better, but then the workflow is stuck to the machine with the GUI. Worktree orchestrators can coordinate parallel tasks, but they usually want to own the workflow.
Herdr sits in a useful middle: terminal model, plus agent awareness.
The performance multiplier is not magic. It comes from four practical properties:
The fourth point is the one I care about most. A human supervising three panes is useful. An agent that can start helper agents, read output, wait for state transitions, and consolidate the result is where compounding starts.
Herdr's docs are explicit about this. The socket API can manage workspaces, tabs, panes, and agents. The recommended path is CLI wrappers first, then the raw socket API for direct request-response control or subscriptions. There is also an agent skill file, guarded by HERDR_ENV=1
, that teaches an agent to use Herdr from inside a pane.
Imagine a staff engineer supervising a refactor: replace an internal client, adjust tests, and check deployment. I would split it.
One supervisor owns the plan and review. It creates three panes:
herdr
Inside Herdr, it can split panes and start agents:
split=$(herdr pane split --current --direction right --no-focus)
api_pane=$(printf '%s\n' "$split" | jq -r '.result.pane.pane_id')
herdr agent start api-change --kind codex --pane "$api_pane"
herdr agent prompt api-change "Replace the legacy client in the API layer. Keep the diff minimal."
Then it starts two more agents:
test_split=$(herdr pane split --current --direction down --no-focus)
test_pane=$(printf '%s\n' "$test_split" | jq -r '.result.pane.pane_id')
herdr agent start tests --kind codex --pane "$test_pane"
herdr agent prompt tests "Add or update tests for the new client behavior."
deploy_pane=$(herdr pane split --current --direction right --no-focus | jq -r '.result.pane.pane_id')
herdr agent start deploy-review --kind codex --pane "$deploy_pane"
herdr agent prompt deploy-review "Review config, deploy scripts, and rollback implications."
The supervisor waits for state instead of polling terminals:
herdr agent wait api-change --until blocked --timeout 120000
herdr agent read api-change --source recent-unwrapped --lines 80
Or for normal process output:
herdr pane run w1:p3 "just test --watch"
herdr pane wait-output w1:p3 --regex "passed|failed" --timeout 120000
The human moves up a level: review diffs, answer blocked agents, reject bad approaches, judge tests, and stop the blast radius before production.
Parallelism alone is not enough. Opening five terminals is easy. Keeping them understandable after lunch is the hard part.
Herdr works because it combines parallel execution with persistence and state. If an agent gets blocked, that state is visible. If another finishes while you are reviewing the first, it is marked done until inspected. If ssh drops, the server keeps owning the panes and processes.
Without persistence, each extra agent adds overhead. With persistent panes and state, the overhead drops. You can run one agent per repo, hypothesis, or strategy, and only pay attention when needed.
Herdr is closest to tmux or Zellij in the mental model. It gives you persistent panes and remote reattach, but adds agent state and an agent-shaped control surface. If you already live in tmux, you are adopting a younger tool for that layer.
Compared with desktop agent apps, Herdr is less polished, but more honest about where engineering work happens. A terminal multiplexer on the work box survives the laptop closing.
Compared with worktree orchestrators, Herdr is less opinionated. If you want a product that owns task assignment, worktree lifecycle, review flow, and merge policy, use the orchestrator. If you want a flexible runtime where agents, shells, test watchers, logs, and supervisor scripts coexist, Herdr is the better shape.
There are real risks. Parallel agents mean parallel blast radius. If you run agents with broad bypass permissions, they can all make bad edits at the same time. You still need git discipline, small prompts, isolated worktrees, diff review, and test-first checks.
I would recommend it most strongly to experienced engineers. Anyone can open a few panes, but the API rewards people who know how to split work, define boundaries, review patches, and notice suspicious changes.
The current generation of coding agents is not limited only by model quality. It is limited by runtime ergonomics.
Single-chat agent workflows make every task feel linear. Real engineering work is a graph of investigations, tests, reviews, failed attempts, logs, and decisions. Herdr's bet is that the right interface is not a prettier chat window. It is a terminal-native runtime with persistence, state, and an API.
Herdr will not replace judgment, code review, or taste. It will not make every engineer three times faster by default. But for engineers already pushing agents hard, it keeps multiple workstreams alive, visible, and controllable without losing context.
That is where throughput comes from. Not from pretending one agent is a team. From giving one engineer a sane control surface for many agents, then being disciplined enough to use it.
To test my projects, I use Railway. If you want $20 USD to get started, use this link.