I build DataNexus with several coding agents running at once. Claude Code fixes router logic while Codex fills in test coverage.

The workspace was the problem. With one checkout and multiple terminals, agents step on each other’s files. One reinstalls dependencies while another’s build breaks mid-run. I juggled stashes for a while, then gave up and ran them one at a time. Agents I added for parallelism were running serially.

Splitting the workspace with git worktree

Branch switching shares a single directory across branches. git worktree does the opposite: one repository, a separate directory per branch.

repo (datanexus)
 └─ base ref: origin/main
     ├─ worktree: fix-nl2sql-timeout    ← branch + directory + terminal
     ├─ worktree: semantic-layer-v2
     └─ worktree: rbac-audit

One task, one worktree, one agent. Agent A can tear through node_modules without touching agent B’s build. Isolation comes first; parallelism only works after that.

Orca turns this structure into a desktop app

You can manage worktrees by hand, but once tasks pile up, tracking which agent runs in which directory becomes its own chore. Orca is an open-source desktop app that takes over that bookkeeping. Stably, a YC-backed team, built it and released it under the MIT license . It runs on macOS, Windows, and Linux, and the GitHub repo had passed 16,000 stars when I wrote this.

One task = one git worktree = one agent terminal = one browser tab

That equation is Orca’s unit of work. Add a repo and the default branch becomes the base ref. Name a task and Orca creates a real git worktree and checks out the branch. You can always cd into the directory and use plain git, so the tool never locks you in.

Installation on macOS is one line:

brew install --cask stablyai/orca/orca

On first launch it offers to import ~/.claude and ~/.codex. Subscription auth carries over, so my existing Claude Code setup came up without re-login. Presets cover more than 25 agents, from Claude Code and Codex to Cursor CLI, and you can register any custom CLI.

The race: three different models on one task

The official recipe is a race. Create three worktrees for the same task, assign Claude Code, Codex, and Cursor CLI, and paste the same prompt into all three. Watch them side by side in split panels, pick the best result, and delete the losing worktrees along with their branches.

I was skeptical at first because I had dropped this pattern in post 9 . Generating three SQL candidates from the same model produced identical results 92% of the time, and the selector never overturned the first candidate. More candidates meant nothing without diversity.

The race starts from a different premise. The models themselves differ, so the approaches actually diverge. Give them the same refactoring task and one extracts an interface while another reshapes the inheritance tree. That is post 9’s lesson seen from the other side: multi-candidate lives or dies on candidate diversity, not candidate count, and model heterogeneity is the most reliable source of that diversity.

It does burn three times the tokens. For fixes with one obvious path it is waste, so I reserve it for problems where the design could go several ways. Losing worktrees disappear with one click, branch and all, which keeps the cost of trying low.

Diff review becomes the next prompt

The deciding evidence is the diff. Orca lets you drop markdown comments on any diff line, batch them, and send them back to the agent. Comments like “early return here” or “this test misses an edge case” become the next iteration’s prompt as-is.

Post 11 argued that AI answers need their evidence on screen. The same principle applies to development: a human makes the merge call, no matter which agent wrote the code. Commit, push, PR review, and CI checks all happen inside the app, and Linear or Jira issues open directly as worktrees.

The features that stuck

Each worktree gets its own Chromium window. In Design Mode, clicking a UI element sends its HTML, CSS, and a cropped screenshot straight into the agent prompt. Explaining a visual bug in words used to take longer than the fix; now it is one click. Heavy jobs can move to a remote machine over SSH worktrees, and per-worktree checkpoints give you a way back when an agent goes off the rails.

There is also an orchestration feature where a top-level agent delegates work to agents in child worktrees. It is still experimental: you enable it under Settings > Experimental, and it ships as the orca orchestration CLI plus an agent skill.

Code stays local. Nothing goes to Stably’s servers, and you can turn telemetry off in settings.

What I am still figuring out

Deciding which tasks deserve a race is still gut feel. It takes judgment to spot problems where designs will genuinely diverge. A few weeks of use should give me adoption rates by task type, and I will revisit this with token costs alongside those numbers.