Race the same prompt across four checkouts

You are about to start a non-trivial task and you catch yourself deliberating: Opus or Sonnet? Plan mode first, or just describe the end state? Phrase it as a refactor or as a rewrite? That deliberation is a guess about an outcome you could simply observe. Racing costs tokens; guessing costs a whole session.

The move is to stop treating model and phrasing as settings you reason about and start treating them as an experiment you run: same prompt, several isolated checkouts, different model in each, read all the diffs, keep one, throw the rest away.

Why the checkouts have to be separate

Two Claude sessions editing one working copy interleave their edits and you cannot tell whose diff you are reading. Isolation is what turns "I ran it twice" into "I have two comparable results."

The docs give you three ways to get that isolation, all with a per-session model:

The agent view path is the closest thing to a documented one-liner for this: it explicitly lets you change the dispatch model between prompts, and every background session isolates its own edits.

A race you can run from one file

Write it to a file with a bash shebang and run it with bash — a for loop pasted into zsh will not word-split the model list the way you expect.

#!/usr/bin/env bash
# race.sh - one prompt, three models, three worktrees
set -euo pipefail

PROMPT_FILE="${1:?usage: bash race.sh path/to/prompt.md}"
PROMPT="$(cat "$PROMPT_FILE")"

for m in opus sonnet haiku; do
  claude -p --worktree "race-$m" --model "$m" "$PROMPT" \
    > "race-$m.log" 2>&1 &
done
wait

for m in opus sonnet haiku; do
  echo "===== $m ====="
  git -C ".claude/worktrees/race-$m" diff --stat
done

Then read the three diffs, cherry-pick or merge the branch you like, and remove the others. Nothing cleans these up for you: a -p run has no exit prompt, so the worktree, its branch, and the lock Claude Code took on it all stay until you run git worktree remove (and git worktree unlock first if git refuses).

The part that decides whether this works

The race only pays off if you can rank the outputs. Ranking means holding an opinion about the shape the code should have taken, not just whether the tests pass. On a module you designed, that judgement is instant. On a codebase you are new to, four passing diffs are four things you cannot choose between, and you will pick the shortest one for the wrong reason.

Give yourself a tiebreaker before you look: the smallest diff that touches the fewest files and adds no new abstraction wins, and the tests must pass in that worktree, not just in one of them.

Two habits that travel with it

Scope each lane tightly. State the end goal and the shape — which file, which existing pattern to follow, what not to touch. Racing four unconstrained prompts gives you four different architectures to compare, which is a harder problem than the one you started with. The docs' own guidance on specific prompts covers this ground; the racing is what is new.

Queue the follow-up work while you review. Kick a cleanup lane off in a worktree while you QA the previous fix. Reviewing and generating are genuinely two jobs, and one person cannot do both in the same minute — that is the whole argument for parallel sessions.

What is unverified here

Be clear about which half of this is grounded:

• Grounded: the mechanics. Isolated worktrees, per-session models, background dispatch on a different model each time, and running parallel sessions for isolated experiments are all documented Claude Code behaviour.
• Not grounded: the practice itself. No official page suggests racing one prompt across models and keeping a winner. It comes from one practitioner interview, and it is a workflow report, not a measurement.
• Weakest claim of all: the assertion that agents are near-perfect at refactoring and much weaker at new functionality. Nothing in the docs says this, no benchmark is cited, and it is the kind of claim that goes stale with the next model release. Treat it as a prior to test, not a rule.

What would settle it: run the same prompt through the script above on a task you know well, three times over a week, and keep a tally of which lane you actually merged. If one model wins six times out of nine, you have learned something about your codebase. If the winner is random, you have learned that the race was not worth its cost — which is also worth knowing, and cheaper to find out than to argue about.