Nermal
A terminal workbench: persistent sessions, remote work, agents.
Nermal is a terminal you can leave running. Close the window, reboot the machine, walk to a different laptop — the shells you started are still there, and so are the coding agents you left working in them.
It is written in Rust, renders on the GPU through Zed's
gpui, and parses VT with Alacritty's
terminal core. In practice that means roughly twice the throughput of Alacritty,
Ghostty, or Kitty on a big cat, and a frame rate that does not fall over when
something floods the screen.
What makes it different
Sessions that outlive the app
A background server owns your shells, not the window. Quit Nermaland your builds keep building. No tmux to learn or configure.
Editor-grade input
Ghost suggestions from your history, tab completion that explains each flag, syntax highlighting, click-to-place-caret, real multi-line editing.
Agent-aware
22 coding CLIs are recognised on sight. Per-pane status dots, notifications when one needs you, git context, and session resume after a reboot.
Remote work that feels local
A native Rust SSH stack with profiles, SFTP, and port forwarding — plus remote workspaces where files, repos, and panes all stay on the far machine.
Git where you are looking
Branch and diff counts on every sidebar row, a source control panel, a diff overlay, and worktrees in one dialog.
Scriptable
A bundled Nermal CLI that opens panes, sends keys, reads screens, and blocks
until an agent needs you — so scripts and agents can drive the workbench.
Start here
Install it
Native builds for macOS, Windows, and Linux. Installation →
Set it up
Five minutes of settings that pay for themselves. First launch →
Learn the three words
Workspace, tab, pane — and the server underneath them. Core concepts →
How fast, exactly
Same machine, same day, same 155×40 grid — Apple M1 Pro, macOS 26.3.1, five-run averages.
| Nermal | Alacritty | Ghostty | Kitty | |
|---|---|---|---|---|
Plaintext I/O — 11 MB cat (lower is better) | 95 ms | 239 ms | 179 ms | 185 ms |
| DOOM-fire frame rate (higher is better) | 888 fps | 485 fps | 552 fps | 617 fps |
| Cold-launch memory | 116 MB 1 | 105 MB | 128 MB | 130 MB |
The methodology and a one-command reproduction live in
scripts/bench/.
Three decisions account for most of it:
- The PTY is read at device speed and parsed in large batches, off the render path — so drawing never throttles reading.
- The hot paths are lock-free. A big
catnever waits on the renderer. - The server buffers up to 16 MiB ahead of the window before backpressure applies, which is enough that a flood finishes writing while the window is still catching up.