What is AgentHerder?

Two things share this name, and which one you're after depends on why you got here.

AgentHerder is a practice. It's the working method for running eight, twelve, fifteen Claude Code sessions at once, on real work, without losing track of what any of them are doing. The whole method is written down as a free self-paced course, and there's a paid cohort for people who want coaching through it.

cctabs is the tool. It's the open-source CLI I wrote because the practice needed one, and it manages Claude Code sessions as native terminal tabs, one tab per session. It used to be called herd and it used to live on this domain, which is why searches for "herder cli" and "herder terminal" still land here. It now has its own package and its own home at cctabs.com.

If you came looking for a session manager, keep reading. If you came looking for the practice, the Course is the better door.

The problem the tool exists for

When you run several Claude Code sessions at the same time you lose track of them, and it happens earlier than most people expect. Which tab is working on what, whether the one you briefed twenty minutes ago finished or is waiting on a question or has been retrying the same broken approach ever since you walked away. At three sessions you can hold all of that in your head, and somewhere around six you can't, and the fleet starts running ahead of your ability to supervise it.

Most of the tooling that grew up around this problem wraps the sessions in tmux. claude-squad, ccmanager and agent-deck all take that route, along with a long tail of orchestration repos on GitHub. tmux gives you panes, persistence, a scriptable layout, and the not-small advantage that plenty of engineers already have it configured, so if you live in tmux all day then putting your sessions there is a sensible thing to do.

I went the other way, because the terminal I was already using did most of what tmux was being brought in for. My tabs were already the multiplexer. So cctabs treats the tab as the unit of orchestration: one tab per session, named for the work it's doing, with the tab title, the Claude session name and the working directory all kept in sync. I wrote out that trade-off in more detail in Claude Code and tmux.

What cctabs does

npm install -g @generativereality/cctabs

cctabs sessions              # every tab, and what its Claude session is doing
cctabs new auth ~/Dev/myapp  # spawn a named tab with Claude running in it
cctabs new auth ~/Dev/myapp --worktree   # ...in its own git worktree
cctabs scrollback auth       # read a tab's output without switching to it
cctabs send api "yes"        # put input into another tab
cctabs fork auth             # branch a conversation, keep the original
cctabs restore               # after a reboot, re-attach Claude to every dead tab

The parts that matter once you're past a handful of sessions:

• A stable identity per tab. Every session has a name, and the name is on the tab, so you can look at a terminal window and know what's where without reading the working directory out of each prompt line. Naming every tab the moment it spawns is a discipline more than a feature, and it's the one that does the most work.
• Restore after a reboot. cctabs restore walks the tabs from your last session and re-attaches Claude to each one, so the fleet you had open on Friday evening is the fleet you walk back into on Monday.
• Fork. cctabs fork <session> opens a new tab carrying the same conversation history and then lets the two diverge, which is the cheap way to try a second approach without giving up the first.
• Reading and writing other tabs. cctabs scrollback and cctabs send let one session read another session's terminal and put input into it. This is the piece that changes the shape of the practice, because Claude can run cctabs itself: a session can spawn siblings, watch what they're doing, and coordinate across them while you're looking at something else.
• Alternative backends. A --backend flag routes a session to Kimi or Qwen via Ollama Cloud, to a local Ollama model, or to an OpenAI-compatible endpoint, which is what you reach for when your Anthropic quota window closes in the middle of an afternoon.

cctabs works out of the box in Wave Terminal, and in Tabby after a one-time companion plugin install. macOS and Linux; Windows works under WSL2.

Where Anthropic's own Agent View fits

Anthropic has since shipped Agent View, which you open with claude agents, and their docs describe it as "one screen for all your background sessions: what's running, what needs your input, and what's done". The sessions it dispatches run under a separate supervisor process, so in Anthropic's words "you can close agent view, close your shell, or start a new interactive session and your dispatched work keeps going."

That covers a real part of what people used to reach for tmux or cctabs to do. If what you want is to fire off a batch of background tasks and check on them when you get back, it's built in now, it's good, and you should use it rather than installing anything.

What it doesn't cover is the foreground half of the practice. On any given day one to three of my streams are not background work at all: there's a dev server running that I'm clicking through, an agent driving a browser against staging that I need to watch, and a stream where I'm iterating in conversation because the problem needs me in the loop. Those want a real terminal I'm looking at, and they want to stay put on a tab while I go and deal with something else. Agent View is deliberately not that, since its sessions aren't terminal-attached at all. The two coexist fine, and I use both.

How it compares to the tmux-based tools

I'm not going to publish a feature grid for claude-squad, ccmanager and agent-deck, because they're all under active development and any checkbox table I write here is wrong within a month. The difference that actually persists is architectural: those tools put your sessions inside a multiplexer they manage, and cctabs leaves your sessions in the terminal you already use and manages the tabs from outside. Which is better depends almost entirely on whether you were a happy tmux user beforehand.

The one thing I'd point at, if you're comparing them, is scrollback and copy-paste. Reading an agent's output is the single most frequent thing you do at fleet scale (you are doing it dozens of times an hour), and native terminal scrollback with native mouse selection is better than the tmux equivalent in a way you feel every single time. That's most of why I built the thing.

Where to go next

• Running Claude Code sessions in parallel — the failure modes that show up between three sessions and twelve, and what to do about each.
• Claude Code and tmux — the panes-versus-tabs question in full, including where Agent View lands.
• The AgentHerder Course — the practice, six weeks, free.
• cctabs.com — the tool's own docs.