Orbit / Running multiple AI coding agents

Running multiple AI coding agents at once

Running one coding agent is a solved problem. Running six is a coordination problem, and the tools that solve it fall into five groups that are easy to confuse. This is the map, written by someone who builds one of them.

First, the part you can do with no tools at all

The mechanism underneath every product here is git worktree. It gives one repository several working directories, each on its own branch, sharing one object store. Two agents in two worktrees cannot corrupt each other's index, which is the failure that makes naive parallelism useless.

git worktree add ../work/feature-a -b feature-a
git worktree add ../work/feature-b -b feature-b
# start an agent in each directory, in its own terminal
git worktree list

For three or four agents this genuinely works, and plenty of people never need more. The problems appear at scale rather than at the start: each worktree needs its own dependency install, dev servers collide on ports, and you end up with a screen of terminals where you cannot tell which agent is working and which has been waiting on a question for ten minutes.

The five groups

1. Terminal multiplexers for agents

Thin wrappers over tmux and worktrees, usually free and open source, always keyboard-first. Claude Squad, workmux and dmux are the ones people name. Good if you already live in the terminal and want the smallest possible layer. The ceiling is that a pane is not a status: you still have to look at each one to know what is happening.

2. Desktop orchestrators

Native or Electron apps that create a worktree per task, run an agent in it, and give you a diff viewer. Conductor is the best known and is macOS only. Emdash, Pane, Nimbalyst, Mux and Orbit are cross-platform to varying degrees. Sculptor takes the same idea but runs agents in containers rather than bare worktrees, which is a stronger isolation story if you are nervous about what an agent can reach.

This is the crowded group. The useful questions when comparing them are which platforms they build for, how many agent CLIs they support, whether anything checks the work before it reaches you, and what happens when two agents finish at the same time.

3. Boards

Kanban framing on top of the same machinery: cards move from todo to in progress to review, and each card is an agent. Vibe Kanban made this popular. Boards read well when you are planning and read badly when you are triaging, because a board shows you everything at equal weight and triage is about ranking.

4. Cloud and async agents

The agent runs on someone else's machine and comes back with a pull request. Different shape entirely: no local worktrees, no terminals, and you trade control for not having your laptop pinned. Worth using alongside a local tool rather than instead of one.

5. What the vendors ship themselves

This is the group that changed most recently. Claude Code now creates worktrees natively, and the Claude Code desktop app runs several sessions with a diff viewer. If you use one vendor and want three or four agents, the first-party tools may be all you need, and they cost nothing extra on a subscription you already pay for.

The case for a separate tool starts where the vendor's stops: running agents from different vendors side by side on the same repository, applying your own checks before work counts as done, and having one queue across everything rather than one per vendor.

Choosing

Where Orbit sits

Orbit is a desktop orchestrator, and on the mechanics it does what the others in that group do: a worktree per task, ten agent CLIs, diffs, terminals, port previews, macOS and Windows.

The part that is different is what happens when an agent stops. Orbit runs the lint, typecheck and test commands you configured for that repository before anything is marked ready for review, so an agent claiming success does not become your problem later. Separately, it reads each agent's rendered terminal screen to notice when one is blocked on a question, and puts that at the top of a single ranked queue with the question attached. Merges run through one lane per repository, so two finishing agents cannot race, and your working checkout is never touched.

Honest limits: it is closed source, the builds are not code-signed yet, agents run in worktrees rather than containers so isolation is process-level rather than sandboxed, and the phone control is a paid feature and a PWA rather than a native app. If any of those is disqualifying, one of the tools above is a better fit and that is fine.

Keep reading

Conductor alternative for Windows · Getting notified when an agent is stuck