Cate gives each coding agent its own git worktree on an infinite canvas

What a Cate terminal reports while an agent works

Most people run a coding agent one at a time: a terminal, a prompt, a wait. Cate is aimed at the case where five are going at once, each on its own branch. Start Claude Code, Codex or another agent CLI inside a Cate terminal and that panel stops being plain scrollback. Supported agent CLIs report turn start, turn end and permission prompts, so each panel can show running, waiting or finished, and Cate notifies you the moment a terminal needs an answer. That notification is the whole reason the canvas exists. With several agents in flight the usual failure is not a crash, it is a session that sat on a yes or no prompt for twenty minutes while you looked somewhere else. The editor layer underneath is stock: a Monaco editor, a file tree, a browser panel, viewers for PDF, image and DOCX files, nested canvases, and Cmd+K for commands, panels and files, with shortcuts rebindable in Settings.

One worktree per agent, drawn as its own territory

Branching is the other half. Rather than asking you to run git worktree add by hand, the README says you type what you are working on and Cate creates the worktree and the branch, starting from a local branch, a remote branch, or an open PR. The result appears on the canvas as a colored piece of territory, which is the actual argument for the spatial layout: five agents on five branches stay five visibly separate workstreams instead of a pile of tabs. Git sits next to it, with multi-repo source control, badges in the file tree, side-by-side diffs and ripgrep search, so you can read what an agent produced without leaving the canvas. The honest reading of the mechanism is that Cate automates an invocation you could type yourself. The branching model is still git's, which is a good property. It also means a worktree that gets into a messy state is your mess to clean with git, not something the canvas will resolve for you.

Only the six agents the panel knows report their state

The set of agents is named, and it is finite. T3 Code, the integrated chat panel, runs Codex, Claude Code, Cursor, Grok, OpenCode and Antigravity with streaming output, tool calls and approvals, and those same CLIs are the ones whose terminals report turn start, turn end and permission prompts. The marketing line about any agent CLI therefore needs reading carefully. A CLI outside that set can still be typed into a Cate terminal, but nothing in the documentation promises the running, waiting or finished badge will light up for it, and the notification path is exactly what you are buying. The set is not a loose claim either: package.json defines an npm script named test:agent-contracts that runs vitest with CATE_LIVE_AGENT_CLIS=1 against a live config, so the contracts are exercised against the real CLIs in CI style. If your agent is not on the list, find out first whether it emits the events Cate listens for, because everything else in the workspace still works while that status stays blank.

The cate CLI is the seam your agents can call

There is a second interface inside the app, and it is the more unusual design decision. Run in a Cate terminal, the cate command drives a browser panel, reads another terminal, opens files and manages panels. That means an agent can be handed a way to inspect and reshape the workspace around it, and you can reorganise panels from a prompt rather than by dragging. It is also the thinnest part of the documentation. Those capabilities get one sentence and no subcommand, no flag and no code example, and the README does not point at a reference page for them. If you intend to script panel management or let an agent open files through this CLI, read the help output of the shipped binary before assuming a stable surface, and expect the CLI to change shape as the app moves. The rest of the project's own workflow lives in CONTRIBUTING.md, which covers building rather than using the command.

Editors stay local while the shell runs on SSH or WSL

Remote work takes the same code path as local work, which is the choice most likely to surprise someone arriving from a remote-first editor. Point Cate at a host over SSH or over WSL and terminals, git, search and the agents run on that host, while editors, the browser panel and the canvas stay on your machine. Nothing in the README describes a synchronisation protocol between the two sides, so keep the boundary in mind: the pixels and the editing surface are local, the processes are not. That has a practical consequence when a remote agent writes a file, since what you see in the local editor is whatever the host and the panel agree to hand over. The path does have a live test behind it rather than being a claim. package.json defines test:ssh:loopback, which sets CATE_LOCAL_SSH_E2E=1 and runs vitest against a separate config with the sshLoopback target, so the loopback case is exercised deliberately.

Install path: prebuilt builds, and a pinned Node 22 for source

Installing is deliberately not a build project. The README opens the install section by saying to download a prebuilt release and not to build from source for daily use. The release table lists DMG and ZIP for macOS on arm64 and x64, an NSIS installer and a ZIP for Windows on x64, and AppImage, DEB and tar.gz for Linux on x64, all from the latest release page. On macOS there is one documented command:

brew install --cask cate

That cask is the supported macOS route alongside the manual downloads. If you do want a source build, package.json pins the toolchain precisely. The engines field requires node >=22.16 <23, so a machine on Node 24 is outside the supported range rather than merely untested. The setup script runs:

bun install && bun run runtime:tarball

and the build script is:

electron-vite build

The remainder of that workflow is in CONTRIBUTING.md. Note that source builds also assume bun is present, which the README never mentions, since it only documents prebuilt installs.

No config file, and a Sentry script the README ignores

Two documentation gaps matter before adoption. The first is the promise that opening a folder makes a workspace with no config files at all. That is convenient until you need to change a default, because there is no documented settings file to read and nothing in the project says where per-machine preferences would live. Layout persistence is scoped to per-project, and the rest is reached through Cmd+K and rebindable shortcuts in Settings, so the project is betting on a single folder and a fixed surface. The second gap is error reporting. package.json defines a script named sentry:test that runs node scripts/sentry-test.mjs, so a Sentry path exists inside the app, and the README says nothing about what it sends or where. Read that before you point it at client work. On licensing, Cate is MIT with the LICENSE file at the repository root, which leaves commercial use and modification unencumbered, and electron-builder.yml is where the packaging targets are declared. Maintenance is not the worry: the last push was on 2026-09-19, and v2.0.0, v2.0.1 and v2.0.2 shipped on 2026-09-13, 2026-09-14 and 2026-09-16.

Where this sits against a terminal and an integrated editor

Compare it with the two setups you already have. A plain terminal, or a multiplexer, gives you the agents and nothing around them: no status badge, no notification, and no way for an agent to open a file through a panel API. An editor with a built-in terminal gives you a file tree, language services and one familiar window, but one workspace, one working tree, and a tab list that does not encode which branch an agent owns. Cate sits between those two and trades the editor's density for spatial arrangement. The cost is an Electron application that bundles Monaco, viewers and a canvas renderer, with a source tree carrying e2e/, research/, registry/, skills/ and plan.md directories. That is a heavier thing to maintain than an extension, and it is a heavier thing to review. The unit of work is different either way: in Cate, one branch, one worktree, one agent, one colored region you can point at.

Editorial conclusion

Adopt Cate if you regularly run more than one coding agent against the same repository and already think in git worktrees. Stay on a plain terminal, or a multiplexer, if you run one agent at a time, because the canvas buys you nothing there. Verify two things before switching: that your agent CLI is one of the six the panel knows about, and that the absence of a config file is what you actually want, since the README states none exists. The last push was on 2026-09-19 and the licence is MIT, so trying it and backing out costs little.

Frequently asked questions

Official sources

1. 0-AI-UG/cate on GitHub
2. License: MIT
3. Project website
4. README
5. Releases