Herdr Deep Dive: Inside the Agent-Native Terminal Multiplexer

Last updated: August 23, 2026

Run one coding agent and any terminal works. Run six, and the terminal becomes the bottleneck: one agent has been sitting at an approval prompt for two hours, another finished while you were reading a diff somewhere else, and a third died twenty minutes ago and nothing told you. Herdr, a Rust terminal multiplexer rebuilt around coding agents, is the most popular attempt to fix exactly this. It went from a repo nobody noticed in May to roughly 31,800 GitHub stars, two large Hacker News launches, an independent wave of third-party tooling, and a Y Combinator announcement in under five months.

This is the flagship post of our Herdr series: what Herdr actually is, how its agent-awareness works under the hood, what the traction record really looks like when you check primary sources, and where the honest limits are.

Official Sources#

Live repository snapshot, pulled from the GitHub API on August 23, 2026: 31,766 stars, 2,272 forks, 224 open issues, 92 watchers, language Rust, license Apache-2.0, latest push the same day. The project ships as a single binary with no Electron shell, no account requirement, and per its own README, no telemetry.

The Problem: N Agents, One Screen#

A single agent session needs nothing more than a terminal. A fleet needs answers to questions that plain terminals cannot ask:

• Which of these eight panes is still making progress?
• Which agent stopped ten minutes ago because it wants permission to run a command?
• Which one finished successfully while its tab sat in the background?
• What survives when you close your laptop lid or drop an SSH connection?

The failure mode is not exotic. In the July Hacker News thread, a user running more than ten parallel agents described the pre-Herdr experience plainly: tmux "was not making this particular workflow easy and I would occasionally lose an agent or forget about it until much later only to realize it's been sitting idle waiting for me to approve something for a few days."

Why not just script tmux? That exact question opened the June 29 thread, and the discussion produced the clearest articulation of the gap. The classic workarounds all infer completion from the outside: configure each agent harness to emit a terminal bell when it finishes, poll for a silent pane, or attach a stop hook. One commenter who had tried the polling route summed up the flaw: silence for N seconds "doesn't know if that really means waiting for input or something else." An agent that pauses to think looks identical to an agent that paused to ask you something. The signal is ambiguous precisely at the moment that matters.

That is the orchestration gap above individual CLIs. Each agent harness knows its own state internally, but nothing sits above all of them translating that state into attention guidance. tmux and Zellij are excellent general-purpose multiplexers, but they treat every process as an undifferentiated PTY. Graphical agent managers understand agent state, but they typically wrap the terminal in their own application and do not follow you onto a headless Linux box over SSH. Herdr positions itself between those two camps, keeping the real terminal model and adding the layer that understands what is running inside it.

What Herdr Actually Is#

The README calls Herdr "the runtime your coding agents live on," which sounds abstract until you look at the architecture. The shortest honest description comes from Flavio Copes' August deep dive: "Herdr is tmux rebuilt around coding agents."

Concretely, it is a client-server terminal multiplexer in one Rust binary:

• The herdr command starts or attaches to a background server. The server owns the pseudo-terminals, child processes, live pane state, and session layout. Clients render that state and ship input back.
• Because the process tree belongs to the server rather than the visible window, detaching keeps everything running. Close the terminal, drop the network, shut the laptop lid, and reattach later from any terminal, over plain SSH, or from a phone. Multiple clients can attach to the same session at once.
• herdr --remote ssh://you@server turns the local binary into a thin client for a remote server, so a desktop machine can drive sessions living elsewhere.

On top of that runtime sits a hierarchy borrowed from multiplexers and extended one level further than tmux goes: sessions contain workspaces, workspaces contain tabs, tabs contain panes, and panes may contain recognized agents. A workspace maps naturally to a project and rolls up the states of everything inside it. A pane is always a real terminal; an agent is a distinct concept that exists only when Herdr identifies a coding-agent process inside that pane. This distinction matters because a test runner deserves raw terminal treatment while Codex deserves lifecycle tracking, and Herdr can give each layer different commands.

Two interface properties round out the pitch. First, it does not replace your agents. The README is explicit that Herdr "doesn't wrap or replace them; it owns their terminals": Claude Code, Codex, Cursor Agent CLI, OpenCode, Grok, Pi and friends keep running unmodified. Second, mouse and keyboard are both first-class. There is a conventional tmux-style prefix (default ctrl+b, detach with ctrl+b q) alongside click-to-focus, drag-to-resize splits, and native-feeling wheel scrolling. That last one sounds minor until you hear a Hacker News commenter call it "a killer feature over tmux" after failing to find it documented anywhere.

Under the Hood#

Completion detection, not scrollback inference#

The load-bearing feature is agent state tracking, and the interesting question is how a passive multiplexer achieves it without modifying the agents. Per the project's documentation and Copes' verification, detection happens in two layers.

Layer one is process identity: Herdr watches the foreground process in each pane. Layer two is what the project calls screen manifests: rule sets that examine the live bottom region of the terminal screen and match known interface states, the same way a person glances at whether Claude Code is showing a spinner or an approval prompt. This works with no hooks or configuration for many mainstream agents, and the manifest database updates remotely as agent interfaces change, so a redesigned prompt UI does not require waiting for a Herdr release.

Every pane lands in one of five states: working, blocked, done, idle, or unknown. Two design choices here deserve attention. done is not a condition the agent reports; it is an attention state meaning the agent became ready while its tab was unviewed, and it clears back to idle once you look. And unknown honestly means unknown: Herdr saw something it could not confidently classify, rather than guessing. States roll upward, so a blocked agent marks its tab and workspace blocked, which is what makes the sidebar usable as an operations view across several projects.

For agents that can cooperate directly, official integrations go deeper than screen matching. Running herdr integration install claude (or codex, cursor, and others) lets the integration report lifecycle state and, importantly, the agent's native session ID. Session identity is what makes conversation resumption possible after a full server restart: Codex can come back via its resume mechanism instead of leaving you an empty shell. When a state looks wrong, herdr agent explain <target> shows exactly which detection source and which rule produced the verdict, which is more debuggable than most black-box automation.

Contrast this with the alternatives discussed on Hacker News: bell characters configured per harness, external tools polling tmux for silence, or stop hooks wired into each agent separately. Those approaches scale linearly with your patience. Screen manifests put the burden on the multiplexer, once, for every agent it recognizes.

Wait primitives built on real state#

Once states exist, they become synchronization primitives, and this is where Herdr stops being a viewer and becomes infrastructure. The CLI exposes three surfaces: layout commands for workspaces, tabs and panes; pane commands for raw terminals; and agent commands for recognized agents.

The signature primitive is prompting with a wait condition:

herdr agent prompt reviewer \
  "Review the current diff and report actionable findings." \
  --wait \
  --timeout 600000

That call blocks until the agent reaches a settled idle, done, or blocked state, not until some regex appears in scrollback. For non-agent processes there is the analogous herdr pane wait-output --regex "passed|failed" --timeout, and for guardrail flows there is herdr agent wait reviewer --until blocked, which fires when an approval interface appears rather than when text happens to contain the word "blocked." Scripts and coordinating agents address targets by stable IDs such as w1:t1 and w1:p2 returned as JSON, avoiding the classic bug of prompting whichever terminal happens to be focused. The whole surface is mirrored by a local socket API with event subscriptions, which is how agents drive Herdr itself: spawning panes, prompting other agents, and waiting on each other's genuine blocked state instead of sleeping for thirty seconds.

The config model#

Configuration lives in ~/.config/herdr/config.toml and hot-reloads via herdr server reload-config. The shape follows the features: a [keys] section remaps the prefix and bindings, [ui.toast] controls notification delivery (in-app, outer terminal, or OS-level, suppressed for the tab you are already watching, with sound options under [ui.sound.agents]), and [ui.sidebar.agents] rearranges the sidebar rows, letting integrations inject live tokens like model names into what is effectively a tiny status dashboard.

One default worth knowing: restoring pane screen history across a server restart is experimental and disabled. The stated tradeoff is sensible, since terminal scrollbacks routinely contain prompts, logs, and secrets, and persisting them creates another sensitive file on disk.

Integrations and plugins#

Beyond first-party integrations, the extension model is deliberately thin. A plugin is an executable package with a herdr-plugin.toml manifest, implemented in Bash, JavaScript, Lua, Rust or anything else the machine can run. There is no separate SDK: plugins use the same CLI and socket API that humans and agents use. The official marketplace index listed 762 plugins across 749 repositories as of August 23, 2026, up from the "more than 500 plugins" cited in the company's own YC announcement three weeks earlier. Since plugins execute locally with your permissions, the usual caution applies: inspect before you trust.

The Traction Record#

Strip away the hype and the timeline is unusually clean, because almost none of it was self-submitted.

Two details stand out. The founder never submitted his own project to Hacker News; an Algolia author search shows his only submissions there are an unrelated Show HN from December 2025 and a 2023 support post. All three big threads were posted by users who found the tool independently, which is the organic-growth pattern every launch playbook pretends to have. And the curve did not flatten after YC: roughly 6,800 stars arrived in the seventeen days after the announcement, with the repo taking its 31,000th-star victory lap while still shipping daily.

Ecosystem velocity tells the same story from a different angle. Within weeks of the plugin marketplace opening, a constellation of third-party clients and bridges formed around the socket API. A sample from our ecosystem sweep on August 23, with the starred entries spot-checked against the GitHub API:

The YC post name-drops the strangest ones with evident delight: a Raycast extension, Stream Deck buttons wired to Herdr, and an iOS app driving a full session, none built by the core team. For a runtime whose thesis is that clients are commodities above a persistent process owner, that is the thesis proving itself.

Independent Takes#

Flavio Copes, whose August 10 deep dive is the best public technical treatment, came away convinced but precise about why. His killer feature is not persistence, which tmux already sells, but the agent sidebar: "This removes terminal polling. I do not need to open six tabs every few minutes to see whether an agent stopped. I look at one sidebar and go where my attention is needed." He also contributed the sharpest framing of the architecture: Herdr is "an interface for me, and a control plane for the agents," with no export step between the human view and the automation view. His criticisms, covered below, are structural rather than nitpicks.

Hacker News ran the full spectrum. On the positive side, users reported multi-device workflows that previously required gymnastics: attaching from a desktop at home and picking the same session up over SSH from a laptop at a doctor's appointment. Others praised that the tool "doesn't punish you for not remembering the bindings, everything is clickable," that copy-paste finally just works where tmux history plumbing has always been fiddly, and that the socket API is clean enough to build products on top of. One enterprise-flavored take worth quoting: the value was connecting local agents to already-existing remote sandboxes "without adding a new vendor" to infrastructure.

The skepticism clustered into a few honest camps. The largest asked what problem this solves that tmux does not: "I read the website and still don't understand what this solves. Doesn't tmux and zellij do all of these things?" A thoughtful version of that critique itemized Herdr's actual deltas (mouse-first interaction, popups, agent status display, clipboard defaults) and concluded "otherwise it seems exactly like tmux," which is either damning or a fair description of a good niche product depending on how many agents you run. Another camp preferred graphical managers outright, arguing conductor.build was better and that "running in the terminal is a flex" rather than an advantage. The bluntest comment in the biggest thread was two words: "Vibecoded. Nope." There were also legitimate jabs at marketing choices, with the landing page's logo marquee called out as lawyer-bait and "the most annoying thing of this software era." Notably, we could find no founder replies in either launch thread; the defense was mounted entirely by users.

The YC Chapter and the Open-Runtime Commitment#

On August 6, founder Can Celik (GitHub handle ogulcancelik) announced that Herdr is joining Y Combinator's F26 batch, writing as "the only person behind Herdr." The origin story in that post explains a lot about the product's shape: four months earlier he was job hunting, dreading whiteboard interviews, and realized "I am the bottleneck" - not the models. He wanted agents managed from the terminal he already lives in, and he wanted other products to integrate with his agent rather than shipping yet another agent of their own.

The commitments in that post are unusually specific, likely because the audience was skeptical by default:

• The runtime stays free and open source under Apache-2.0. The license switch from AGPL to Apache happened right before the announcement, with the stated reason "I want everyone to use Herdr freely."
• The core stays small. In Celik's words, choosing what stays out of the core is the most important decision, and everything else belongs to extensions.
• The TUI remains first-class forever, because bundling it means SSH-ing into a VPS gives you a complete UI with zero setup.
• The roadmap is about connection, not features: a laptop, a VPS running a six-hour job, and a sandbox for risky code are all places Herdr already runs, and the plan is to make those disconnected machines act as one.

At announcement time the project stood at 25,000 stars and 340,000 downloads. Whether a venture-scale business can be built above a free runtime that refuses to grow is the open question the post deliberately leaves unanswered, pointing only at demand for "multiple clients" as the commercial wedge.

Honest Limits#

Herdr coordinates terminals; it does not solve multi-agent engineering, and its critics and fans agree on this more than on anything else. The concrete boundaries, drawn from the independent deep dive and the launch threads:

• No isolation. Two panes pointed at the same checkout can edit the same files. Safe parallelism still requires git worktrees and task discipline that Herdr does not enforce.
• Orchestration is not shared memory. Agents talk through the socket API, but project context syncs through files and git like any other processes. Nothing merges mental models for you.
• Detection is probabilistic. Screen manifests break when agent interfaces change, wrappers hide foreground processes, and unsupported agents stay unknown. The project's own docs treat unknown as exactly that, not success.
• A server restart kills child processes. Detach survives anything; restarting the server restores layout and directories, resumes conversations only where integrations recorded session IDs, and resurrects nothing else.
• It is not an agent platform. No task graph, no approval policy engine, no durable event history. If you want organizational workflow management, Herdr is intentionally beneath that layer.
• Rough edges remain: early users found keybindings inconsistent, copy-paste inside redraw-heavy outer terminals like wezterm fights selections, and subagent wiring puzzled at least one would-be user publicly.

None of these are disqualifying for the tool's actual scope. All of them are reasons to arrive knowing what you bought.

FAQ#

Is Herdr free and open source?#

Yes. The runtime is licensed Apache-2.0, switched from AGPL shortly before the August 2026 YC announcement specifically to permit unrestricted use. There is no paid tier yet, no account, and no hosted component required.

How is Herdr different from tmux?#

tmux multiplexes anonymous terminals. Herdr multiplexes terminals plus knowledge of which terminals contain agents: five-state lifecycle tracking, a sidebar that rolls status up per project, agent-addressable CLI commands, wait primitives that block on real completion states, and a mouse-native interface. Detach, reattach and SSH behavior feel familiar to tmux users by design.

Which coding agents does Herdr support?#

Screen-manifest detection covers Claude Code, Codex, Cursor Agent CLI, OpenCode, Pi, GitHub Copilot CLI, Devin, Kimi, Droid and others, with official integrations adding direct state reporting and session-ID-based resume for major harnesses. Anything unrecognized still runs perfectly well as an ordinary pane; it simply gets no lifecycle state.

Does Herdr know when an agent actually finishes?#

As well as screen inspection allows. Detection combines foreground-process identity with screen manifests matched against the live bottom of the pane, and herdr agent explain shows which rule produced a state. It is materially more reliable than silence polling or bell hacks, but the docs themselves admit classification is imperfect and unknown means unknown.

What happens if I close my laptop or the server restarts?#

Those are different events. Closing the client or dropping the network detaches you; the server keeps every process alive and you reattach to the exact same live terminals. Stopping the Herdr server stops its child processes; layout and directories restore on next start, supported agent conversations resume via recorded session IDs, and ordinary processes start fresh.

Can I use it remotely, including from a phone?#

Yes, twice over. Plain SSH into the machine and run herdr for the full bundled TUI, which adapts to narrow screens, or use herdr --remote host from your local machine as a thin client that preserves local desktop conveniences. Third-party mobile clients exist precisely because the runtime is client-agnostic.

What is Herdr written in, and how heavy is it?#

One Rust binary compiled per platform, no Electron, no telemetry, running inside whatever terminal emulator you already have. Development happens in the open with cargo; the repo carried roughly 1,460 commits and 2,270 forks by late August 2026.

Is Herdr a company now?#

Yes. Founder Can Celik took it through Y Combinator's F26 batch as Herdr, Inc., announced August 6, 2026, with the explicit commitment that the runtime stays free and Apache-licensed while the company builds above it. What that commercial layer looks like remains the most-watched unknown in the project's future.

This deep dive is part one of our four-part Herdr cluster. If you are ready to get hands-on, the Herdr setup guide walks through verified install steps and three real fleet patterns. To see how Herdr stacks against the harnesses it orchestrates, read Herdr vs Pi vs tmux. For the business and community angle, the YC and plugin ecosystem analysis tracks what 762 plugins in five weeks actually means. And if you want the broader context on terminal-first agent workflows, start with our OpenCode developer guide and CLIs over MCPs.