Marcos Paulo
79 lines
9.6 KiB
Markdown
79 lines
9.6 KiB
Markdown
# 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.
|