Ratty Terminal Emulator: Inline 3D Graphics for Developers

What “inline 3D graphics” means for a terminal

Terminals have rendered raster images for years. iTerm2 shipped an inline image protocol over a decade ago. The Kitty graphics protocol followed, WezTerm and a handful of others adopted variants, and Sixel — the DEC protocol that dates back to the 1980s — got a second life as Mintty and xterm cleaned up their support. None of those handle 3D geometry. They handle pixel buffers.

A terminal that advertises inline 3D graphics is making a different claim. Either it ships a small OpenGL or WebGPU surface that lives inside the cell grid, or it hands a scene description to a GPU context the emulator owns, or it tunnels frames through one of the existing image protocols at high frequency. The distinction matters because each path has different costs. Pixel streaming is universally compatible but burns bandwidth and CPU on decode. A true embedded GL surface gives you interactive frame rates but locks you to the host process and one rendering backend.

Ratty positions itself in the second camp — a terminal emulator that exposes a 3D primitive to the programs running inside it. The premise is interesting, but the value depends on what the protocol looks like, what the language bindings are, and how the system degrades when you SSH into a remote machine where Ratty is not running.

Where this matters in practice

A few categories of work spend a lot of time forcing 3D into 2D representations.

GPU debugging. RenderDoc, nsight, and Xcode’s frame capture all give you a graphical inspector. None of them sit next to your build output. If you’re iterating on a shader and want to see the geometry of a misbehaving primitive without alt-tabbing, an inline rotatable view in the same terminal where you ran cargo run is genuinely useful.

Scientific computing. Matplotlib and plotly already render to PNGs and SVGs, but they’re flat. Plenty of problems — protein structures, finite element meshes, point clouds from a SLAM pipeline — want a 3D primitive, and today’s loop is “save to file, open in another viewer.” Trimming that loop is the most defensible use case for inline 3D.

ML model inspection. Embedding spaces with tens of thousands of points in PCA-projected 3D are a standard diagnostic. Right now you either open TensorBoard, write a Jupyter cell, or ship a Streamlit app. A print_scatter3d(embeddings) that draws into the terminal is a smaller habit to maintain.

CAD and 3D pipelines. STL or glTF preview at the CLI is occasionally useful for build pipelines that produce assets.

The common thread is short-lived inspection. Nobody is going to do production 3D work inside a terminal cell — the input model, viewport size, and color fidelity make that a non-starter. The pitch is that you can avoid a context switch when you just need to glance.

What to actually check before adopting

The questions worth asking about any graphical terminal entrant, in priority order:

1. Does it degrade gracefully? When you SSH from Ratty into a server running plain bash, the program that wanted to draw a 3D scene needs to do something sensible. The usual answer is to detect the terminal capability via terminfo or an environment variable, and fall back to text. If a tool produces garbage in plain xterm, it will not survive contact with reality.
2. What’s the rendering backend? OpenGL has the widest hardware support but is deprecated on macOS. Metal locks you to Apple. WebGPU is the modern bet, but its ecosystem is younger. Whichever Ratty picks, you inherit those constraints.
3. Is the protocol documented? The reason the Kitty graphics protocol got adoption is that the spec is published, and Neovim, fzf, and others could implement against it. A 3D protocol with one implementation is a single point of failure for any tool built on top.
4. How does it interact with multiplexers? tmux and Zellij famously break image protocols unless explicitly patched. Anyone who lives in tmux should test before committing.
5. What does CI look like? You will eventually want to capture terminal output in a CI log, and an embedded GL surface does not translate well to a plaintext build artifact.

The market context

Ratty arrives in a crowded field, but nobody else owns the 3D corner. WezTerm and Kitty are the technically ambitious modern terminals, both with strong programmability stories. Alacritty is fast but deliberately minimal — it has rejected image protocols for years on architectural grounds. Ghostty opted into the Kitty graphics protocol but no 3D extension. iTerm2 remains the macOS default for many developers and added an image protocol early.

A new entrant has to answer “why not just extend Kitty?” The honest version is that Kitty’s maintainer is opinionated about feature scope, and a 3D primitive is the kind of thing he might reject. Forking the ecosystem to ship the feature is a defensible choice if you believe the 3D-in-terminal premise is worth a clean break.

The risk is the same one every terminal emulator faces — terminal choice is sticky, configuration is personal, and most developers will not switch unless the gain is large and the friction is small. Inline 3D needs a killer demo to clear that bar.

Should you switch?

Probably not as your daily driver yet. Watch the project. See if the protocol gets a published spec. See if a second implementation appears. See if tmux and mosh learn to pass it through. If those things happen, the category becomes interesting. If they don’t, Ratty stays a clever demo.

The cheap experiment is to keep your existing terminal and run Ratty in a window when you’re doing the specific work it’s good at — shader iteration, point-cloud inspection, mesh preview. That’s a low-commitment way to find out whether the inline 3D premise actually saves you context switches, or whether it’s a feature you thought you wanted until you had it.