kolu
Site

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.

Why a terminal and not an editor

The dock finds what you cannot see: two agents in two repos, and one buried behind another tile asking for you.

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
  1. kolubrowser workspacethe canvas, dock, code browser, PWA shell — real xterm.js tiles, and everything you look at.
  2. padiworkspace daemonthe per-host memory: sessions, terminal records, restore, git and agent awareness.
  3. 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 →