herdr Joins Y Combinator: A Rust Agent Runtime, Not Another tmux

herdr is an open-source Rust agent runtime that owns the terminal sessions your coding agents run in, and on 6 August 2026 it announced it is joining Y Combinator's F26 batch. The announcement came from Can Celik, who built the whole thing alone. This post is my research summary, written the day after: what herdr actually is, how developers received it, and what the YC news does and does not change.

TL;DR

• herdr is a runtime, not an agent. It is a background server that owns the terminal sessions your agents live in. It runs Claude Code, Codex, opencode and the rest — it does not replace them.
• The differentiator is state, plus an API. Every pane is marked working, blocked, or idle, and the CLI and socket API are the same surface agents drive. tmux persists your terminal; it cannot tell you which of your six agents is waiting for an answer, and nothing can call it.
• The numbers are real and the project is one person. 25,000+ GitHub stars, 340,000+ downloads, 500+ plugins within a month of the marketplace opening — all solo.
• The news: F26 batch, group partner Pete Koomen, team size still 1. The runtime stays open, and the licence moved toward permissive — AGPL to Apache-2.0 — not away from it.
• The interesting layer is the runtime, not the agent. Agents are converging on similar capabilities. Where they live is still unsolved, and that is the bet.

The problem: your agent has no home

Run a coding agent today and watch what happens to its terminal.

It spawns one. The agent works, prints, waits. You close the laptop lid, or your SSH connection drops, or the agent process crashes and restarts — and the terminal goes with it. Whatever was half-finished is gone, and there is no record that it was ever running.

That is tolerable when you run one agent for ten minutes. It stops being tolerable the moment you run several for hours. Now you have six terminals, and the only way to know which one needs you is to look at all six. The agent that finished twenty minutes ago has been idle the whole time, wasting the parallelism you were paying for. The one that hit a permission prompt has been blocked just as long, and you had no way to know.

The usual answer is tmux, and tmux genuinely solves half of it. Sessions survive disconnects. You can attach from your phone. But tmux was built for a human sitting at a keyboard, and it owns sessions on that human's behalf. It has no idea what is running inside a pane. Asking "which agent is blocked?" means bell characters, hook scripts, or a polling loop you wrote yourself.

So the gap is not persistence. The gap is that nothing owns the session on the agent's behalf and reports back on what the agent is doing.

What herdr built

herdr's answer is a daemon. It runs in the background on a machine, and it owns every terminal session on that machine. Agents attach to it instead of spawning throwaway terminals; you attach to it too, through a TUI that ships with the runtime.

The organising model is a hierarchy, and Celik states it plainly: "A terminal pane belongs to an agent. A pane belongs to a tab. Tabs belong to a project." That is the whole mental model. Your work is grouped by project, not by whichever terminal window you happened to open it in.

The part that earns the category name is state detection. The repository documents it directly: "every pane is marked working, blocked, or idle. when an agent stops and needs an answer, herdr says so." You do not configure this, and you do not write a hook for it — the runtime infers it from what the pane is doing. That single feature is why herdr is a runtime rather than a nicer multiplexer. A multiplexer holds terminals. A runtime knows what is happening inside them.

Two more things matter in practice. The TUI is not a separate install: "it's bundled. Install Herdr on your VPS, ssh in, and your UI is already there." And getting onto a remote box is one command — "Or run herdr --remote user@host and it installs itself. Depending on your network speed, you're a couple of seconds away from an agent running."

It is also mouse-native. The README offers "tmux-style prefix keys and click, drag, split" — you can keep the muscle memory or ignore it entirely, which turns out to matter more than it sounds like it should.

The part that makes it a runtime

State detection is what you notice first. The socket API is what makes the category name literal.

herdr exposes a socket interface, and the README is precise about its relationship to the command line: "the cli and socket api are the same surface agents drive." One surface, two front doors. Anything you can do by hand, an agent can do programmatically — open a pane, read what is in it, check whether a sibling agent is blocked, spawn more work.

That is the actual dividing line. A multiplexer is something you operate; every integration with one is a script gluing keystrokes together. A runtime is something a program calls. It is the difference between automating a UI and having an API, and it is why an orchestrator agent can treat herdr as infrastructure rather than as a terminal it happens to be sitting in. The 500-plugin month is downstream of this: a Stream Deck button and an iOS app are both just clients of the same surface.

Trying it

Installation is a one-liner — brew install herdr, mise use -g herdr, or curl -fsSL https://herdr.dev/install.sh | sh. There is a PowerShell installer too, though the README labels Windows support beta, which is the one caveat it states about itself.

The origin story

The origin is unusually specific about its own motive. "Four months ago I was looking for another job," Celik writes — thinking about software engineering, hobby projects, whiteboard interviews. Running several agents at once, the realisation was uncomfortable: "At some point it hit me: I am the bottleneck."

The bottleneck was not the agents' capability. It was that supervising them was manual — that a human had to keep checking which one needed attention, and that checking did not scale past a handful. So: "I didn't like what I tried, so why not build it? So I built a runtime."

There is a positioning line in the post that explains why herdr wraps nothing: "Let my agent integrate with your product, don't offer me another agent." That is aimed squarely at every vendor shipping its own coding agent. herdr's bet is that you have already chosen your agent, and what you lack is somewhere for it to live.

The Y Combinator announcement

The news itself is short. "Herdr is joining Y Combinator, F26 batch." YC's company page lists the batch as Fall 2026, the group partner as Pete Koomen, the location as Ankara, Turkey, and the team size as 1.

The reason given is capacity, not ambition: "So a solo project reached 25k stars and 340k downloads, and it became more than one person can carry." The plugin ecosystem makes the point better than the star count does. Within a month of the marketplace opening there were more than 500 plugins, including "A Raycast extension, a Stream Deck with buttons for herdr, an iOS app that drives a whole session from a phone" — none of which Celik wrote.

The commitment that matters to anyone considering adoption is that the runtime stays open, and the licence history supports it rather than undermining it. herdr moved from AGPL to Apache-2.0 before the YC news: "I recently switched it from AGPL to Apache: I want everyone to use Herdr freely, without any problem." That is a move toward permissive, which is the opposite of the usual pre-commercialisation tightening. If you are scanning for the rug-pull signal, this is not it.

Hiring is framed around the runtime rather than around a product: the plan is to bring in "people who keep the runtime healthy, robust, fast, running anywhere easily, and more extensible."

Community reception

herdr's launch discussion on Hacker News — item 48714802, submitted around 30 June 2026, five weeks before the YC news — drew 166 points and 110 comments. It is worth reading as reception of the tool, not of the funding.

The dominant thread is the obvious one: why not tmux? The responses were mostly experiential rather than architectural. Native mouse-wheel scrolling came up repeatedly, described by one commenter as a killer feature over tmux, with the fair counterpoint that tmux 3.6+ can do it once configured. Another cited herdr being more mouse and touch friendly in practice. Copy and paste in tmux came in for the usual complaint — still awkward, even with plugins.

The second theme is the one that maps to the state model: knowing which terminals need attention across many sessions. Commenters described this as genuinely hard in a conventional setup, requiring bell characters or external polling. That is the strongest evidence that herdr found a real gap rather than a stylistic one — the demand was articulated by people who had already built workarounds.

The third theme is remote and mobile. SSH in over Tailscale from a phone or iPad and see every active session — several commenters called this the practical unlock, contrasting it favourably with VNC. It was not uniformly smooth: one Android user reported trouble with tap interactions through Termius.

Commenters also named alternatives they had tried: Zellij, conductor.build, cmux, emdash, Ghostty integrations, and Emacs-based setups. Notably absent from the thread is any complaint about licensing. Third-party write-ups still describing herdr as AGPL with a dual commercial option simply predate the Apache switch — worth knowing if you are researching this from secondary sources.

Competitive landscape

The comparison people actually make is with terminal multiplexers, so that is the honest place to draw the line.

The row that matters is the third. Everything else is degree; that one is a difference in kind. tmux and Zellij are excellent at owning sessions for a person who is present. herdr owns them for a process that is not, and reports the process's state to a person who is elsewhere.

The other names from the thread — cmux, conductor.build, emdash — sit in the same emerging category rather than in the multiplexer one, which is itself the signal: a year ago there was nothing to compare herdr against.

When you don't need this

Worth saying plainly, because the honest answer is not "everyone": if you run one agent at a time and watch it while it works, herdr solves a problem you do not have. You are already the supervisor, the state is on your screen, and tmux — or nothing at all — is fine.

The value turns on concurrency and absence. It arrives when you are running enough agents that you cannot watch them all, or when the machine doing the work is not the machine in front of you. Below that threshold this is a nicer terminal. Above it, it is the difference between parallelism you can actually use and parallelism you are paying for and wasting.

What it means, and what to watch

Three things follow from the announcement, in descending order of confidence.

The roadmap is stated, and it is about connection. Celik is explicit about the next problem: "Herdr can run anywhere today, but those machines are disconnected. It should be connected." Today herdr owns sessions per machine — your laptop, your VPS, a sandbox — and those are three separate worlds. The obvious destination is one view across all of them. That is also the most natural place for a commercial product to sit, which brings us to the second point.

Expect open core. The runtime is Apache-2.0 and the stated intent is that it stays open. Coordination between machines is a different product with different economics — it needs a control plane someone has to run. Nothing has been announced, but that is where the seam is, and it is the seam to watch if you are betting a workflow on this.

The core will stay small on purpose. This is the design commitment I find most credible, because it is stated as a principle rather than a plan: "choosing what goes in the core is the most important decision, I believe. So the core stays small, and everything else stays possible through extensions." The 500-plugin month is the evidence that this works. It is also the discipline most likely to erode under investor pressure, so it is a fair thing to check again in a year.

Beyond herdr specifically, the funding validates a category. YC putting money into a runtime rather than another agent is a statement that the interesting problems have moved down the stack.

My learning summary

What I take from this is a layering argument.

Coding agents are converging. Claude Code, Codex, opencode, Cursor and the rest are differentiated today, but the gap narrows every release, and none of them owns the substrate. The substrate — where an agent runs, whether it survives, whether anyone can see what it is doing — is unsolved and shared. Solving it once, for every agent, is a better position than being the eleventh agent.

It also reframes what "agent infrastructure" means. Most of that phrase's usage today is about giving agents new capabilities: x402 native payments so they can pay for things, Cloudflare Wallets so they have an identity to pay with. herdr is about something duller and more immediate: agents need a place to run before any of that matters. Persistence, supervision and visibility are unglamorous, and they are the ones you hit first.

And there is a smaller lesson in the shape of it. herdr is a single Rust binary that does one thing and refuses to grow — the same instinct behind simpleconf, a small Rust-adjacent tool of my own. Doing one thing well and letting extensions carry the rest is not a new idea. It is just unusually hard to hold onto once there is money involved.

What YC changes is capacity, not direction. What it puts at risk is the small core. Both are worth watching.

FAQ

What is an agent runtime?
A background process that owns where your AI coding agents run. It creates and holds their terminal sessions, keeps them alive across disconnects and restarts, and reports what each agent is doing. It is not itself an agent — it runs the ones you already use.

How is herdr different from tmux?
tmux owns terminal sessions for a human who is at the keyboard; herdr owns them for an agent that is working while you are not. Two concrete differences. State: herdr marks every pane working, blocked, or idle, so you can see which agent needs you, where tmux has no visibility into what runs inside a pane. And programmability: herdr's CLI and socket API are the same surface, so an agent can drive it directly instead of a script faking keystrokes. If you run one agent at a time and watch it, tmux is fine.

Is herdr free?
Yes. It is open source under Apache-2.0, having moved from AGPL before the Y Combinator announcement. No commercial product has been announced.

Which agents does herdr support?
It runs whatever you already run in a terminal — Claude Code, Codex, opencode and others. It does not wrap or replace them; it owns their terminals.

Which YC batch is herdr in?
Fall 2026 (F26). YC lists Pete Koomen as the group partner and the team size as 1.

Does joining YC mean herdr will stop being open source?
The stated commitment is that the runtime stays open, and the licence moved toward permissive rather than away from it. The likeliest commercial shape is open core, with the announced roadmap item — connecting machines that are disconnected today — as the natural paid layer. Nothing has been announced.

Can I use herdr on a remote server?
Yes. herdr --remote user@host installs it on the remote machine itself, and the TUI is bundled, so there is nothing separate to set up.

References

• Herdr is joining Y Combinator. The runtime stays open. — Can Celik, herdr blog, 6 Aug 2026. Every quote above comes from here unless noted.
• herdrdev/herdr on GitHub — source of the working/blocked/idle state model, the socket API, the install commands, the Apache-2.0 licence, and the current star count.
• herdr socket API docs — the surface agents drive.
• Herdr: Agent multiplexer that lives in your terminal — Hacker News, ~30 Jun 2026, 166 points / 110 comments. The community reception section above.
• herdr on Y Combinator — batch, group partner, location, team size.

Written 7 August 2026, one day after the announcement.

Related reading on this site: x402 native payments, Cloudflare Wallets, simpleconf, more AI posts, and all posts.