Model tiering

Tiering exists for two reasons, and thrift is neither: match firepower to the difficulty of the job, and put the author and the verifier on different models. Lower spend is a side effect. Chase it as the goal and you buy rework.

Staff to your own situation, not to a fixed roster. Whatever models you have access to and whatever your usage meters say today — that is the roster, and it changes. Assign every role the strongest tier your current headroom sustains. A rule written months ago cannot know either; you do, at dispatch time.

The split

• Build — top tier. Implementation, refactors, bug fixes, hard-bug diagnosis, merge-conflict resolution, planning, final synthesis. This is what the founder is paying for; do not staff it below the strongest tier your headroom sustains.
• Verify — a different family or tier of comparable strength. Tests, review, acceptance, the deciding vote. Deliberately not the model that built it. Staffing build and verify from two different strong models makes "the author never grades their own paper" true by default configuration rather than by remembering it each time (red-light-first, two-axis-review).
• Support tier. Bulk, secondary, independently checkable work running alongside a main job: batch edits, formatting, translation, per-item comparison against a list, fetching and summarizing.
• Bottom tier. Rarely worth reaching for. Under real headroom, downshifting here is how you pay twice for work that should have been done right once.

Reconnaissance goes to the top tier

The standard advice is to send searching and exploring to the cheapest model you have. We do the opposite: reconnaissance — mapping an unfamiliar codebase, tracing what else depends on a thing, working out the blast radius of a change — gets the strongest tier available. Three reasons.

• Reconnaissance is a judgment call, not a grind. The work is not mechanical searching; it is deciding which files are relevant and which are noise. Anything can return matches. Knowing which handful of them are load-bearing is the entire job.
• Its errors are the best-hidden errors you can make. A miss does not raise an error. Nothing fails, nothing turns red — the report comes back clean and confident, and it is simply short. You find out much later, when a decision built on it breaks, and by then everything downstream was built on the same incomplete picture. Compare a bad line of code, which announces itself.
• So the saving is always smaller than the rework. One tier of price difference, against one missed call site discovered after the whole chain has been built on top of it. This is the principle at the top of this file turned back on a job that looks cheap: firepower matches difficulty, not apparent grubbiness of the task. Scouting looks like grunt work and is actually hard — which is exactly the case the principle exists to catch.

What counts as reconnaissance. The test is whether you already know where the answer lives. "Open that file and read that function" is retrieval — the location is known, nothing is being judged; do it inline if it is a call or two, or hand a batch of them to the support tier. Reconnaissance is the other kind: I don't know where the answer is, and finding it requires deciding what is relevant. Retrieval can go anywhere. Reconnaissance goes to the top.

Rules

• Sub-agents inherit the parent's model unless told otherwise. The parent is usually your most expensive session — always set the model explicitly on every dispatch. Forgetting this once cost us a 20-agent research fleet all running on the flagship.
• The three-call rule. In a long-running expensive session, any chore that will take more than ~3 tool calls (inventory sweeps, batch edits, running test suites, install-and-verify) goes to a cheap agent as one package — even when each call looks tiny. A fat session re-reads its whole history on every turn, so in a long chat there is no such thing as a small chore. (We learned this the same day we wrote the meters rule: the meter drifted anyway, and the leak was "quick" hand-done chores in a day-old session.) Don't trust willpower here — this repo ships a hook that enforces it mechanically: see hooks/. No self-granted exceptions: the only inline acts are conversation, the final artifact's single Write, one verification command, and reading agent results — everything else dispatches.
• The tier is quoted, not just chosen. Whatever you assign here has to appear in the pre-launch quote, one tier per agent, next to the headcount and the budget — see dispatch-economics.
• Dispatch the digging — but not to the bottom. Your main session still reads conclusions rather than raw material; that part does not change. What the digging costs depends on which kind it is: fetching and condensing a source you already named is support-tier work, while deciding which sources matter is reconnaissance and goes to the top (above).
• Escalate the hard case, not the batch. If one item in a cheap batch turns out to be genuinely hard, send that one item up a tier. Don't promote the whole pipeline.
• Spend to the meters, not to habit. "Cheap hands" is a pressure response, not a religion. Once dispatch discipline has cut your fleet frequency down, check the meters: with comfortable headroom at your actual cadence, default every role to the strongest tier that headroom sustains — you are buying fewer errors and fewer retries, which beats paying twice for the same work. Downshift only when the meters actually tighten. The meters set the tier; frugality theater does not.
• Heterogeneity is not optional, so build it into the default. If your standing configuration already puts build and verify on different models, you cannot forget it under deadline pressure. A roster where one model does both is a roster with the verification quietly removed.
• Keep the meters marching together. If your plan shows per-tier usage meters, read them at every dispatch: top-tier meter running ahead → your main session is doing muscle work itself, push drafting and mechanical chores down a tier; aggregate meter running ahead → your fleets are too fat, shrink them and do small jobs inline. No meter should hit 100% while another sits half full.
• Quota pressure shrinks batches, not thinking. Under a tight budget, cut fan-out and skip nice-to-have verification passes — never dumb down the planning or the final judgment.

Success criteria

Every dispatch names its model on purpose. The bill's biggest line is thinking, not grinding. No top-tier tokens went to work that was genuinely mechanical — and nothing sent out to explore came back from a model too weak to judge relevance.