Mitchell Hashimoto rebuilds tmux in the server, aiming to kill multiplexer latency

Mitchell Hashimoto, the HashiCorp cofounder who helped make “infrastructure as code” feel mainstream, is now taking aim at a much older piece of the stack: the terminal multiplexer. Through his new startup, Superlogical, he is building a server-side terminal multiplexer meant to let programmers bounce between multiple persistent work sessions without the lag and state chaos that come with today’s tools.

In Hashimoto’s own framing, today’s multiplexers are too slow because they duplicate everything the user types and then constantly reconcile local and remote state. The result is friction even when you swap in modern terminals. He explicitly calls out that even pairing a multiplexer with fast terminal emulators like Kitty, Alacritty, or Ghostty “won’t do much to speed ops.” The bet is that speed and reliability should come not from a faster UI on the client, but from changing where “session state” lives.

This matters because multiplexers are the common denominator across how developers work, and increasingly, how agents and tooling work. Tools like tmux, Zellij, and GNU Screen have become default glue for handling long-running terminal work: multiple panes, reconnections, and the ability to move between tasks without losing context. Hashimoto’s critique is that the multiplexer layer has become a bottleneck. It doesn’t just manage windows. It mirrors typed input and attempts to keep multiple views consistent, which forces constant back-and-forth between what the user thinks is happening and what the server has actually processed.

Superlogical’s approach tries to eliminate that duplication at the architecture level. The core idea is surprisingly simple and practical: the client sends terminal input to the server, similar to an SSH session, while the server maintains the persistent session state. Users can then disconnect and return later, with the client focused on rendering and scrolling locally rather than waiting for a network round trip for everything the terminal needs to show. In other words, the “memory” of the work sits with the server, and the “pixels” sit with the client.

Hashimoto also ties the new product directly to technology he already worked on at HashiCorp. Superlogical’s terminal multiplexer is built on a project called Ghostty, a modern terminal emulator he began developing while still at HashiCorp. The source describes Ghostty as GPU-driven and adopted for both “lightning-fast performance” and a feature set that other emulators rarely have in tandem. Just as important, Hashimoto extracted the core Ghostty engine into a software library called libghostty, so others can build on it.

That is the enabling detail for why the Superlogical architecture is feasible: Hashimoto says it requires that every connecting client be a “very smart, high-functioning, compliant client,” such as one built on libghostty. He does not give more detail about Superlogical’s product plans beyond the concept, but the technical implication is clear. The client has to be capable of doing more than just passing bytes and drawing characters. It needs to manage rendering and scrolling in a way that fits the server as the source of truth for persistent state.

This is also where “durable” agentic layers enter the conversation. Hashimoto’s thesis is that today’s computer architecture is missing a fundamental primitive: a stateful session for the work itself. If work spans machines and users, then tasks need their own space for context, data, and history. Traditional terminal multiplexers try to paper over that by keeping session context in a way that is still tightly coupled to a streaming, interactive text experience. But if you move the authoritative session state server-side, you are closer to a model where tools and agents can keep making progress even when the human, the UI, or the network disappears temporarily.

There is no direct regulatory story in the source, but there is a governance and operational one that executives should notice. A stateful, server-side session model changes where workloads “live,” which in turn changes accountability, auditing, and how you think about access control for development and automation. The source also notes that Hashimoto did not divulge much about Superlogical’s plans, which means the next questions are likely to be strategic rather than purely technical: how standardized this becomes, whether teams can integrate it into existing developer workflows, and how safely organizations can run it across varied environments.

Finally, the story has an obvious signal for the AI and infrastructure crowd: terminals are where developers, agents, tools, and infrastructure still meet. If Hashimoto is right that the terminal is the common denominator, then speeding up session persistence and eliminating client/server duplication could become the unglamorous but critical layer that future “agentic” systems require. Even Gergely Orosz, author of the Pragmatic Engineer Substack, speculated on X that Superlogical could be building an AI-native “agentic operating system” that sits above OSes. Whether or not that’s the endgame, the near-term stakes are that the boring workflow layer could become the fastest path to durable computation for humans and agents alike.