Most AI coding tools still assume one human watching one agent do one thing. That is useful, but it is not where the interesting leverage is anymore.
The interesting part starts when you stop treating a coding agent as autocomplete and start treating it as a worker process. Long-running, interruptible, sometimes wrong, often useful when the task boundary is clear.
Once you do that, the bottleneck changes. The question is whether you can supervise several pieces of agent work without losing state, missing questions, or spending all morning context-switching between terminals.
That is why Herdr caught my attention.
Herdr is not another desktop coding app. It is an agent multiplexer. The short version is: tmux for coding agents.
the important bit is where it runs
Herdr runs where the work happens.
That can be your laptop, a Mac Mini, a development server, or a VM with the right credentials and dependencies. You start Herdr there, run agents inside real terminal panes, detach, and come back later.
The Herdr process owns the persistent session. The terminal window is only the client rendering it. Close the laptop, lose SSH, switch machines, SSH back in, run herdr, and the session is still there.
ssh you@server
herdr
That matters more than it sounds.
Desktop agent apps can feel polished, but they are usually tied to the GUI machine. Classic terminal multiplexers survive disconnects, but they do not know that pane three is blocked while pane five is done.
Herdr sits in the middle: real PTYs, terminal-native persistence, remote attach, and agent awareness.
throughput comes from parallelism plus zero context loss
The productivity story with agents is often told badly.
People show a prompt, the agent writes code, and everyone argues about whether the output was impressive. That is the wrong unit of analysis. A single agent doing one task is still serial work.
The multiplier is parallel supervision.
Herdr gives you:
- N agents in real PTYs, each working on its own task or repo
- semantic state like blocked, working, done, and idle
- persistence, so a terminal crash does not erase a run
- CLI wrappers and a JSON socket API, so scripts and agents can operate the multiplexer too
The API part is the real lever. Herdr's socket API exposes workspaces, tabs, panes, agents, events, pane reads, and waits. The docs recommend CLI wrappers for simple orchestration, then raw socket API calls when you need direct request and response control or event subscriptions.
For example:
herdr workspace create --cwd ~/src/payments --label payments
herdr pane split w1:p1 --direction right
herdr pane run w1:p2 "npm test"
herdr agent wait w1:p1 --until done
herdr pane read w1:p2 --source recent --lines 50
Some Herdr examples describe this pattern as herdr pane run plus an agent-status wait, and older wording may show herdr wait agent-status. The current socket API docs show herdr agent wait, so I would trust the installed CLI schema:
herdr api schema --json
The flag name is not the point. The wait is semantic. A supervisor can wait until an agent is done or blocked, read the output, and decide the next action.
That is the difference between "I have many terminals open" and "I have a small execution fabric for coding work."
a concrete workflow
Imagine a normal platform engineering morning. Three pieces of work would be annoying to run sequentially.
Agent 1 works on a bug in the API service.
Agent 2 updates Terraform for a staging environment.
Agent 3 investigates a flaky test in a different repo.
A supervisor agent sits in a fourth pane. Its job is to coordinate the herd.
herdr pane split w1:p1 --direction right
herdr pane run w1:p2 "codex 'fix the pagination bug and run the API tests'"
herdr pane split w1:p1 --direction down
herdr pane run w1:p3 "codex 'update staging Terraform for the new Redis size'"
herdr pane split w1:p2 --direction down
herdr pane run w1:p4 "codex 'investigate the flaky checkout test and report the root cause'"
Then the supervisor watches state instead of polling terminals manually:
herdr agent wait w1:p2 --until blocked
herdr agent wait w1:p3 --until done
herdr agent wait w1:p4 --until done
This does not remove review. It makes review more important.
If Agent 2 finishes Terraform first, inspect the diff. If Agent 1 blocks on ambiguous API behavior, answer that pane. If Agent 3 finds a race in test setup, decide whether to let it fix the test or stop and file the finding.
The gain is not "three agents write perfect code."
The gain is that you do not pay context loss tax every time one of them pauses.
how it compares
Herdr is closest to tmux or Zellij in spirit. It preserves terminal sessions, panes, tabs, and remote attach. If all you need is persistent shells, tmux is probably enough.
But tmux and Zellij do not understand agents. They cannot tell you which pane is blocked, working, done, or idle. They are terminal multiplexers, not agent multiplexers.
Desktop agent apps solve a different problem. They can be agent-aware and pleasant, especially when the workflow is centered on one repo and one machine. The tradeoff is location. If the GUI machine is not where the work lives, you drag the workflow back to your desktop.
Worktree orchestrators are useful too. Some own the branch, diff, pull request, and review flow end to end. That can be excellent when you want a managed workflow. It is less attractive when you already have your own repo layout, scripts, terminals, SSH habits, and local conventions. Herdr can pair with worktrees, but it does not need to own the whole process.
The tradeoff is that Herdr assumes you are comfortable supervising real processes. That is a feature for experienced engineers and a footgun for careless ones.
who should use it
Experienced engineers will get the most out of Herdr.
Not because beginners cannot run it. They can:
curl -fsSL https://herdr.dev/install.sh | sh
herdr
Senior people benefit more because parallelism only helps when you can decompose work, define boundaries, evaluate diffs, and spot confident wrongness.
Parallel agents also mean parallel blast radius.
If you run three agents with broad filesystem access and bypass permissions enabled, you created three fast ways to modify things you may not have inspected. That can be fine in a disposable repo, clean worktree, or container. It is not fine in production infrastructure with ambient credentials.
My practical rule: Herdr makes sense when each agent has a crisp task, a bounded working directory, and a verification command. Review every diff. Keep dangerous permissions boring. Treat blocked states as useful signals, not annoyances to bulldoze.
references
To test my projects, I use Railway. If you want $20 USD to get started, use this link.
Top comments (0)