herdr

The author ultimately chose to keep using herdr rather than Orca, and the decisive question was whether they wanted a new app or a better terminal, and the author chose a better terminal.

herdr is a terminal-native ADE that runs as a standalone Rust binary, with no Electron, and can run side by side with Neovim while inheriting the user's font, theme, and keybindings.

herdr exposes a CLI that agents can use to spawn panes, prompt each other, and wait for another agent to finish or block.

In herdr, the main Claude Code session can automatically hand mechanical work to Codex based on routing rules in CLAUDE.md, open a Codex pane, wait for its status without polling, and stop to ask the user when Codex hits an approval prompt.

Each pane in herdr is marked as working, blocked, or idle, and herdr sends a notification when the user is needed.

herdr's sessions run on a background server, so users can detach, close the laptop, or disconnect SSH, the work keeps running, and reconnecting restores it.

herdr's entire configuration is a single TOML file that can be kept in dotfiles, and migrating from Mac to Linux or connecting to a remote machine over SSH is completely seamless.

herdr does not wrap coding agents, it only manages their terminals, and supports many agents such as Claude Code, Codex, Gemini, Cursor, and OpenCode.

In herdr, fan-out is a Claude Code skill that can create multiple git worktrees for one prompt, launch multiple agents, prompt them in parallel, have each run tests, and finally generate a comparison table, and nothing is merged without the user's approval.

herdr's design philosophy is to keep a thin terminal layer, not build every feature into the core, but let agents extend themselves through generic interfaces such as the CLI and MCP.

herdr identifies which Agent is running in each pane and maintains a finite state machine for each Agent.

herdr maintains four states for each Agent: Working (actively doing work), Block (waiting for a user decision), Idle (finished but not yet reviewed), and Unknown (unrecognizable).

herdr's command-line interface is designed for Agents themselves to use, and having one Agent send a message to another Agent requires only executing the herdr agent prompt command.

herdr supports combining "sending a message" and "waiting for the result" into a single atomic call.

herdr does not wrap or replace any Agent; it simply owns their terminals, achieving Agent identification and communication by controlling the terminal layer.

Application-layer interoperability requires both collaborating parties to use the same SDK or API protocol, forming an ecosystem barrier; terminal-layer interoperability bypasses application-layer protocols, intercepting and injecting at the process and I/O level with no requirements on the Agent's interface.

Using herdr, cross-Agent automated workflows can be built, for example having Agent A automatically send code to Agent B for a code review after finishing writing it.

The herdr solution requires users to set up and configure it themselves, making the configuration cost higher than the official application-layer solution.

herdr is a terminal multiplexer written in Rust, compiled into a single binary, and installed via a one-line cargo install command.