Have some fun stuff to share for fellow light mode terminal lovers: we call it Automatic Contrast Correction. Users of light themes will have felt my pain. Developers have generally designed text interfaces for dark mode terminals. There are many examples in the tui apps I use everyday: `lsd`, `btop` (with theme bg off), even my beloved `lazygit` has some suss legibility out the box. The issues are so bad, I generally switch to a dark theme to read stuff. Automatic Contrast Correction fixes this issue by evaluating contrast at runtime between whats being sent from the server to the macOS client versus the theme mode the user is running. Our correction pipeline finds low contrast foreground/background combinations, does some oklab magic, hue rotation towards theme-colors, contrast checking and produces an end result of theme-harmonious, perfectly WCAG-approved legible text. All this happens in nanoseconds and is then cached for performance. It's built right into the @superlogical client. (Screenshots above show ACC off and on)

i think we're all really particular about our terminal environment. we're building the @superlogical clients to have beautiful defaults but also quite a few levels of customisation. this ranges from full liquid glass embrace to totally solid system palettes, through to our 41 custom themes which tint the entire application. we also have two modes of density: our "islands" for terminals (comfortable mode) and a more traditional single pixel border (compact mode).

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.