Herder: The Open-Source Terminal Multiplexer Built for AI Coding Agents
Herder is a free, open-source Rust terminal multiplexer that tracks, notifies on, and orchestrates parallel AI coding agents like Claude Code and Codex.
What is Herder?
Herder is an open-source terminal multiplexer, written in Rust, designed specifically to track and coordinate AI coding agents such as Claude Code, Codex, and about 20 other agent CLIs. Unlike tmux, which treats an agent as just another running process, Herder understands agent state: whether it’s working, blocked on a permission prompt, idle, or finished. It runs inside your existing terminal and adds a sidebar showing the live status of every agent across all your panes.
TL;DR
- Herder tracks four agent states (working, blocked, idle, done) so you can tell at a glance whether an agent needs your attention instead of clicking through panes to check.
- It supports roughly 20 agent CLIs out of the box, including Claude Code, Codex, open code, cursor agent, Copilot CLI, grok CLI, Quen code, kilo code, droid, amp, Devin, and Kiro, with Gemini CLI and Cline flagged as less tested.
- Herder exposes a CLI and local socket API that agents themselves can call, meaning one agent can spin up another agent in a new pane, prompt it, wait for it to finish, and pull back its output without you writing glue code.
- It uses a client-server architecture so sessions persist through disconnects and restarts, and it can natively resume an agent’s actual conversation (using mechanisms like Claude Code’s resume feature) rather than just reopening a blank pane.
- A remote mode lets the server run on another machine over SSH while you keep your local keybindings and theme, so agents can run on a beefy dev box or VPS and you check in from anywhere.
- Installation is a single command on Mac (
brew install herder), Linux (curl script), Windows (PowerShell script), or viacargo install herderfor Rust users. - It’s pre-1.0 software, so expect rough edges: protocol upgrades can require restarting the server, state detection for agents without lifecycle hooks relies on screen-pattern matching, and Windows support lags behind Mac and Linux.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
Why does tracking multiple AI agents become a problem in the first place?
Running one AI coding agent is easy to babysit. Running three or four at once, spread across terminal tabs or tmux panes, is where things fall apart. A standard multiplexer like tmux has no concept of what’s happening inside a pane. It doesn’t know if an agent has been sitting on a permission prompt for ten minutes, or if it quietly finished a task twenty minutes ago while you were looking elsewhere.
That gap between “the agent is running” and “you know what the agent is doing” is the actual bottleneck in parallel agent workflows. Herder was built to close that gap by giving the multiplexer itself an understanding of agent behavior, not just process status.
How does Herder detect agent state?
Herder uses two detection mechanisms depending on the agent. For CLIs with proper lifecycle hooks, the agent reports its own state directly, which is the most reliable signal. For agents without full hook support, including Claude Code as of now, Herder watches the bottom of the terminal buffer and matches it against known UI patterns, such as recognizing the visual shape of a permission prompt to mark an agent as blocked.
The four tracked states are:
- Working: the agent is actively processing.
- Blocked: it’s waiting on you, typically a permission prompt or a question.
- Idle: it’s ready for a new prompt.
- Done: it finished a task but you haven’t reviewed the result yet.
That last distinction between idle and done is a small but useful detail. A finished agent stays flagged until you actually look at it, so completed work doesn’t quietly blend back into the noise of an idle pane. Blocked detection is deliberately conservative, only firing on known approval or question patterns, to avoid false alarms. For better accuracy, you can install per-agent integrations with a command like herder integration install claude, and check what’s active with herder integration status.
What does the interface actually look like?
If you’ve used tmux, the basics translate directly: workspaces (called “spaces”), tabs, split panes, and a prefix key (control B by default) that brings up key bindings. The difference is a persistent sidebar listing every detected agent and its current state, so you don’t have to cycle through panes to check on things.
Herder also treats the mouse as a first-class input method, letting you click to focus panes, drag to resize, and right-click for context menus to split or close panes. That’s a departure from tmux’s typically keyboard-only, prefix-key-driven interaction model, and it lowers the learning curve for people who don’t want to memorize a new set of chords.
Configuration lives in a .config/herder folder, where you can remap the prefix key, adjust the sidebar, set up notifications and scrollback behavior, and choose from built-in themes like Catppuccin, Gruvbox, Nord, and Dracula. Config changes can be reloaded in a running session without restarting anything.
How do agents orchestrate each other through Herder?
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
This is the part that separates Herder from a typical multiplexer. It exposes a CLI and a local socket API, and crucially, an agent running inside Herder can call that API itself. That means one agent can split a pane, launch a second agent, send it a prompt, wait for it to reach a particular state, and read its output back, all without a human manually wiring it together.
The command set includes pane-level operations (pane split, pane run, pane send, pane wait-output, pane read) and agent-level operations (agent start with a --kind flag to specify which CLI to launch, agent prompt with an optional --wait flag to block until a target state, agent wait, agent read, and agent rename to give an agent a stable name like “reviewer” instead of addressing it by pane ID).
A practical example: you tell Claude Code to implement a feature. When it’s done, it runs herder pane split to open a new pane, herder agent start reviewer --kind codex to launch Codex there, herder agent prompt reviewer with review instructions and --wait to block until the review finishes, then herder agent read reviewer to pull the feedback back and act on it. One instruction from you triggers a two-agent review pipeline that would otherwise require manually scripting tmux send-keys calls.
Does session state survive restarts and disconnects?
Yes, and this is one of Herder’s core design points. It uses a client-server model: the server holds the actual terminal sessions, and your client just attaches to it. You can detach, close your laptop, and reattach later with everything still running.
If the server itself restarts, Herder restores the session’s shape (spaces, tabs, panes, working directories, layout). For supported agents, it goes further with native agent session restore, using mechanisms like Claude Code’s built-in resume functionality to bring back the actual conversation context after a restart, not just an empty pane. This is enabled by default and can be turned off in config. There’s also an experimental pane history replay feature for restoring terminal output across restarts, but it ships off by default since scrollback can contain secrets or tokens.
Remote mode extends this further: running Herder with a --remote flag pointing at an SSH host puts the server on that remote machine while your client and local keybindings stay put. Combined with persistence, this lets agents keep running unattended on a server overnight, checkable from any machine.
Is Herder worth using?
If you only run one agent at a time, a plain terminal or tmux does the job fine, and Herder’s added layer isn’t necessary. But for anyone running three or four agents in parallel across different tasks (refactor, bug fix, review, tests), the state-tracking sidebar and orchestration API address a real, concrete pain point: knowing what’s happening without constantly checking.
It’s free, open source, works with agents outside its officially tested list (just without the rich state tracking), and installs in a couple of minutes. The tradeoffs are what you’d expect from pre-1.0 software: protocol upgrades can force a server restart that kills active panes, state detection for non-hooked agents is heuristic rather than a guaranteed signal, Windows support trails Mac and Linux and can’t yet act as a remote target, and nesting tmux inside a Herder pane breaks agent detection.
Frequently Asked Questions
What is Herder used for?
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
Herder is a terminal multiplexer built to run and track multiple AI coding agents at once. It shows the live status of each agent (working, blocked, idle, or done) in a sidebar and lets agents call a CLI and socket API to coordinate with each other.
Which AI coding agents does Herder support?
Herder detects around 20 agent CLIs out of the box, including Claude Code, Codex, open code, cursor agent, Copilot CLI, grok CLI, Quen code, kilo code, droid, amp, Devin, and Kiro. Gemini CLI and Cline are also detected but noted as less tested. Unsupported agents still run as normal terminal processes, just without state tracking.
How is Herder different from tmux?
Tmux has no awareness of what’s happening inside a pane; it just manages terminals as generic processes. Herder adds agent-specific state detection (via lifecycle hooks or screen-pattern matching), a sidebar for at-a-glance monitoring, mouse-first interaction, and an API that agents can call to orchestrate each other.
Can Herder run agents on a remote server?
Yes. Herder’s --remote flag lets the server run on another machine over SSH while the client stays local, keeping your keybindings and theme intact. Combined with session persistence, this supports leaving agents running on a remote box and checking in from any device.
Is Herder stable enough for daily use?
It’s pre-1.0 software, so there are known rough edges: protocol upgrades between versions can require restarting the server (which kills running panes), state detection for agents without lifecycle hooks is heuristic, Windows support is behind Mac and Linux, and running tmux inside a Herder pane breaks agent detection.