Marcos Paulo
9.6 KiB
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 | split | Ran twice on Codex, zero usable commits both times. This table's own swap rule applied: too big, so it became 15a–15e. |
| 15a guide selector | Codex | Collapsing nine near-identical render functions into one island is the reasoning-heavy part that remains. |
| 15b copy prompt | MiniMax-M3 | Small, mechanical, and has an exact oracle: the clipboard payload must be byte-identical. |
| 15c language toggle | Codex | Needs a design decision written down, not a port — the selector-map approach cannot survive. |
| 15d assemble full guide | Codex | Assembly, but wide: 22 KB of bilingual markup against three islands and task 10's blocks. |
| 15e retire responsive.css | agy |
Screenshot-diff driven — needs vision. |
| 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.