Tmux Survived 18 Years. It Won't Survive Agents.
Zellij gave me panes. It never told me which agent was waiting. So I moved my whole day 1 layer up.
tmux shipped on November 20, 2007. Since then it buried screen, took the whole GPU terminal wave without blinking, watched Warp show up wanting to replace it, went through the entire Electron era without moving a pixel 🤓 Version 3.6a is dated December 5, 2025. The project is alive, maintained, and it never once needed to reinvent itself. Boring in the best possible way.
What is going to kill it is not a faster multiplexer. It is what lives in the panes now. Before, a pane held a shell waiting for me to type something.
Today it holds an agent that runs alone for 8 minutes, then stops dead to ask for a write permission. tmux does not tell those 2 situations apart. To tmux, it is text scrolling, or text not scrolling.
Might as well get the easy objection out of the way. tmux is not going to disappear from your machine. It is going to disappear from your working day, which is a slower and far more complete death than a deprecation.
The terminal world is going through a new mutation. Right under your eyes!
Tmux Outlived Everything. Agents Are Different.
Let me bound the claim before it runs away. The software is fine. What is dying is the layer where I spend my day, and those are 2 very different funerals.
No maintainer is walking away, nothing is deprecated, and that C codebase under the ISC license will still compile in 10 years and probably in 30.
The thing that pulled me out is called herdr. Early July 2026: roughly 105 days old, sitting near 15,000 GitHub stars, version 0.7.3 in homebrew-core, built by 1 developer working on it full time. Number 1 on GitHub Trending on June 30, 2026. I am dating those numbers on purpose, because the repo was pulling several hundred stars a day when I wrote them down, which is XP grinding at a rate no side project should survive, so whatever you find today is higher.
None of which means the category has picked a winner. On July 23, 2026, Matt Pocock asked his audience which CLI they actually use to run several agents inside 1 terminal, and mentioned he wanted to try herdr. The replies did not converge on anything. People were still comparing 6 different approaches to a problem that did not exist in this shape 2 years ago.
Ghostty Was Never the Problem
My setup, short version. Ghostty as the emulator, Zellij stacked on top, several coding agents running in parallel across projects. It worked. I had no complaint I could have named out loud.
When I moved to herdr, Ghostty did not move. It still runs underneath, same config, same font, same everything. The layer that dropped out was the middle one.
That distinction matters, because a lot of the current coverage blends the 2 things together. An emulator draws characters and handles input. A multiplexer splits that screen into panes and keeps sessions alive when you disconnect. They are 2 different jobs at 2 different layers, and only 1 of them broke.
Zellij did not break in any technical sense. It does exactly what it was written to do, better than tmux in a few places (the built-in layouts alone saved me a config file I never want to write again). It gives you panes. It does not tell you which pane is waiting for you.
With 2 agents, that gap is invisible. AgentsRoom put the escalation better than I would have: 2 agents feel like a superpower, 6 agents give you a dozen tabs where 2 are waiting on a reply you never saw and 1 crashed 20 minutes earlier. At that point you are not running agents, you are patrolling. No party health bar anywhere on screen, and no way to sort the ones bleeding out from the ones idling in town.
Unrelated, but it has been bothering me all week. There is an external drive on my shelf with a label that says BACKUP and a year on it, and I no longer own the cable that plugs into it. I have looked twice. Somewhere in this house there is a drawer where that cable is sitting next to a Wacom pen for a tablet I sold, and I am not going to find either of them by looking.
Your Multiplexer Multiplexes Streams. You Need States.
A multiplexer multiplexes streams. That is the entire job description, and for 18 years it was enough, because a human eye sat in front of every pane and performed a conversion so natural that the conversion never got a name.
You looked at scrolling output and you knew the build was running. A prompt sitting still meant it had finished. A half-written line meant something died. You turned stream into state a few hundred times a day, for free, without ever noticing you were doing it. An agent blocked on a permission request is a state rather than a stream, and there is no eye in front of that pane anymore, because the entire reason you launched 6 agents was to stop sitting in front of them.
The competent objection lands right here, and it is a good one. tmux can already do this. Hooks, a scripted status bar, a wrapper around your agent that writes to a file, and you have your state indicator. True. Kun Chen says as much in his own demo: you can replicate status tracking with hooks, and having it natively changes the experience.
The workaround does not fail. It just has to be configured per machine and per harness, which is the it-works-on-my-machine defense wearing a status bar. Native detection is there the second you open the thing. I wrote about the compensation gap agents cannot close back in March, and this is the same shape one floor up. Developers have compensated for terminal limitations for 30 years and got extremely good at it. The compensation is the tax.
Second half of the mechanism, and Better Stack has been documenting it publicly since June 2026, so I am claiming nothing new. Reading is not enough anymore. The agent needs to write into the workspace: open a pane, launch a sub-agent inside it, read the output, close the pane when the report lands. tmux and Zellij do neither. A workspace only a keyboard can address is a workspace half your workforce cannot touch.
A pane that waits looks exactly like a pane that works.
Step away from the terminal for a second, because this runs past the tooling niche. If you launch 2 or 3 agents on a side project without being a senior developer, the same shift already happened to you. The job moved from doing to supervising. You are not typing the thing anymore, you are watching several things get typed and deciding which one needs you next. The supervision tooling did not follow, and the dashboard that goes with that role change is not in the box. I wrote a whole book about the distance between a demo that runs and something you can actually ship, Vibe Coding, For Real, and this is a new corner of the same gap.
What Herdr Does, and Where It's Rough
Here is what my day looked like before, and I did not think of it as work. Open a pane. Launch the agent. Go do something else. Come back, read 3 panes to figure out which one had finished, close that one, check whether the second was blocked or just slow, scroll up in the third because I could not remember what I had asked it.
None of that is difficult. It is just a job, and it is a job I was doing all day without ever counting it as a job.
What changed is that I stopped reading panes to find out what is happening in them. There are 4 states now, blocked, working, done and idle, and they sit in a sidebar that aggregates every agent across every workspace. A party frame for agents, basically, and it is the whole product as far as I am concerned. The rest is a Rust binary of around 10 MB running inside the terminal I already had, with detach and reattach over SSH, sessions that survive a reboot, and tmux-style prefix keys so my fingers relearned nothing.
The first rough edge is structural rather than a bug. Detection is heuristic, based on process names and output patterns, and it covers roughly 15 harnesses including Claude Code and Codex. A harness that is not on that list goes back to being an ordinary pane with no badge, which means the magic is a guest list and your tool might not be on it.
The part I did not build myself is the socket API, and Kun Chen demoed it while building a project from scratch. His orchestrator creates its own herdr tabs, launches sub-agents inside them, and closes the tab the moment the report comes back, which is the automated version of the manual routine I just described. His second point is the one I had not seen coming: because every sub-agent lives in a real pane, he can walk into it and correct it mid-run. Compare that with the sub-agents of a classic harness, which are opaque by design. You throw a task into a black box and you get a summary back. Here, the box has a door. Worth noting he demos all this inside a tool stack he wrote himself, which makes him informed and not neutral.
That is also the most experimental surface of the product, and Better Stack says so plainly. Agent-driven orchestration through the CLI is the newest thing in there, and new things break. I went at the same problem from a much dumber angle 2 months earlier, building visibility for things that never report state, except I was gluing it together myself with a custom tool. Getting it from the workspace layer instead of from my own duct tape is a different quality of solution.
Second voice, independent from the first, and starting from exactly my setup. Marco Silva ran WezTerm at work and Zellij at home, and says neither came close. He holds 3 to 4 simultaneous OpenCode sessions without losing a single one, which he could not do before, and describes the shift as babysitting turning into check-ins at the moments the agent genuinely needs him. He also flags that resume_agents_on_restore will cheerfully spawn a pile of useless workspaces if you switch projects often, which I can confirm 😬
Windows works, and it is labeled beta with rough edges the maintainer documents openly. I have seen the claim in a video that this is the only multiplexer working properly on Windows, and I would not repeat that as a fact. Linux and macOS are the primary platforms and you can feel it.
Last one, and it tells you how young this project is. The main branch moved to Apache 2.0 on July 22, 2026, presented as removing the biggest adoption blocker for teams. The Homebrew formula was still listing AGPL-3.0-or-later after that date, so for a while the license your package manager displayed was not the license of the repository. Verify it yourself before putting this in front of a legal team, it may well be resolved by the time you read this.
Where Your Control Layer Actually Lives
Terragon Labs shut down on February 9, 2026. The reason sits in their own shutdown page: not enough traction to build a sustainable business. The interesting part is where they pointed their users, which is Claude Code Web and Codex Web, the official offerings from the model vendors themselves. A public code snapshot dated January 16, 2026 is still up, published as-is with no maintenance promise.
Bloop, the company behind Vibe Kanban, closed on April 10, 2026. The project continues as community-maintained Apache-2.0, while the paid cloud product and the remote services stopped. No reason documented anywhere. Crystal is no longer maintained either.
Those 2 tell you the category is deadly without telling you why, and I will leave them at that.
My reading: the orchestration layer looks like it has a shorter lifespan than the problem it solves, and Terragon is the cleanest demonstration of it. Maybe I have the causality wrong and February to April was just a funding window closing on 3 unrelated companies. 3 shutdowns do not make a trend, but they do make me read the terms before I move my day into anything.
Every orchestration layer is a wrapper betting its vendor stays lazy.
The strongest argument against everything I just wrote is called Conductor, and it deserves a fair hearing. It is more readable than a terminal will ever be. Real diff viewer, isolated worktrees per agent, a clean review flow, and for a lot of people that is simply the correct choice. I would not try to talk a team out of it.
The price is architectural. Proprietary binary, macOS only, and a permission model asking for broad access to your GitHub account. That critique comes from a May 29, 2026 write-up relaying a Hacker News comment about read-write access covering settings and deploy keys, so treat it as dated and check the current state yourself.
And herdr is a bet too. 1 developer, full time, 105 days of history at the point I am writing this. If he stops, the sidebar stops.
Which is the actual trade-off, and it has nothing to do with taste. When an app dies it takes your workflow with it, because the workflow lived inside the app. When a local binary dies, your terminal is still there, your sessions are still there, and you fall back to panes. There is no save file to reload either way, so I would rather lose the layer I can afford to lose.
It Leaves the Workflow, Not the Machine
In March I wrote that the terminal was going to have to evolve for agents. I was aiming at the emulator. 4 months later Ghostty has not changed a line and still runs under my entire setup. The mutation happened 1 floor above, in the layer where I spend all my time.
The browser plugin shipped on July 27, 2026 settled it for me. The friction I described in March, rendering a browser inside the session, gets solved by a multiplexer plugin.
tmux is still installed on this machine. I opened it last week to check something and it did exactly what it has done for 18 years, perfectly, without telling me a single thing I needed to know.
Sources
- herdr repository, Ogulcan Celik
- Herdr: Terminal Multiplexer with Built-in AI Agent State Awareness, Better Stack
- Managing OpenCode Sessions with Herdr, Marco Silva
- Herdr Review: Open-Source Agent Multiplexer, Bitdoze
- Terragon shutdown notice
- Best Tools for Managing Parallel AI Coding Agents in 2026, Nimbalyst
- The Best Tools to Run Multiple Coding Agents in 2026, AgentsRoom
- Conductor by Melty Labs in practice, madewithlove
- Kun Chen, building a project from scratch with an agentic workflow
This post may contain affiliate links. If you click them, I might earn a small commission, costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure.
The article shows how agents are reshaping terminal workflows in ways tmux never anticipated. The CLI Blueprint in the welcome kit covers exactly how to structure agent tools so they integrate cleanly with your terminal setup, not fight it.