Superlogical costs four times tmux to start, and wins from the second full terminal

Mitchell Hashimoto published memory benchmarks for Superlogical on September 2nd, measured on macOS 26.6.2 on an M4 Max using physical footprint. His framing is scale, and the reason he gives for caring about it is agents: "They like to spawn more sessions than we've ever seen, and they are all their own clients."

Mitchell Hashimoto@mitchellh

The Superlogical server is built to run anywhere and everywhere and serve a level of scale (terminals+clients) unmatched w/ prior solutions. So let's start talking about that, starting with memory usage and comparisons to other popular multiplexers.

I want to start by talking high level: why does terminal/client scale matter? This matters because we're seeing unprecedented terminal usage and client attachment mainly due to AI. They like to spawn more sessions than we've ever seen, and they are all their own clients. So we have to optimize it. Even if you don't use AI/agents, this just makes the software better for humans, too.

Okay, onto the results. First thing to notice is that while tmux's empty states are excellent, Superlogical makes it up at scale and there is an early breakpoint with busy terminals and clients where we use significantly less memory than tmux or anyone else.

Zellij simply does very poorly. There is no other way to put it. Its default out of the box empty footprint is high. And its per-client attachment is simply unscalable. It was clearly meant in its current form for smal single-human low-terminal-count scale.

The per-client attachment for Zellij was so unbelievable I had to dig into why. Out of the box (zero config) Zellij has a tab bar and status bar plugin. These are wasm-plugins and each tab gets an instantiation. Each instantiation is its own wasm runtime. Huge memory explosion. I also noticed the memory was never reclaimed when I closed the tabs (even when waiting for minutes for memory to settle) but didn't dig into that more.

Anyways, credit where credit is due tmux has excellent memory usage for empty states. The tmux project has always been great and they've been really receptive to the bugs I've found via Ghostty or the protocols we've championed. Much respect.

I'm going to talk more about how we achieve this in a follow-up video.

The charts are honest, including where they lose. An empty Superlogical server takes 10.6 MiB against tmux's 2.50 MiB, and an empty 80×24 terminal costs it 68 KiB against tmux's 15 KiB. On both of those, tmux wins by a factor of four.

Hashimoto says there is "an early breakpoint with busy terminals and clients" where Superlogical pulls ahead. He does not say where it is. So we did the subtraction (his charts have the numbers; they just sit on four separate images).

Fill a terminal with 10,000 lines of prose and tmux spends 4.89 MiB on it. Superlogical spends 407 KiB — about a twelfth. That saves 4.48 MiB per filled terminal against a starting deficit of 8.1 MiB, which means Superlogical is behind at one filled terminal and ahead at two. Two.

That is the whole argument, and it is a narrower argument than "scale". Superlogical is not better at having many terminals; per empty terminal it is 4.5 times worse than tmux and always will be. It is better at holding what is in them. Which happens to be roughly the workload agents produce — long, noisy scrollback nobody is reading — so the AI framing probably lands, but through storage rather than session count.

Per client connection, with 50 filled terminals attached: Superlogical 85 KiB, tmux 157 KiB. Both fine. Zellij out of the box (that is, with no configuration at all): 1.56 GiB.

That last figure is worth sitting with. Fifty attached clients of default Zellij would be roughly 78 GiB of server memory before anybody runs a command. Hashimoto went and found out why, and the answer is the sort of thing you only learn by reading someone else's plugin system: Zellij ships a tab bar and a status bar as wasm plugins, each tab instantiates them, and each instantiation is its own wasm runtime. He also reports the memory was never reclaimed after closing tabs, though he says he did not dig further into that.

He is generous about tmux, twice, and specific about why it wins: "credit where credit is due tmux has excellent memory usage for empty states."

Our read is that this benchmark is a recruiting document aimed at exactly one person — the tmux user who has never had a reason to move — and that the numbers are good enough to work on them, with a caveat worth saying out loud. They are the vendor's numbers, on one machine, on one OS, and nobody has reproduced them. Superlogical is not shipping yet. "Hope we can bring you something you can use soon," is where the demo ended on August 28th.

The architecture underneath is the part we would want to see stress-tested first. Hashimoto describes "a custom binary protocol where the server is maintaining N replica distributed terminal state machines", which is how you get a session that survives closing your laptop and reopening it on a phone. It is also a class of system with a long history of interesting failure modes, and 407 KiB of scrollback per terminal is likely only true while the replication keeps doing something clever with it.

What does the company actually intend to sell? Not a terminal, on its own telling. The plan on superlogical.com is three steps — build an incredible multiplexer, make everything in it composable, make it safe and operable in production — and the team is Hashimoto with HashiCorp's first employee, Vercel's former VP of Design, and a designer from Poolside. That is probably not a roster assembled to compete with tmux.

Hashimoto said the platforms for the first public release are undecided. We would bet on macOS and the web first, Linux after, and we would be happy to be wrong, because the people most likely to be running fifty agent terminals at once are not on a Mac.