Running Claude Code, Codex, and Cursor on the same task

Most of the time, one task gets one agent. But some tasks have natural seams: an implementation and its tests, a refactor and the migration that follows it, a backend change and the UI that consumes it. For those, running two agents side by side in the same task is often faster than running one twice.

How it looks in Dispatcher

Every task's workspace can hold more than one agent tab. Open a second tab, pick a different harness, and the two run in a split view inside the same worktree. A typical pairing we use ourselves:

• Claude Code implements the change described in the task.
• Codex writes or updates the tests for it, in parallel.

Both see the same files, because they are in the same worktree. That is the point: the test writer can read the implementation as it lands.

Give each agent a lane

Sharing a worktree means sharing files, so the instructions need to divide the work cleanly. What works for us:

1. Split by file, not by idea. "You own src/settings/*, you own src/settings/__tests__/*" is unambiguous. "You handle the logic, you handle the edge cases" is not.
2. Sequence the shared step. If both agents need a new type, have the first one add it and tell the second to read it rather than create it.
3. Keep one agent as the owner. When both are done, the owner runs the full test suite and fixes whatever the combination broke.

When to use separate tasks instead

If the two pieces of work could merge independently, make them two tasks. Each gets its own worktree, its own branch, and its own pull request, and neither can step on the other. Splitting one task between agents is for work that has to land together.

A rough rule: if you would put it in one pull request, one task with two agents is fine. If you would want two reviews, use two tasks.

Picking the agent

We do not think there is a permanent ranking of coding agents. They change monthly, and the right choice depends on the codebase, the language, and the shape of the task. What we have found is that switching costs are what keep people on one agent out of habit.

Dispatcher's job is to make those costs close to zero. Every supported harness runs the same way: it launches in the task's worktree, its terminal sits next to the diff, and its output goes through the same review. Try a different agent on the next task, compare the diffs, and keep whichever one did better.

Watch the bill

Running two agents on one task roughly doubles the token spend for that task. The Harnesses screen shows what each CLI has used, which makes it easier to decide when the second agent is worth it. For a small bug fix, it usually is not. For a feature with a real test surface, it often is.