The Terminal Was Always a Log

On July 29th, Mitchell Hashimoto posted four words that were enough to send a developer tool to the top of Hacker News: I started a new company. By the end of the day the thread had climbed past 700 points and 400 comments. For a terminal multiplexer, that's not normal. That's viral.

If the name doesn't place him: Hashimoto co-founded HashiCorp and built Terraform, Vault, Vagrant, and the rest of the tools that quietly run most of the industry's cloud infrastructure. More recently he built Ghostty, a terminal emulator fast and modern enough that he handed it to a nonprofit foundation just so it would stay open source forever, no matter what happens to him or any company he starts. That's not a small gesture. People don't do that for software they think is a toy.

His new company is called Superlogical. Its first product is a terminal multiplexer, the kind of program tmux has owned for the better part of two decades. And the Hacker News thread split cleanly down the middle. Half the comments were excited about a genuinely fast, modern multiplexer. The other half asked the obvious question: tmux is free, tmux works, tmux is everywhere. Why does this need to be a company?

The day after the announcement, Hashimoto posted a ten minute video walking through the architecture. About a month later, a demo. Buried in that demo was one sentence that explains almost everything: the server, he said, maintains N replica distributed terminal state machines, all talking over a custom binary protocol.

That sentence is either meaningless jargon or the whole point, depending on whether you know what a terminal actually is under the hood. Most of us don't, because we've never had to. So before getting anywhere near Superlogical, we need to go all the way back to the metal: what happens, mechanically, when you press a key.

What actually happens when you press a key

Open a terminal and type a single letter. Something appears on screen almost instantly, so it's easy to assume the emulator just draws what you type. It doesn't. Three separate programs are involved, and none of them can see the other two directly.

The terminal emulator is the application with the window, whether that's Ghostty, iTerm2, Kitty, Alacritty, Warp, or the stock macOS terminal. Its only job is drawing: it owns a grid of character cells and paints glyphs into them. The shell, usually bash, zsh, or fish, is the program that actually reads your command line and decides what to run. And sitting between those two, invisible unless you go looking for it, is the PTY: the pseudo terminal.

A PTY is a pair of connected endpoints supplied by the kernel: a two way pipe that behaves like a physical terminal from 1978. That date isn't a joke. Terminals used to be hardware: a keyboard and a screen wired to a shared computer down the hall. The hardware is long gone, but the software contract it spoke never went away, because too much still depends on it. So the kernel keeps a fake serial device around so every program written against that decades old contract keeps working without modification. That fake device is the PTY.

Watch a full round trip once and the rest of this gets easier. You press L. The emulator doesn't draw anything yet. It writes one byte, the one associated with the letter L, into its end of the PTY. The kernel carries it down the pipe. The shell reads it off the other end, decides you need to see it, and writes that same byte straight back into the pipe. It travels back up, the emulator reads it, and only now does an L appear in the grid as a glyph. Press enter after typing ls, and the same round trip happens for whatever the command prints: the shell runs it, the output travels back up the pipe as bytes, and the emulator paints each line, scrolling automatically once the bottom fills.

So far: one side writes bytes, the other side echoes them back, and that's the entire relationship. Nothing else connects these two programs. Which raises an obvious question, because plenty of terminal output is in color, or moves the cursor, or clears the screen. None of that is text. How does it travel down a pipe that only carries bytes?

One language for everything

It travels down the exact same pipe, because there's nowhere else for it to go. Say a program wants to print the word error in red. It can't reach into the emulator's window directly. All it has is the pipe. So it prints a special sequence of bytes right before the word: the escape byte (value 27), followed by a handful of characters meaning switch to red. Then it prints the word. Then, because it turned red on, it has to turn it back off, the way an HTML tag needs a closing tag.

These are called escape sequences, and they are the entire control language of the terminal, sent through the same stream as the data. That's worth sitting with, because it's not how most protocols work. HTTP separates headers from body: one channel for instructions, one for data. A terminal has no such separation. There's no metadata layer. Every instruction, every byte of actual text, travels through one undifferentiated stream.

So how does the emulator make sense of a stream where plain text and control instructions are interleaved with zero warning? With a state machine: a program whose reaction to the next byte depends entirely on which state the previous bytes left it in. The byte 109 is just a lowercase m in one state, and "apply the pending style" in another. There's a well known diagram of exactly this machine, reverse engineered from real DEC VT terminals by Paul Flo Williams, and something close to it is implemented in essentially every serious terminal emulator shipping today. Ground state, escape state, parameter state, and onward. It is not, notably, a regular expression, and the Ghostty project has written at length about how many implementations get that distinction wrong.

Which gives us a real definition of terminal state: the full grid of cells (what character and color each one holds), where the cursor sits, which styles are active, which modes are on, plus the scrollback: the lines that have already rolled off the top. That's genuinely all of it. And it's smaller than you'd guess.

Real emulators land far below that, since most cells are blank and most lines share styling. But the shape of the number matters more than its precision: a terminal's entire state, cursor, colors, scrollback and all, is a rounding error next to almost anything else on your machine. Keep that number in your head. It's about to explain why replicating that state to multiple clients at once is a reasonable thing to attempt.

Determinism, proven

Here's the property everything downstream depends on: feed the same bytes, in the same order, into the same state machine, and you get the same state, every time. No randomness anywhere in the pipeline. Which means the byte stream itself is a recording. Play it back later into a fresh renderer and you get the exact same screen. The byte stream is the program; the emulator is just the machine that runs it.

That's easy to state and worth actually watching happen. Record a small deploy log, colors and all, to a file of raw bytes. Replay that same file into two completely separate terminals at once, feeding it a few bytes at a time so you can watch it build.

Same file, two independent terminals, zero coordination between them. Every cell matches, because the machine that drew them is deterministic and got identical input.

Now cut roughly forty bytes out of the middle of that same recording and replay it again. The reasonable guess is that a chunk of the output goes missing, maybe a line drops out, and the rest is fine.

That's not what happens. The whole screen goes wrong: colors bleed across lines, text lands in the wrong cells, the cursor ends up somewhere nonsensical. Not damaged in one spot. Damaged everywhere, from the cut point onward. That's the state machine being exactly what it claims to be: every phase after the missing bytes takes whatever state the previous phase left it in and keeps building on top of it. Move one byte, and everything downstream is wrong.

Hold onto both halves of that experiment. A deterministic machine that reconstructs identical state from identical input, and a machine that produces total garbage from any gap in that input. Those two facts, together, are the entire engineering bet Superlogical is making.

Why tmux exists, and what it actually is

None of this explains multiplexers yet, so back up to the actual original problem. You SSH into a remote server, kick off something long: a migration, a build, a log tail. Your laptop sleeps, or the wifi drops, and the kernel tears down the login session on the spot. The job dies with it. Two hours of waiting, gone, because the connection that was carrying your terminal's byte stream no longer exists.

GNU Screen solved this in 1987. tmux became the standard replacement starting in 2007. The idea in both cases: instead of your connection talking straight to the shell, a server process sits in the middle and owns the shell's PTY. Your connection now talks to that server, not the shell. When the connection dies, the server, the PTY, and the running job are all still there. Reconnect, and you attach to the same server and pick up where you left off.

tmux itself is a client-server program: the tmux command you run is a thin client, and the first time you run it, it quietly starts a server in the background. Every command after that is just a client talking to that already-running server, over a Unix socket local to the machine. That's a detail worth underlining, because tmux never speaks a network protocol at all. Over SSH, the SSH connection carries the bytes across the network, and only once they land locally do the tmux client and server talk to each other over their socket. The multiplexer itself never crosses the wire. Remember that; it's exactly the piece Superlogical moves.

Since tmux is open source, you can go look at what it does with every byte your program prints. There's a roughly 3,600 line file, input.c, that is the same kind of parser state machine described above, written in C, running inside the tmux server. Everything printed inside a pane gets parsed there, into a grid tmux keeps in its own memory, one grid per pane. Scrollback lives in grid.c, in the same server.

Here's the part that matters: your actual terminal, Ghostty or Kitty or whatever you run, can never see that grid. It only speaks bytes. So tmux does the only thing it can: it looks at the grid it built, generates a fresh stream of escape sequences describing it, and sends that to your terminal. That's the job of tty.c. Your terminal parses that stream with its own state machine, into its own grid, and only then do you see anything.

Add up the work: your program prints once, but its output gets parsed by two independent state machines into two independent grids, with an entirely new byte stream invented in between. The same doubling happens on input: your keystroke reaches the server, the server works out which pane you're in, then writes it into that pane's PTY. In 2007 this was a fair trade, built for one person on a laptop SSHing into one box. It's still the design in 2026, and for typing or ordinary output you will never feel it. You feel it specifically under high throughput, a program dumping a large build log, where every byte pays for both parses, and no amount of GPU acceleration on the terminal side changes that, because the terminal was never the bottleneck. The multiplexer in the middle is.

That's not a metaphor, either. Capture exactly what a program writes into tmux's pane, and separately capture what tmux sends onward to the attached terminal for that same moment, and they don't match. The outgoing stream carries cursor repositioning tmux invented, its own repaint of the region, status bar updates woven in. Your terminal never receives your program's output. It receives tmux's description of its own grid, after your program's output was folded into it. And it isn't unique to tmux: zellij, a modern Rust multiplexer, has its own roughly 6,200 line grid implementation doing the same job, for the same architectural reason.

Where that architecture leaks

The double parsing costs CPU, which mostly doesn't matter. The real cost is ownership. Because there is exactly one grid, living in exactly one server, three specific things end up shared that most people never asked to share.

Two people attached to the same session is a genuinely good collaboration feature, right up until one of you scrolls back to read an error. Then both screens scroll, because the scrollback lives in the server's one grid, and there is only one scroll position to have. Geometry breaks the same way: a tmux window has one size, in cells, and if a teammate attaches from a smaller terminal, tmux can't give you a full screen and them a small one. There's one grid. The window shrinks to whoever's smallest, and the rest of your screen fills with tmux's well known field of dots. And features break the same way again: your terminal might fully support something like the Kitty graphics protocol, letting a program render an actual image inline. Inside tmux, that image never appears, not because your terminal can't draw it, but because your program isn't talking to your terminal. It's talking to tmux's built-in emulator, and if the middleman doesn't understand image data, it's just noise to it. There's an opt-in escape hatch to let image bytes pass through untouched, off by default, which tells you how confident anyone is in it.

The job changed underneath the tool

Here's what's actually different about 2026, and it has nothing to do with speed. Picture the pre-agent workflow: run a few commands, close the terminal, done. Compare that to starting a coding agent on a real task, say migrating a frontend from Next.js to TanStack across a few hundred files, then walking away. You check from your phone an hour later to see if it's stuck on a question. You check again before bed, and by then it's finished and asking you to review the diff. The next morning a teammate asks what changed. That session is now the record. It has to be durable, and more than one person, on more than one device, needs to be able to look at it.

The same week Superlogical launched, Peter Pistorius wrote a piece asking why a whole wave of new terminal multiplexers had shown up at once: not just Superlogical, but zmx, cmux, Herdr, and WezTerm's own built-in multiplexer. His answer: traditional multiplexers assume a person is sitting at the keyboard, actively driving. That assumption is gone. Agents work independently for hours, and once they're done, multiple people need to look at the same work. His framing, which the rest of this piece basically confirms from the wire up: the server should own the session, and the client should own the view.

Session means the PTY, the process's lifetime, the output history, the identity of the work itself. View means how you're currently looking at it: the layout, the scroll position. In tmux and zellij those two things are the same object, owned by the same server. That's the fusion this whole new generation of tools is trying to undo.

This split creates two problems tmux never had to think about. First, when a person and an agent, or two people, share a session, something has to decide whose keystroke lands first: an input ordering point tmux's single-user design never needed. Second, once agents are touching production systems unattended for hours, teams increasingly want an audit log of exactly what happened in that session, which is only possible once the session is a durable, first-class thing rather than an artifact of someone's terminal being open.

One more nuance keeps the new architectures honest: a PTY has exactly one size. If a session started at 120 columns runs a full-screen program like btop, and your phone connects at 50 columns, there's no way to redraw those already-computed drawing instructions at the smaller width. That computation has to happen somewhere, and it can only happen where the state lives. So geometry, the actual rows and columns inside the PTY, stays server-side even here. What moves to the client is layout: how sessions get arranged on your screen. Client owns the view, not the math underneath it.

Superlogical, claim by claim

With all of that as background, here's what the actual demo showed, claim by claim.

So was Hacker News arguing about the right thing?

Half right, mostly by accident. The skeptics are correct that nobody strictly needs a new multiplexer to do what tmux already does well: keep one person's session alive on one machine across a dropped connection. tmux is free, it's everywhere, and for that job it isn't broken. But that was never really the bet. The bet is that a terminal session's identity, not its rendering, becomes the durable unit that a human and an agent, or several humans, work around together, checked from a laptop, a phone, and a teammate's machine, at different times, without any of them stepping on each other's scroll position. That only becomes buildable once the session stops being welded to any one person's view of it, and welding those two together is precisely what tmux's 2007 architecture, quite reasonably for 2007, did.

It's also worth staying a little skeptical, on purpose. Hashimoto's own roadmap has three stages: build the multiplexer, make it composable, make it safe to run in production. This entire piece has been about stage one, the part that's actually shipped anything to look at. Stages two and three are where a fast idea either turns into infrastructure teams trust with production access, or doesn't. A team with this pedigree, Jack Pearkes was HashiCorp's first employee, and the design side has shipped work at Vercel, Heroku, and Poolside, has earned the benefit of the doubt on stage one. Stages two and three still have to happen in public.

That last row is the honest caveat, and it's a real one: tmux's biggest advantage, working with absolutely any terminal you already have, is exactly what Superlogical trades away for everything above it in that table. Whether that trade is worth it depends entirely on whether you believe the thing being described in this piece: that your terminal was a deterministic log the entire time, and multiplexers before now just never took that fact seriously enough to build around it.

Notable Capital and Amplify Partners led the funding, with a angel list that includes Guillermo Rauch, Patrick Collison, Tobias Lütke, and Armon Dadgar, which is not the list of people you'd expect to back a hobby project. Whether that conviction is warranted is still, genuinely, an open question. What isn't open to argument is the mechanism. Give a terminal the same bytes in the same order and it will draw the same screen, every single time. That was always true. Superlogical is just the first company betting a whole product on it.