Running Codex as a fleet: parallel tasks, best-of-n

The single-session habit dies hard. Most of us learned agentic coding by babysitting one careful conversation: prompt, watch, correct, repeat. Codex's cloud mode quietly breaks that habit, because tasks are cheap to start and share nothing. Each one spins up its own container, checks out its own copy of the repo, works, and hands back a diff. My terminal instincts (one session, tended like a bonsai) turned out to be wrong. This system rewards launching, not tending.

That inverts the workflow question. Instead of asking how to make one session succeed, you ask how many attempts you can afford to review. That is the fleet mindset, and it comes in two flavors.

Fan-out: different tasks, same afternoon

The obvious pattern first. Pick a handful of small, independent items off the backlog (a flaky test, a deprecation warning, a missing input validation, two documentation gaps) and launch each as its own cloud task. The mechanics of handing work to the cloud are covered in delegating to Codex cloud; the fleet insight is simply that nothing forces you to do it one task at a time. You come back from lunch to five proposed diffs instead of one.

Fan-out lives or dies on task selection:

• Small blast radius. A task that touches three files is reviewable. A task that touches thirty is a project.
• Machine-checkable. If tests or a linter can vouch for the result, your review shrinks to reading intent.
• Disjoint files. Two tasks editing the same module hand you a merge conflict as a bonus prize.

Best-of-n: same task, several tries

The less obvious pattern. Agents are stochastic: give Codex the same gnarly task three times and you get three genuinely different diffs. Different approaches, not just different formatting. For work where the approach matters, run the same prompt as several attempts and keep the strongest. The cloud surface makes this nearly frictionless; you can fake it locally with git worktrees, but container isolation is exactly what makes n attempts painless.

Strongest usually means the smallest diff that passes the tests and matches how the codebase already thinks. One warning from experience: best-of-n is not a vote. When all attempts agree, that is weak evidence you are fine. When they diverge wildly, your prompt was underspecified. Fix the spec, not the sample count.

Parallel agents do not remove the bottleneck. They move it — from the model's attention to yours.

Review is the new bottleneck

Five diffs land at once and you are now the constraint. Generation scales horizontally; judgment does not. This is the central tension of async agent architecture, and its mitigations transfer directly:

• Cap the fleet. Never keep more diffs in flight than you can review the same day. A stale queue is worse than a small one, because the repo moves underneath old diffs.
• Demand green proof. A diff that arrives with tests already run inside its container is a different object than a naked diff. Set up the task environment so the agent can prove itself.
• Judge the approach before the hunks. Read the agent's summary first. If the approach is wrong, reject without reading line one.
• One winner per task. Do not stitch hunks from attempt two into attempt three. Frankenstein merges mean you personally own every seam.

Fleet mode is the strongest argument for Codex's cloud surface over a local session, and it changed what my own day looks like: I write specs and review survivors, and that is most of the job now. Start with fan-out on boring, independent chores until your review pipeline feels trustworthy, then spend best-of-n tokens on the tasks where a second opinion is genuinely worth it. And track one honest metric: the age of your oldest unreviewed diff. The day it crosses twenty-four hours, the fleet is too big. Shrink it, because review discipline, not model quality, is what this workflow actually runs on.