# Which model runs which task

You have **MiniMax-M3** (primary), **Gemini**, and **Codex**. They are not
interchangeable here, and the split is not about which is "smartest" — it is
about which failure mode each task punishes.

**Honest caveat up front:** I have not benchmarked these three on this
repository. The routing below is reasoned from task shape and each model's
known strengths. Validate it cheaply on **task 07** (small, self-contained,
easy to judge) before fanning out across ten worktrees.

## Short answer

**Run the refactor on MiniMax-M3.** It is your primary, the work is mostly
bounded mechanical migration with a hard verification gate, and that is exactly
the shape M3 handles well at low cost. Reach for the other two at three specific
points where M3 is the wrong tool.

## Routing table

| Task | Model | Why this one |
| --- | --- | --- |
| 01 scaffold + gates | **Codex** | Config-heavy, many interacting tools (Astro + husky + lint-staged + CI), and success is binary — it builds and hooks fire, or not. Codex's long autonomous run-until-green loop suits it, and getting the foundation wrong is expensive later. |
| 02 design tokens | **Gemini** | Needs the whole CSS corpus in one context (8 stylesheets, ~90 KB) plus **visual judgement on screenshots**. Gemini's long context and multimodal comparison are the differentiator; the others would work file-by-file and miss cross-file drift. |
| 03 verification net | **Codex** | Writing test tooling with a tight feedback loop. Precision about what an assertion pins matters more than speed. |
| 04 content schema | **MiniMax-M3** | Small, well-specified, one file. |
| 05–06 content migration | **MiniMax-M3** | High-volume mechanical string moves with a `diff` as the oracle. Cheap, parallel, verifiable. Exactly M3's sweet spot. |
| 07 primitives | **MiniMax-M3** | Small components from templates. Use this task to calibrate the whole routing decision. |
| 08–11 component blocks | **MiniMax-M3 ×4 parallel** | Four bounded tasks, one template each, checklist-gated. Cost per task matters because there are many. |
| 12–14, 17 pages | **MiniMax-M3** | Bounded, snapshot-diff verified. |
| 15 full guide | **Codex** | The hard one: 50 KB `app.js`, 12 render functions, tab state, bilingual swap. Long sustained reasoning over interacting pieces; the task most likely to need many iterations against a failing check. |
| 16 review desk | **Codex** | Same shape and worse — search, filtering, file fetching, six query params, markdown rendering, client-side diff. Highest defect risk in the plan. |
| 18 motion | **Gemini** | Judging whether motion looks right is perceptual. Feed it before/after captures. |
| 19 contract re-point | **Codex** | 42 assertions to translate without losing coverage. Meticulous, mechanical, verifiable. |
| 20 cutover | **you, with M3 assisting** | Touches production publishing. A human should be watching. |
| review of every task | **Gemini** | Fresh eyes, whole-diff-in-context, and it did not write the code. Never review with the model that wrote it. |

## The reasoning in one line each

- **MiniMax-M3** — cheapest per task and strong at bounded, tool-driven edits.
  Use it for volume: 13 of the 20 tasks. Its weakness is long multi-file
  reasoning where the spec is vague; every task above that it owns has a
  template and a mechanical oracle.
- **Codex** — best at "keep iterating until the check passes" over a
  complicated existing codebase. Use it where the loop is long and the answer is
  not obvious: scaffold, the two hard pages, verification.
- **Gemini** — biggest context and genuinely useful multimodal comparison. Use
  it where the input is *everything at once* or where the judgement is
  **visual**: token consolidation, motion, screenshot diffing, and code review.

## Cross-checking rule

Whatever writes a task must not review it. Pair them: M3 writes → Gemini
reviews; Codex writes → Gemini reviews; Gemini writes → Codex reviews. The
`reviewer` agent definition is model-agnostic on purpose.

## Swap the routing if you see this

| Symptom | Move the task to |
| --- | --- |
| M3 spends more than ~3 iterations failing the same gate | Codex |
| M3 edits files outside its task scope | Codex, and tighten the brief |
| Codex "fixes" a red suite by deleting assertions | anything — but re-read `context/verification.md` to it first; `gate.sh` blocks the merge either way |
| Gemini gives confident visual sign-off with no screenshots attached | require the artifacts; do not accept prose |
| A task needs more than two models' worth of hand-holding | the task is too big — split it |

## Cost shape

Tasks 05–14 are ~two-thirds of the work and are all M3-eligible. Running those
on Codex would work and cost several times more for no measurable quality gain,
because the checklist and `gate.sh` — not the model — are what guarantee those
outputs. Spend the expensive models where there is no mechanical oracle: 15, 16,
and the visual judgement calls.