Superlogical Server Memory Optimizations Overview

Superlogical, a new terminal multiplexer, claims to use significantly less memory than tmux or Zellij at scale, particularly with busy terminals and clients driven by AI session spawning. The project's analysis shows tmux excels in empty states, while Zellij's per-client memory usage is unscalable due to its wasm-plugin architecture. Superlogical aims to optimize for high terminal and client counts, benefiting both AI agents and human users.

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.