herdr
A terminal-native agent multiplexer that runs Claude, Codex, Gemini, and other coding agents side by side in real, persistent panes you can detach from and reattach to from anywhere.
Repository Health
Technical Analysis
Dependency Health
herdr is a Rust-built terminal multiplexer designed specifically for running AI coding agents in parallel. Instead of juggling separate terminal tabs or windows for each agent, herdr gives every agent its own real, PTY-backed pane inside a single workspace, and continuously watches each pane’s output to classify it as idle, working, or blocked — so a glance at the grid tells you exactly which agent needs your attention.
Under the hood it runs a client/server architecture: a background daemon owns the actual terminal sessions and keeps them alive even after you close your terminal or disconnect over SSH, while a lightweight client attaches and detaches from it on demand. That split is what lets you start a batch of agents, walk away, and reattach later — locally or remotely — without losing any session state. herdr also exposes a local socket API so agents themselves can spawn new panes, read other panes’ output, and wait on each other, turning it into an agent-callable orchestration surface rather than just a human-facing dashboard.
The project leans into git-worktree-based agent workflows (auto-generated worktree branch names, per-worktree git status), supports both keyboard-driven tmux-style prefix bindings and full mouse interaction, and ships an installable plugin system with a public plugins marketplace. It’s fully open source under Apache-2.0, distributed as a single dependency-free Rust binary via a curl installer, Homebrew, mise, or a Nix flake, with a Windows beta available separately.
What You Get
- A persistent background server that keeps every agent pane alive across terminal restarts, window closures, and SSH disconnects, so long-running agent work survives you walking away.
- Continuous agent-state detection (idle, working, or blocked) driven by pattern-matching each pane’s live terminal output against a maintained manifest of known coding-agent signatures, shown at a glance across all open panes.
- A local socket API that agents themselves can call to spawn new panes, read another pane’s output, and wait on other agents to finish, enabling agent-orchestrates-agent workflows beyond simple human supervision.
- Native git worktree awareness, including auto-generated, human-readable worktree branch names and per-worktree ahead/behind status folded directly into the workspace/tab model.
- An installable plugin system, backed by a public plugins marketplace, for extending panes and workflows beyond what ships in the core binary.
- Cross-platform, dependency-free single-binary installs via a curl script, Homebrew, mise, or a Nix flake, plus a Windows beta with native ConPTY support.
Common Use Cases
- Supervising multiple parallel coding agents - a developer runs Claude, Codex, and Gemini each in its own herdr pane against the same or different checkouts, and scans the pane grid to see instantly which agent is blocked waiting on input versus still working.
- Remote and SSH-based agent sessions - an engineer kicks off long-running agent work on a remote dev box or cloud VM, detaches, and reattaches later from a laptop or a different terminal without losing pane state or history.
- Agent-to-agent orchestration - a coordinating agent uses herdr’s socket API to spawn worker-agent panes, poll their state, and wait for them to finish before continuing its own task, rather than a human manually managing each pane.
- One agent per git worktree - a team gives each coding agent its own auto-named git worktree and branch inside a dedicated herdr workspace tab, keeping concurrent agents from colliding on the same working directory.
- A terminal-only alternative to Electron agent dashboards - a developer who wants no Electron runtime, no hosted control plane, and no telemetry runs herdr as a lightweight, self-hosted, terminal-native way to watch and control agent sessions.
Under The Hood
Architecture herdr follows a client/server model: a background daemon owns the actual PTY-backed terminal sessions and keeps running headless even when no client is attached, while a lightweight client attaches over a local socket (Unix domain sockets or Windows named pipes) to render and interact with them. That split is what makes detach/reattach possible — sessions survive terminal restarts and SSH disconnects because the server never depends on a live client connection. On top of the client sits an app loop that owns workspace, tab, and pane state and a rendering layer that serializes terminal output to send across the wire. The agent-facing socket API is deliberately kept separate from this pane-rendering protocol — agents speak a distinct, schema-typed API (spawn, read, wait) rather than the same wire format panes use to render — and agent-state detection is layered on top of both as an independent concern that tails pane output and classifies it without touching the render or API layers. Session persistence to disk is a further, separate recovery path from the live-attach path, and git-worktree awareness is folded into the workspace layer as a submodule rather than a top-level concern. This is a genuinely modular, layered design; because every higher layer (rendering, detection, persistence, the agent API) consumes the core terminal-session abstraction’s model of state, a change to that core would ripple through all of them.
Tech Stack herdr is a Rust binary built against a pinned toolchain with clippy and rustfmt as first-class components. Its terminal UI layer combines ratatui with crossterm for raw-mode, mouse, and keyboard-event handling, while cross-platform pseudo-terminal spawning goes through a vendored, patched fork of portable-pty — including native Windows ConPTY support with direct Win32/job-object bindings for process-tree management. Local IPC between the server daemon and clients uses a cross-platform local-socket abstraction, with a compact binary format plus JSON for wire serialization and a schema-generation crate for typing the agent-facing API. An async multi-threaded runtime drives the server and client event loops, CLI parsing uses a trimmed-down argument-parsing crate, and structured logging writes to a local log file. Configuration and session state are plain TOML and JSON files under the user’s config directory. Build and release tooling includes a Nix flake for reproducible builds, a task runner driving a fast Rust test runner alongside supplementary Python test scripts for documentation and packaging hygiene, and a dedicated CI pipeline covering cross-platform artifact builds, a companion Astro-based documentation/marketing site, and installers for curl, Homebrew, mise, and Nix.
Code Quality Testing is integration-heavy: a dedicated test suite exercises real client/server behavior — attach/detach, multiple simultaneous clients, headless server operation, cross-area interaction — run through a fast, isolated test runner rather than relying solely on unit tests. Supplementary Python test scripts check the project’s own documentation and process hygiene (changelog format, config-reference accuracy, translation parity, vendored-patch integrity), an unusual but deliberate practice layered on top of the core Rust suite. Linting is strict, with warnings treated as build failures and a customized threshold for clippy’s argument-count lint, plus mandatory formatting checks. Error handling in the sampled modules favors idiomatic result propagation over panics or silent failure. Domain state is modeled with explicit enums (agent state, specific supported agents) rather than stringly-typed alternatives, and the agent-facing API is schema-typed rather than loosely structured JSON. CI runs the full lint-and-test matrix plus a separate reproducible Nix build and a dedicated Windows-specific lint pass, giving genuine cross-platform verification rather than a single-OS pipeline.
What Makes It Unique What sets herdr apart from a plain terminal multiplexer or a browser-based agent dashboard is that it treats agent-state awareness as a first-class primitive rather than a bolt-on: it actively classifies each pane’s live output against a maintained catalog of coding-agent output signatures, turning “which of my agents needs me right now” into an at-a-glance visual state instead of manual tab-switching. Its socket API is a second differentiator — panes are addressable, spawnable, and waitable resources over a local protocol, so agents themselves can orchestrate other agent panes rather than only being watched by a human, an agent-native automation surface that generic multiplexers and hosted dashboards don’t expose without a control plane. Native git-worktree awareness, with auto-generated worktree naming folded directly into the pane/tab model, is a further, more incremental differentiator aimed at the increasingly common one-agent-per-worktree workflow. None of these ideas are individually unprecedented, but combining real PTY-backed panes, built-in agent-state detection, an agent-callable socket API, and worktree awareness into a single self-hosted binary is a fairly novel synthesis for this specific niche.
Self-Hosting
Licensing Model herdr is licensed under Apache License 2.0 — a permissive, business-friendly open-source license with no license keys, paid tiers, or self-hosting restrictions for any feature in the codebase.
Self-Hosting Restrictions
None found. There are no ee/, enterprise/, or pro/ directories in the repository, and no license-check or feature-flag gating logic anywhere in the source.
Enterprise Features There is no separate paid tier. The project’s own pricing page states plainly that it is free, self-hosted only, with no account and no telemetry; the only commercial angle is optional GitHub Sponsors funding (with an “Enterprise / partnership” contact for custom sponsorship, not a licensed product tier).
Cloud vs Self-Hosted Not applicable — herdr explicitly has no hosted control plane; it is self-hosted by design, described on its own site as “not a browser dashboard.”
License Key Required No. All functionality, including the plugin system and socket API, is available without any license key or account.
Related Apps
claw-code
AI Agents · AI Code Assistants
A Rust-built CLI agent harness for Claude AI with persistent sessions, MCP tool integration, plugin hooks, and multi-provider support — designed to run autonomous coding workflows without human babysitting.
Ollama
AI Development · Developer Tools
Run Llama, Gemma, DeepSeek, and other open LLMs on your own machine with one command and an OpenAI-compatible API.
Firecrawl
AI Development · Developer Tools
Turn any website into clean, LLM-ready data with a single API call — no proxy headaches, no scraping complexity.