Mitchell Hashimoto, creator of Ghostty and co-founder of HashiCorp, revealed on July 30, 2026, the launch of his new company Superlogical along with its first product concept. What they're building is a terminal multiplexer that keeps work as long-lived sessions you can reconnect to from the Web or from native macOS and iOS apps. The goal is to remove display processing from the serial path where tools like tmux interpret terminal output, convert it back into a rendering sequence, and have the local terminal interpret it all over again. That said, the product has only just started taking waitlist signups, and claims of being "fast" are a design expectation, not a measured result.
What's new isn't persistence, but a design that tracks terminal state in parallel
tmux keeps programs running after you disconnect, letting you return to the same session from a different terminal. According to the official documentation, a single tmux server manages the programs and their output, while clients running in outer terminals connect via a socket. Persistent sessions are already a well-established feature.
The burden with traditional multiplexers arises because that middle layer also acts as a terminal emulator. In a 2025 document explaining the design of libghostty, Hashimoto described how tools like tmux and Zellij own the child process's pseudo-terminal (PTY), parse escape sequences to manage screen state, and then output a different set of escape sequences for the outer terminal. The outer Ghostty or Kitty then parses that rendering sequence again to display it. Until the server-side parsing and re-rendering finish, the client side can't move on to the next step.
Superlogical changes this dependency. The server parses the PTY's output as authoritative state while also distributing the same raw byte stream to connected clients. Each client, with libghostty built in, parses and renders that stream on its own. Parsing work is duplicated between server and client, but because the two run in parallel, the local display doesn't have to wait for the server to produce a rendering sequence. The novelty here isn't reduced computation—it's restructuring the latency path.
For this approach to work, you need implementations that reach the same terminal state from the same input. If interpretation diverges on anything from colors and cursor movement to Unicode and image protocols, the client's display will drift from the state the server holds. Superlogical's choice to put libghostty at the core is precisely because it lets the same state machine used in Ghostty be embedded across every environment. It also provides separation: if a client misbehaves, the server-side session isn't corrupted, and only the display side needs to reconnect.
State is sent only right after connecting; after that, raw PTY data flows
A client connecting midway through a session doesn't know the prior terminal state. Per Hashimoto's design explanation, the server temporarily pauses PTY processing upon connection and sends the state needed to begin rendering—the currently displayed content, screen size, cursor position, and so on—in its own binary format. Once the client receives a frame signaling readiness, it can begin handling input, selection, and scrolling, and from then on it keeps following the raw PTY output. If sync is ever lost, this connection procedure starts over.
Nor is this a design where you have to wait for the entire scrollback history before you can interact. Scrollback arrives in the background from newest to oldest, and each client maintains its own scroll position. Even if multiple people have the same session open, one person's scrolling doesn't need to move everyone else's screen. The server orders inputs to keep the PTY-side state unified.
Here, the boundary between the screen snapshot and the continuing byte stream matters a lot. If PTY output gets mixed in during the connection process, the same sequence could end up applied twice or dropped entirely. The reason the server pauses and uses a ready frame as a boundary is precisely to avoid that race. Once implemented, it will need to be verified that this boundary holds up during connections made mid-burst of heavy output, and during recovery from a dropped connection.
Screen splitting is also being moved to the client side. Under the plan, each tab or split pane in the native UI connects individually to a single PTY, and the layout is drawn by the Web or macOS/iOS app. For ordinary terminals that don't understand the protocol, they're also envisioning a compatibility mode where libghostty sits on the server side and returns a conventional rendering sequence as before. Maximizing the performance benefit requires a capable client that implements the same terminal spec.
Web sharing and native UI have precedents
The ability to open a terminal in a browser and share it among multiple people isn't new. Zellij offers a built-in Web client and touts collaboration as a current feature. Comparing long-lived sessions, browser connectivity, and live sharing, Superlogical is arriving as a latecomer to an existing space.
There are also precedents for connecting a native UI to a multiplexer. tmux's Control Mode was built for iTerm2: instead of tmux drawing a normal terminal screen, it exchanges commands and asynchronous notifications through a text-based protocol. iTerm2 uses this to display tmux panes within its own UI.
Where Superlogical diverges is in where the connected terminal's state gets computed. In Control Mode, the tmux server remains the center of everything. Superlogical distributes the same libghostty state machine to both the server and each client, and during normal operation, each one reconstructs the same state from the raw PTY data independently. More than Web support or sharing features, it's this distributed state management that will determine performance and feel.
A client receiving raw PTY output can interpret the control sequences the application originally emitted, rather than a representation converted for an outer terminal. This reduces the number of times terminal features get translated into another format by a middle layer, but it also means the client can't just be a lightweight display renderer. Whether the same behavior can be preserved from Web to mobile, and how compatibility is maintained when different versions of libghostty coexist, are challenges that come bundled with the design's strengths.
Pre-beta concept, speed still awaiting measurement
Underlying the design is libghostty-vt, which handles everything from parsing terminal sequences to managing state for the cursor, character attributes, and line wrapping. It's usable from C and Zig, and supports macOS and Linux as well as Windows and WebAssembly. While the processing used within Ghostty itself is stable, the public API's signatures are still in flux, and it doesn't yet carry an independent version number.
Superlogical's product is even further upstream than that. As of August 1, 2026, all the official site offers is a beta waitlist and a promise of an open-source release at some point during development. There are no benchmarks comparing speed, no formal protocol specification, no pricing, and no release date. The authentication, permission separation, and auditing mechanisms essential for running live sharing in production haven't been announced either, and the licensing for the overall product is also unknown.
The company has laid out a three-stage plan going forward: start with the terminal, make each component composable, connect human interactive work with automation and AI agents, and eventually handle everything—including production operations—within a single long-lived session. But right now, all that can actually be verified is the design of that first terminal layer. The first things to judge will be round-trip latency on real hardware, rendering speed under heavy output, and recovery time when multiple clients lose sync.
Terminal text alone can't represent everything the company envisions as "all work." Superlogical says future sessions will carry structured data, operations, and history, driven by software while still letting humans supervise. We'll only be able to say the terminal multiplexer has advanced to its next layer once its API and production-grade safety measures are made public.