One coding agent in one terminal is easy to follow. Three agents across two repositories, each in its own terminal tab, are not. One is waiting for permission to run a migration, another finished ten minutes ago, and the third is still reading files. You only find out by clicking through every tab, and the agent that needed a yes has been idle the whole time.
herdr is built for exactly that situation. This post explains what it is, how it is organised, and why a console in front of your agents changes how you work with them.
What herdr is
herdr describes itself as "the agent runtime": a terminal workspace manager that keeps real terminal processes running and adds structure around them. You start it from a project folder with herdr, then run your agents inside it the way you normally would, for example claude or codex. It is open source under the Apache 2.0 license and runs on macOS, Linux and Windows.
The install script from the docs is one line on macOS or Linux:
curl -fsSL https://herdr.dev/install.sh | sh
Homebrew users can run brew install herdr instead.
The herdr project also makes the Herdr app, a desktop app whose agents run in herdr-core, a small server controlled with the hc command. This post is mostly about the terminal version, herdr TUI, but the ideas carry over.
Workspaces, tabs, panes and agents
herdr's model has four layers. A workspace is the project container; the docs suggest one per repo, task or investigation. A tab is a layout inside a workspace, so you can keep agents, logs, a dev server and a review view apart. A pane is a real terminal: herdr draws its output, sends your keys to it and keeps it alive when you detach. An agent is a process herdr recognises inside a pane.
That last part is what makes it more than a terminal multiplexer. herdr detects agents from the foreground process, from screen manifests and from optional integrations, and gives each one a state:
- blocked: the agent needs input, approval or a decision.
- working: the agent is actively running.
- done: the agent finished and you have not looked at it yet.
- idle: the agent is finished or waiting, and you have seen it.
- unknown: herdr cannot confidently classify it.
Each workspace in the sidebar rolls up the states of the agents inside it, so a glance tells you which project needs you. The docs list more than twenty agent CLIs it can detect, including Claude Code, Codex, OpenCode and Pi.
A server that outlives your terminal
herdr runs as a background server with one or more clients attached. The server owns the panes and their processes; the client is only the view. Press ctrl+b q to detach, close the terminal window, and the agents keep working. Run herdr again and you are back where you left them. To end a session deliberately, use herdr server stop.
This matters more for agents than for ordinary shells. An agent run can take twenty minutes. Tying it to a terminal window that you might close, or to an SSH connection that might drop, means losing work. With herdr the run belongs to the machine, not the window.
A reboot is the exception. After a full restart herdr restores the shape of the session, and with an integration installed (for example herdr integration install claude) it can resume supported agent sessions, but the original processes do not survive.
Remote by design
Because the server and the client are separate, the client does not have to be on the same machine. The docs describe three paths: SSH to a machine and run herdr there, the tmux-style way; attach from your own computer with herdr --remote workbox, where the remote server keeps the panes and your local herdr draws the interface; or save several SSH machines so they share one sidebar.
herdr also exposes a socket API: newline-delimited JSON over a local socket, which scripts and other clients can use to list workspaces, read panes, send input and subscribe to state changes. That is the seam other tools build on.
Why a console helps
The shift is from watching agents to being called by them. Without a console you poll: switch tabs, scroll, check. With one, the state tells you where to look. A few habits follow from that:
- Run more in parallel. When blocked agents surface on their own, three or four tasks in separate workspaces stay manageable.
- Keep tasks apart. One workspace per repository or branch keeps logs, servers and agents from piling into one window.
- Answer quickly. An agent that waits on a permission prompt is the most expensive kind of idle. Seeing "blocked" as soon as it happens shortens every run.
- Walk away. Since the runs belong to a server, you can leave the desk and check back from somewhere else.
Where a phone fits
That last point is where Herdr Pocket comes in. It is a separate iPhone and iPad app, not made by the herdr project, that connects to your computer over SSH and talks to herdr through that socket API. It shows the agents from all your computers in one list, sorted so the ones that need you come first, and lets you answer a prompt, read the conversation or type into the live terminal. The agents keep running on your computer; the phone is only a window onto them.
If you already run herdr, the next step is to make that computer reachable from anywhere. Our guide to setting up a Mac with herdr and Tailscale walks through it, and remote vibecoding from your phone covers the day-to-day workflow.
Want to see your herdr agents on your phone? Herdr Pocket is in a free public beta: join it on TestFlight.