A deep dive into Herdr} -->Bootcamp is coming in September &rarr;learn to build apps with AI~~~<br>I run several coding agents every day.

One might be changing a website. Another is reviewing the change. A third is running tests in a different project. A fourth is waiting for an answer.

The agents are capable.

Keeping track of all their terminals is not.

Herdr is a terminal workspace manager built for this exact problem.

It gives every agent a real terminal. It organizes those terminals into workspaces, tabs, and panes. A sidebar tells me which agent is working, blocked, done, or idle.

The session keeps running when I close the terminal. I can reconnect locally, over SSH, or from my phone.

And the whole system is scriptable.

Herdr has a CLI and a local socket API. A script can create a workspace, split a pane, start an agent, send it a prompt, wait for it, and read the result. An agent can do the same thing.

This is the part that makes Herdr more than a nicer terminal multiplexer.

It is an interface for me, and a control plane for the agents.

If you used tmux, the shortest explanation is: Herdr is tmux rebuilt around coding agents .

If you never used a terminal multiplexer, that is fine. Herdr is mouse-native. You can start by clicking tabs, dragging pane borders, and using the right-click menus.

Let’s see how it works, why I find it compelling, and how it fits into my workflow.

The problem Herdr solves

Running one coding agent is easy.

Open a terminal, start Codex or Claude Code, describe the task, and watch it work.

The workflow changes when you run several agents.

Now you need to remember:

which terminal belongs to which project

which agent is still working

which one needs approval

which one asked a question

which one finished while you were looking elsewhere

where the development server is running

where the test output went

what survives if you close the terminal or lose the SSH connection

Normal terminal tabs only solve the first part.

tmux and Zellij add persistent sessions, panes, and layouts. They are excellent general-purpose tools, but they do not understand the process inside a pane.

To tmux, Codex is just another command.

Graphical agent managers understand agent state, but they usually put the terminal inside their own application. That can mean a wrapped terminal, a desktop-only workflow, or a tool that does not follow me onto a remote Linux server.

Herdr sits between those two approaches.

It keeps the real terminal and persistent-session model. Then it adds agent awareness, mouse controls, remote access, notifications, and automation.

It is a single Rust binary. There is no account, hosted dashboard, Electron app, or telemetry.

The code keeps running where I started it.

Here is the practical comparison:

CapabilityPlain terminal tabstmux or ZellijGraphical agent managerHerdrReal terminal processesYesYesDepends on the appYesPersistent detach and reattachNoYesUsually differentYesPanes and tabsTerminal-dependentYesYesYesAgent lifecycle stateNoNoYesYesWorks through normal SSHYesYesUsually limitedYesMouse-native workspace UITerminal-dependentLimitedYesYesLocal CLI and socket APINo shared layerGeneral terminal controlProduct-dependentYes, agent-awareAgent can control another agentNoPossible, but manualProduct-dependentBuilt in<br>Herdr is not automatically better in every row.

If I need one shell, I use one shell. If I need a battle-tested general multiplexer on a machine that already has tmux, tmux is enough. If I need product-level tasks, isolated environments, and a complete agent event history, a graphical agent platform may be the stronger abstraction.

Herdr becomes interesting when I want persistence, real terminals, agent awareness, and automation in one small layer.

Herdr compared to cmux

Herdr is not strictly better than cmux. It is a different layer.

cmux is the better Mac desktop terminal: native interface, vertical workspaces, notification rings, and a built-in scriptable browser.

Herdr is the better terminal-native multiplexer: server-owned persistent processes, semantic agent states, and the same interface on my Mac, a remote Linux server, or a small-screen terminal.

They can also work together. Herdr can run inside cmux, with cmux providing the Mac interface and browser while Herdr owns the persistent local or remote terminal session.

The mental model

Herdr has five important concepts:

flowchart TD<br>S["Session"] --> W1["Workspace: flaviocopes.com"]<br>S --> W2["Workspace: product app"]<br>W1 --> T1["Tab: agents"]<br>W1 --> T2["Tab: dev server"]<br>T1 --> P1["Pane: implementation agent"]<br>T1 --> P2["Pane: reviewer agent"]<br>P1 --> A1["Recognized agent"]<br>P2 --> A2["Recognized agent"]<br>A workspace is a project

A workspace is the top-level container.

I use one workspace per repository or focused investigation.

For example, flaviocopes.com can be one workspace and a Prototyped app can be another. Switching workspaces changes the entire project context instead of...