tmux, cmux, herdr: orchestrating agents, not shells
TL;DR
tmux was designed to multiplex human shells; coding agents need something else — seeing who's blocked, who's waiting, who's done. My split: tmux unchanged on servers, herdr locally (adopted within days), cmux if you want turnkey macOS. The question isn't "what replaces tmux" but "one tool per context".
With three or four coding agent sessions running in parallel, my local tmux had become a blind dashboard: indistinguishable panes, no way to tell who was waiting for approval, who was running, who had finished ten minutes ago. tmux multiplexes shells. It doesn’t know — and never claimed to know — that a pane contains an agent with a state.
That’s the real shift in need: we no longer multiplex terminals, we orchestrate a herd of sessions. And a generation of tools was born exactly there.
Before switching, I actually tried to teach it to tmux. A hook wired into Claude Code’s events pushes the agent’s state into the status bar: ● when a turn is running, a bell when it’s waiting for my go-ahead, ✓ when it’s done, ✗ when it crashed — and the marker clears when I give the window focus again. It works, and it’s still in my dotfiles. But it only covers the agent that exposes hooks, it has to be rewired tool by tool, and it solves only the read half of the problem: state comes up, nothing gets driven. Mostly, that hack confirmed the need was real — and that it deserved better than a hook.
tmux keeps the servers, no debate
On servers, nothing displaces tmux: the binary is everywhere, sessions persist across SSH disconnects, zero dependencies. My servers stay on tmux and that won’t change. The trap is concluding it should also stay local for consistency’s sake — that’s consistency that pays nothing.
herdr locally: adopted within days
herdr is a multiplexer designed for agents: it exposes the semantic state of each session (active, blocked, done), is driven by CLI and JSON socket, and is customizable through config and plugins (150+ community plugins indexed via a GitHub tag, per herdr.dev as of July 2026). It runs terminal-side like tmux — Linux/macOS stable, Windows in beta — not as a desktop app.
I’ve only been using it for a few days, on v0.7.3 — and it’s already my daily setup. The tipping point was one thing: the agent itself can drive the multiplexer. A Claude Code skill controls my herdr panes, tabs and workspaces; the agent is no longer a tenant of a pane, it’s a citizen of the tool. In tmux you only approximate that with fragile send-keys scripts.
Two pitfalls verified on v0.7.3, to be honest: herdr server reload-config only half-validates (an unknown action in a binding is ignored silently — “applied” proves nothing), and symbolic key names are QWERTY positions — on an AZERTY keyboard that means dead bindings with no message at all. I lost time on both.
cmux: the turnkey macOS option
I have not used cmux — this paragraph is positioning, not a review. It’s the tool soaking up the current YouTube hype: a native macOS app built on Ghostty, open source (GPL-3.0, ~22k stars as of July 2026), agent-aware notifications, a scriptable built-in browser, all with zero config. The more measured takes sum it up well: a turnkey, opinionated tmux. If you’re on macOS and want something that works immediately with nothing to tune, it’s probably the right default. If you live over SSH or want to shape the tool — keybindings, plugins, agent-driven control — that’s herdr.
One tool per context
The question “what replaces tmux?” isn’t the one to ask. tmux isn’t replaced; it’s refocused on what it does better than anyone: servers. Locally, where the agents live, the seat goes to a tool that understands what it hosts — herdr if you want to customize it and stay cross-platform, cmux if you want turnkey macOS.
The only wrong choice: keeping tmux everywhere out of habit and manually scrolling four panes to find out an agent has been waiting for your go-ahead for twenty minutes.