Where Wortel sits
Four kinds of tool have grown up around running coding agents, and they are not really competing for the same job. This is the map, with Wortel on it.
If you run one agent at a time, a terminal is a terminal and you should use whichever you like. The moment there are four, three questions start to matter: which one is waiting on you, whether they are editing the same files, and what happens to them when you close the lid.
The manager apps answered the second one first, by giving each agent its own git worktree, and built review tools around that. The multiplexers answered the third, by owning the shells in a background server so the client can go away. The agent terminals answered the first, with rings and badges and notification panels. Wortel is the one that is a real terminal and answers all three.
Wortel
A terminal, with the review tools in it
Native, on Ghostty’s engine
Terminal emulators
A terminal, and nothing else
Ghostty, iTerm2, Kitty, Alacritty
Pick one if you run a single agent and want a terminal, nothing more. Ghostty is excellent, and Wortel runs its engine.
Agent terminals
A terminal arranged for agents
cmux, Warp
Pick one if tab layout and notifications are the problem you actually have, and you want your own Ghostty config respected.
Agent manager apps
An app that runs agents for you
Conductor, Emdash, Superset
Pick one if you want a task board, a review queue and a pull request at the end, and you do not mind the terminal being a panel inside it.
Multiplexers and runtimes
A server your terminal attaches to
tmux, Zellij, herdr
Pick one if the work has to outlive the machine you are sitting at, and you are happy driving it from a terminal you bring yourself.
Compare, app by app
Pick any two, or more if your screen has room. Every answer was read off that product’s own site, docs or repository.
Native terminal on Ghostty
Terminal emulator
Terminal emulator
Terminal with an agent in it
Agent terminal on Ghostty
Agent manager
Agent manager
Agent manager
Agent runtime
Terminal multiplexer
Native terminal on Ghostty
Terminal emulator
Terminal emulator
Terminal with an agent in it
Agent terminal on Ghostty
Agent manager
Agent manager
Agent manager
Agent runtime
Terminal multiplexer
Native terminal on Ghostty
Terminal emulator
Terminal emulator
Terminal with an agent in it
Agent terminal on Ghostty
Agent manager
Agent manager
Agent manager
Agent runtime
Terminal multiplexer
Native terminal on Ghostty
Terminal emulator
Terminal emulator
Terminal with an agent in it
Agent terminal on Ghostty
Agent manager
Agent manager
Agent manager
Agent runtime
Terminal multiplexer
What kind of tool it is
The category each one belongs to, before any feature is counted, and whether the shell is the product or a panel inside it.
A terminal, with the review tools in it
what it is
A terminal emulator
what it is
A terminal emulator
what it is
A terminal with an agent built in
what it is
A terminal arranged for agents
what it is
An app that runs agents for you
what it is
An app that runs agents for you
what it is
An app that runs agents, with a terminal in it
what it is
A server your terminal attaches to
what it is
A multiplexer inside your terminal
what it is
Ghostty’s engine, unmodified
a real terminal
The whole point
a real terminal
The whole point
a real terminal
A Rust, GPU rendered client
a real terminal
Ghostty’s engine too
a real terminal
One per task, inside the app
a real terminal
It runs CLI agents, in the app
a real terminal
Built in, with tabs and splits
a real terminal
Inside the terminal you supply
a real terminal
Inside the terminal you supply
a real terminal
Swift, AppKit, SwiftUI, Metal
fully native macOS
Swift and AppKit on macOS
fully native macOS
Objective-C and AppKit
fully native macOS
Rust and GPU, drawn rather than AppKit
fully native macOS
Swift and AppKit
fully native macOS
A Mac app; the stack is not published
fully native macOS
Cross-platform desktop app
fully native macOS
Electron
fully native macOS
A terminal user interface
fully native macOS
A terminal user interface
fully native macOS
Several agents at once
What happens when there are four of them: whether they edit the same files, which one is waiting on you, and what survives you quitting.
Shells run under a keeper process
survives quitting
The shell is a child of the app
survives quitting
The shell is a child of the app
survives quitting
The shell is a child of the app
survives quitting
The shell is a child of the app
survives quitting
Not published
survives quitting
Not published
survives quitting
Sessions survive a restart; processes not stated
survives quitting
The server owns the shells
survives quitting
The server owns the shells
survives quitting
A session opens on a branch
a worktree per agent
You run git yourself
a worktree per agent
You run git yourself
a worktree per agent
You run git yourself
a worktree per agent
You run git yourself
a worktree per agent
A workspace and a branch per task
a worktree per agent
Its core idea
a worktree per agent
Its core idea
a worktree per agent
Pairs with a tool that does
a worktree per agent
You run git yourself
a worktree per agent
Read off the terminal stream
knows who is waiting
A bell, at best
knows who is waiting
A bell, at best
knows who is waiting
Agent notifications, on by default
knows who is waiting
Rings, badges, a notification panel
knows who is waiting
Not published
knows who is waiting
Not published
knows who is waiting
Indicators, chimes and a Dock badge
knows who is waiting
Working, blocked or idle, per pane
knows who is waiting
Nothing reads the pane
knows who is waiting
Nothing is installed into any agent
touches no agent config
Nothing to install
touches no agent config
Nothing to install
touches no agent config
Codex needs a line in its own config
touches no agent config
Writes hooks into each agent
touches no agent config
Not published
touches no agent config
Detects the CLIs you have installed
touches no agent config
Not published
touches no agent config
Prefers hooks, works without them
touches no agent config
Nothing to install
touches no agent config
Reviewing and driving them
What it takes to see what an agent did, to let it act on the app itself, and to keep the whole thing running.
Changes, History, Files and previews
diffs in the window
Another app
diffs in the window
Another app
diffs in the window
Another app
diffs in the window
Branch and PR status, not diffs
diffs in the window
Review the diff, open a PR, merge
diffs in the window
Diffs, pull requests and CI checks
diffs in the window
Inspect, comment on and edit the changes
diffs in the window
No window to put it in
diffs in the window
No window to put it in
diffs in the window
A bundled wortel command, over a socket
agents can drive it
Some CLI actions, no session API
agents can drive it
A Python API and AppleScript
agents can drive it
Agent APIs; session control not published
agents can drive it
A CLI and a socket API
agents can drive it
A Conductor API
agents can drive it
Not published
agents can drive it
A superset binary and a TypeScript SDK
agents can drive it
The CLI is the API
agents can drive it
send-keys, and a full command set
agents can drive it
None. One read-only file in the bundle
nothing to configure
A config file, often a large one
nothing to configure
A large settings window
nothing to configure
Settings, themes and agent profiles
nothing to configure
Reads your Ghostty config
nothing to configure
Not published
nothing to configure
Detects your CLIs; providers to set up
nothing to configure
An optional .superset/config.json
nothing to configure
Config, plugins and keybinds
nothing to configure
A .tmux.conf
nothing to configure
These tools ship weekly and this page does not, so check anything that decides it for you. Where a product does not publish an answer the cell says "not published" rather than guessing: that is not a polite way of saying no. Corrections are welcome, and anything wrong here is a mistake rather than a position.