kolu — the terminal, done right
Many agents.
Many machines.
One terminal.
Not a chat-UI wrapper.
Not an editor fork.
The IDE was built for typing — and your agents don't type.
Real terminals on an infinite canvas — and the canvas isn't stuck on one box. Point kolu at another machine over ssh and the whole workspace moves there: your shells run on it, you browse and diff its files, and closing the laptop doesn't kill any of it. claude, codex, opencode, grok — anything you run in a shell runs in kolu, on any machine you can reach.
docs
Start in the guide.
The durable setup and workflow material now lives in the docs, where it has sidebar navigation, search, code copy, and next-page flow.
the system
Three programs. One set per machine.
Kolu is what you use. Padi remembers the workspace on a host. Kaval owns the shells there. That split is why the tab, web server, and PTYs can fail or restart on different clocks — and why adding a remote machine isn't a special case. It gets its own padi and kaval, provisioned with Nix over ssh: the same stack, one floor down.
See the architecture The@kolu/surface framework underneath kolubrowser workspacethe canvas, dock, code browser, PWA shell — real xterm.js tiles, and everything you look at.
padiworkspace daemonthe per-host memory: sessions, terminal records, restore, git and agent awareness.
kavalPTY daemonthe shell owner: live PTYs, screen snapshots, input, attach, and raw terminal survival.
from the blog
all posts →Making nix develop 30x faster with zero flake inputs
Each flake input costs ~1.5s of fetcher-cache verification on every invocation. Removing all of them took nix develop from 3.6s to 0.12s — and made our builds independent of GitHub's API by accident.
read →