Let's talk a bit about what makes the Superlogical multiplexer different architecturally from traditional terminal multiplexers! There's a lot (a LOT) more coming, but wanted to share a little bit about the terminal-specific part compared to tmux and zellij.

Short recap (I hope you don't mind) The problem. Traditional multiplexers (tmux, Zellij, screen) sit between your terminal emulator and the pty, causing double parsing and duplicated state processing. Their terminal-emulation layer is also slow compared to modern terminals like Ghostty, Kitty, or Alacritty — sometimes 100x+ — so putting one in front makes a fast terminal feel slow. Difference 1 — distributed synchronized state machines. They're going all in on libghostty. When a client attaches, the server pauses pty processing and sends a custom bit-by-bit binary protocol carrying just enough screen state (visible content, dimensions, cursor, mouse) to render immediately, then a "ready frame" — at which point you can already type, select, and scroll. Then, instead of sending screen diffs like tmux does, the server tees raw pty bytes to every client, ssh-style, assuming each client runs a compliant, fast emulator. So the client is essentially an ssh client with no middle-man parsing; a slow server can't slow down client rendering. Input is serialized back to the authoritative side — one writer, many readers. A misbehaving client only corrupts its own view; the server stays correct. Scrollback streams in the background, newest to oldest, so you briefly see a loading state. Each client owns its own viewport, fixing tmux's annoyance where one person scrolling scrolls everyone. Out-of-sync clients just restart the handshake. The cost: every client must be smart and compliant — which is exactly what libghostty (no dependencies, lightweight, runs everywhere) is for. Difference 2 — native splits. tmux draws splits inside one terminal screen and needs a terminal to display at all. Superlogical ships native apps — browser, mobile, multiple OSes — where each split is a native tab/window/split with its own protocol connection, one-to-one with a pty. You can also attach a single stream by ID from an ordinary terminal like Kitty; for terminals that don't speak the protocol there's a compatibility mode that puts a libghostty terminal in the middle — same tradeoff as existing multiplexers, but on a faster, more compatible core. Whether to support in-window multiplexing in that legacy mode is undecided. Difference 3 — feature velocity. Responding to Kovid Goyal's criticism that tmux/screen adopt new features slowly (forcing clever workarounds for things like the Kitty graphics protocol): Mitchell concedes the structural point stands — terminal features are whatever libghostty supports server-side — but argues libghostty is more feature-rich, faster to adopt, and open to bleeding-edge features so long as the embedder can toggle them. He closes by noting this covers only the terminal side; more of the project comes later.

Thank you, I would've written something but I was lazy!

Damn I had the same idea a just few days ago after messing with PAM and libghostty :D will this be open source? I'll use it happily, I assume it will replace ssh too? I'd be amazing to get rid of ssh and do quic, and use PAM properly to establish sessions etc for proper native integration.

Is your current stance with libghostty where you encourage people to build their own emulators and the official app is more of a reference implementation stay the same for Superlogical multiplexer?

Yes

Awesome, excited to see the first demo

Technically iterm2 allows native windows via the somewhat horrible tmux -CC text protocol. The fact that tmux syncs the view of all clients can be used to some advantage too, e.g., for co-debugging big LLM training runs, Twitch streaming style. I did that often with coworkers.

I'm painfully aware: We solve the synced view problem as well, its just an opt-in choice, and works by sending additional frames of the synced viewports (but otherwise works like how I described).

Oh I know you know. Your design sounds much saner than -CC mode too!

WezTerm's done this for ages. It's a sound idea, but it's not novel, and you don't need to wait for the new thing to be built to try it today.

Based on some comments, I think it's important to remind ourselves how true this is

Extra hyped to hear that Kovid Goyal (creator of Kitty and Calibre) is part of the conversation. Dude is one of GOATs, and also the most prominent critics of Tmux and similar multiplexers. That his input is being taken seriously here makes me super bullish on SuperLogical.

Delaying the scrollback is pretty smart from a terminal emulator perspective, but I don't get why you need a custom binary protocol over VT100 to send the raw pty data back: you're starting from the premise that the multiplexing client is a terminal emulator but it doesn't have to be. Why not render directly the different ptys on a native window(s), using native APIs? I guess I'm missing the long term product strategy and how the adoption of this protocol fits into it.

Because are on a mix of machines, local and remote. For local, we avoid the network overhead but its still IPC. Also, terminals aren't the only thing we support... just where we're starting...

I see. If it was just remote vs local on a known client, a separate protocol for remote (what we do in would suffice, but since you want remote/local and arbitrary third/party client implementations, you need adoption of the binary protocol so there's no "superlogical client", only server. Smart. If we wanted to add this to Rune, is there a spec anywhere?

for those who prefer reading: It's really awesome to see how excited people are about the multiplexer we're building at Superlogical. I know there's a lot of questions and I promise we're going to give a lot of answers as we get closer and closer to product launches. And we have a lot of exciting devlogs and open source drops and other things planned, but to just sort of start stuff off very casually. Just recording in my home office, I want to talk about a little bit architecturally of why the terminal multiplexer. Part of our vision is architecturally different to a traditional multiplexer. So traditionally the way a multiplexer works, we'll just use TMUX as an example, but this applies to pretty much all of the major ones out there is that you have your terminal emulator and then your terminal emulator runs the multiplexer and then the multiplexer runs the final pty, which is your shell, which has connected directly to your shell or editor or whatever it is. And this introduces some overhead because without the multiplexer it would just be your terminal directly talking to the pty. And so you end up getting double parsing, double state processing, just duplicated work. And historically, just factually speaking, here, tmux, Zellij screen, these types of multiplexers, their terminal emulator like IO part is fairly slow compared to a modern terminal like Ghosty or Kitty or even Alacrity that are, that are sometimes 100 plus times faster. And so when you put something in front of it, you're just, you're sort of like getting that slow experience in a fast terminal, which sucks. So let's talk about the first thing that we're doing differently at Superlogical. So I obviously am one of the creators of Lib Ghosty and we are just really sort of unapologetically going all in on LibgoSD. And one of the ways we're doing that is that the way our terminal multiplexer works is when a client connects to the server libgo. See, the server part that actually is connected to the PTY pauses processing at that moment when a client is connecting of the current PTY bytes. Everything I'm about to describe here happens imperceptibly fast. But what we do is we pause what's happening and then we send down a binary protocol, a custom hand designed, bit by bit binary protocol down to the client that's connecting, which if it's Lib Ghosty just built in, could process this. If it's not lib ghosty, it's still, it's a binary protocol. Anyone could parse, but we send out a binary protocol. The binary protocol is constructed in a way that we send down just enough terminal state, screen state, you know, what's currently visible on the screen, dimensions, mouse, cursor state, things like that. We send out just enough so that the client could start rendering, could start showing you a terminal as quickly as possible. We defer for later things like scrollback history that's going to come in the background later. So we send down just enough that the terminal is visible. At that point we send a frame type called a ready frame. When the client reaches the ready frame, they're able to immediately show the terminal and the user could start doing selection, could start typing on their keyboard, could start scrolling, all that sort of stuff. And then the core sort of server part unpauses, starts processing PTY bytes. But instead of sending down, this is a big difference. Instead of sending down screen diffs, screen tmux, zellage, all these things, what they do is they keep track of the screen and they send down a diff of what's changing on the screen. Instead of that, we take the pty bytes and we tee them off to all the clients and we send them raw like ssh to all the clients. And we assume that everybody is running a compliant performant, correct terminal emulator. Basically we assume you're running Lib ghosty everywhere. Again, it doesn't have to be, but we just assume that. And so what you end up getting is that your terminal multiplexer client that's attached to it is basically like an SSH client. It's connected directly to the PTY stream. There is no internal parsing. If the server actually starts parsing slower, the client is still parsing at full speed, it doesn't matter. And then when we get events such as keyboard entry on the client side, you do have to send that over to the authoritative central side and we serialize all the input. So there's still sort of one writer, there's multiple readers, and we just assume we have this sort of distributed system of synchronized finite state machines and these terminal emulators. If one of the terminal emulators starts processing incorrectly, you're just going to see the wrong data on the client side. But the authoritative side doesn't depend on any of that. And so the central server is still always going to be correct and up to date. And then all the while this is happening, we are streaming in the background. While we're still processing bytes, we are streaming the scroll back into it. So kind of what you see is when you first load in, say you have a full 10,000 line scroll back or something, you could scroll and you're just going to see blank with sort of a loading state, like it's just not there yet. Like I said, all this happens pretty fast. So you're not going to. Unless you're on a very slow Internet connection, you're not really going to see that, but you're going to see a loading state. And we sort of send the history back, newest to oldest. So the most recent scrollback is there just chunk by chunk. And so you get full native scrollback. Everybody is allowed to do their own text selection, their own viewport. Like sort of famously, infamously, in tmux, if you have multiple clients attached to the same TMUX session, when one of them scrolls, it scrolls everybody's window. Very annoying. So you're going to actually be able to scroll on your own because the client fully owns the viewport state. And yeah, that's sort of the idea of it. If a client is ever sort of out of sync for any reason, it could just restart this process. You know, start from the beginning, reset the terminal frames. But that's sort of the core architectural difference. It gets rid of the performance overhead of a traditional terminal multiplexer. It gets rid of the sort of man in the middle style effect of a traditional multiplexer. But it does require that every connecting client be a very smart, high functioning, compliant client. And the key to that is Libgosi runs everywhere, has no dependencies, it's lightweight, it's fast. That's the answer to that. Another thing that is sometimes brought up is that it's the way multiplexers work, like TMUX and screens on is they handle splits themselves. They split the screen up like one terminal screen. If you're in again Kitty or Ghosty, they split that screen up themselves. And so the terminal emulator might support native windows, might support native tabs, but it's not able to represent that. This is also something that the way we're addressing is that one we have native applications. And so TMUX requires a terminal emulator to view its content. Ours will not. We're going to be shipping native applications, they're going to work in the browser, they're going to work on mobile, they're going to work on a variety of operating systems. And we represent each split using native tabs, native windows, native splits, and each one has its own connection to this binary protocol that I mentioned. And so they're sort of their own standalone systems, one to one to a pty. You're not going to get the multiplexing within a window like you normally do. We're still sort of discussing whether we'll have a legacy mode just for other terminal emulators to support that. Not certain yet. But we will also have the ability in any terminal that you will be able to connect to one stream. So if you're in Kitty and you want to connect to the super logical multiplexer and you want to connect to one terminal, you could specify it by ID and we will sort of render it directly into that terminal. Obviously, you know, Kitty, something like Kitty today doesn't understand our binary protocol, may never understand our binary protocol. I don't know. In those cases we will have a compatibility mode that does what traditional multiplexers do, which is we put a Libgosi terminal in the middle and that's the same trade off as other multiplexers. So we're not any worse there. I would say we're much better because Libgosd is a much more performant compatible core, but architecturally it's going to be identical there. If you're in this legacy mode, but if you use our native clients or if your client understands the this binary protocol, which is predominantly part of Libgosi, so an open protocol, then you will not have this overhead. And another point Covid particularly brings up is that it's hard to design new features. Things like TMUX and Screen and so on are somewhat slow. I can't really quantify that because it really varies. But in general they're relatively slow at adopting new features like things like TMUX support, Kitty graphics protocol, Kitty image protocol. So Covid had to go to great lengths in order to create very clever workarounds for that. And I think, you know that's going to be true here, right? Like the. The features of the terminal are going to be the features of the Libgosi support in the server. However, Libgosi is much more feature rich. We're much faster at adopting new terminal features and we are much more open to adopting bleeding edge terminal features as long as they can sort of be turned on and off by the embedder. That's sort of the stance we take. And so philosophically, generally this feedback is still valid, the critical feedback here is still valid, but I think in practice we've shown so far that we're quite innovative and quite fast at integrating these new features. So those are just three things I think there were three. Three things I want to talk about. The big one just being the huge architectural difference of the synchron distributed state machines of terminal emulators. That's going to be the thing that really makes a big difference for how this multiplexer works. But again, this is only the terminal side of it. There's a lot more interesting parts to this that we will get into as time goes on. See ya.

how much have you kicked the tires on wezterm’s multiplexer? do you know anything about its architecture? i’ve been pretty happy with it. i like ghostty’s native ui but hard to leave wezterm’s lua config/scripting for ghostty and applescript. lua editing in nvim so much nicer than applescript

Good to hear some real technology talks. So many larpers know just enough to fool the average person

Very promising approach IMO. I got confused by the order in which ideas were presented (“how can the server send raw PTY if it needs to render split windows?”), so here’s a diagram which might help people.

cant wait to see what you all will build

"...basically we assume you're running libghostty everywhere..." dumb question but why not just merge the multiplexer into the terminal emulator as one thing? I spawn a ghostty window and it loads as a multiplexer window kinda deal? integrated emulator + multiplexer?

great video and great communication so far, really looking forward to it working well on poor internet connections!

Love seeing performance first architecture! Looking forward for the open source drops!

Seems very similar to zmx which I already use heavily (libghostty based too) but I'm 100% sure your implementation would be much better. Just wanted to highlight this.

Question is why is a billionaire interested this much in terminal multiplexers

Cause it’s fun

This is way over my head for now but I’m rooting for you guys to succeed because I love Ghostty and the work you have done!!

This is the way! Really good ideas here.

reasonable and elegant, I can probably imagine amazing usecases with agents and a window into what they upto but now everyone involved gets a window. Also sharing singular panes with no input access might become popular... this could be new web 😂

It’s crazy that it took 2026 for this to be bothered with - nice one

always happy to see someone look at tmux's architecture and decide there's a better way to model it. the unix philosophy of "one process does everything forever" has been carrying that codebase for a while.

If during a client attach, we send the visible screen content, doesn't that mean we had to parse all vt100 escapes server-side as well? How would the server otherwise know what the screen looks like? Then we're still double parsing, right? Just wondering.

Yes, the server parses too. But the teeing happens ahead of the server, so the clients can parse simultaneously to the servers (also if anyone is slow there’s some queues).

The nerd in me loves this tech. Can't wait to ditch tmux in my remote SSH sessions I'm very curious how a terminal multiplexer is going to make money as a business. Have some thoughts, but looking forward to whatever that product ends up being

The overhead of raw terminal streams for LLM agents is massive. If your multiplexer can handle structured data streams or compressed buffer state directly instead of standard pipe output, that changes the cost curve for agents entirely.

Agentic coding scales, software work is fragmenting aX machines, sandboxes, CI, and production handled by a shifting mix of humans and AI agents with no shared session tying it together. a gap $12.8B-and-growing AI coding market and a scramble of point tools trying to patch it

Game engine but literally

Please elaborate on difference from @herdrdev Like, I'm sorry, everything you mentioned IS THERE What's the competitive advantage, why should I switch?

absolutely AMAZING reminded me of very excited to see what the team ships!!

did I come close with ??!!

There's no way an LLM is going to replace this guy

Oh wow. You are building a browser for servers. A replacement for ssh + terminals. Terminals are stipid slow, stuck in 80s.

👌