Why Are There So Many New Terminal Multiplexers? — Peter Pistorius

Blog

Why are there so many new terminal multiplexers?

July 30, 2026

There are a bunch of new terminal multiplexers coming out.

We already have tmux, screen, Zellij, and WezTerm’s built-in multiplexer. Now we have Herdr, cmux with its own take on the idea, zmx, and Mitchell Hashimoto’s announcement of Superlogical.

I also want a new multiplexer for Machinen Desktop, and I want to explain why.

I think the real reason we are getting all these different multiplexers is that we are using our computers very differently than before.

The problem

Traditional multiplexers were designed around a person actively operating a terminal.

You open a terminal, start some programs, arrange them into windows and panes, and move between them. The multiplexer keeps those programs running if you disconnect, but the person operating the terminal remains at the center of the session.

That is no longer true when agents work independently for hours.

It is also no longer true when many agents and many people are working inside an organization. An agent may be working while nobody is watching. I may want to check it from another computer. A colleague may want to see what it is doing. Another agent may need to inspect its output or interact with it.

We also want to share compute.

The work might be running on my computer, your computer, a machine in the office, or a cloud computer. Where it runs still matters for performance, data, credentials, and security. It should not decide who can see the work or which interface they have to use.

The work should be able to stay on the computer where it is already running. Other people and agents should be able to connect to it there.

You want the session to remain available when you close the terminal, restart an application, lose an SSH connection, or move to another computer.

You want the output to exist separately from the terminal currently displaying it. It should be searchable and replayable instead of living only as scrollback in one terminal window.

You also want the session to be multiplayer. Several people and agents should be able to see and interact with the same work at the same time.

Terminal applications are here to stay

It is clear to me that terminal applications are here to stay because they are the most composable software we have.

A terminal application can run on my laptop, over SSH, inside a VM, or on a cloud computer. It can run inside a regular terminal emulator or behind a graphical application. Other software can start it, send it input, and read its output.

The application does not need to know whether I am looking at it through Kitty, Ghostty, a browser, Machinen Desktop, or something else that has not been built yet.

We do not need to replace terminal applications to support the way we are starting to work.

We need to separate the terminal session from the personal viewing experience.

The server should own the session

The server should own the PTY and keep the process running when clients disconnect.

The session should have an identity that does not depend on a particular window, application, process ID, or network connection. I should be able to find it again from another client or another computer.

The server should keep a durable record of the output and enough terminal state for a client to reconnect. That record should be available to software so it can be searched and replayed.

The server should also know which people and agents are connected. Several clients should be able to receive output and send input to the same session.

These are properties of the session:

The PTY and process lifetime

A stable session identity

Terminal output and checkpoints

Connected participants

Input from those participants

Reconnection and recovery

A protocol that other software can use

The personal view of the session does not need to be part of that state.

The client should own the view

The client should decide which sessions are visible and how they are arranged.

A desktop client may use spatial windows. Another client may use tabs. A browser may show a grid. A regular terminal may attach to one session directly. A phone may show status and recent output.

Each client should have its own focus, scroll position, selection, and viewport. One person reading earlier output should not move another person’s view.

Those clients should be able to use the same sessions without having to reproduce the same layout.

Server:

+-------+ +-------+ +-------+<br>| PTY A | | PTY B | | PTY C |<br>+-------+ +-------+ +-------+<br>| | |<br>+--------+---------+<br>each client<br>chooses a view

Desktop: Phone:

+-----+-----+ +-----+<br>| A | B | | B |<br>+-----+-----+ +-----+<br>| C |<br>+-----------+

This is the problem I have with tmux. The tmux server owns windows, panes, focus, and layout. Every attached client has to understand and reproduce that view.

Herdr has the same issue. Its server owns workspaces, tabs, panes,...