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 today, and whatever headroom you actually have — that is the roster, and it changes. Assign every role the strongest tier that 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 section below: one line 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.
• Default to the strongest tier your headroom sustains. "Cheap hands" is a pressure response, not a religion. Once dispatch discipline has cut your fleet frequency down, most roles can sit at the top tier at your actual cadence — you are buying fewer errors and fewer retries, which beats paying twice for the same work. What to do when the usage lines get loud is its own question, below.
• 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.

The meters are instruments, not judges

If your plan exposes usage meters — per tier, per period, however your provider slices it — read them at every dispatch, and read them as instruments. They tell you what happened. They do not get to decide who is allowed to think.

• While you have headroom, never downgrade a role to flatten a line. One tier running ahead of the others is a diagnosis to chase, not a verdict to obey: is the main session grinding through work it should have dispatched? are the fleets fatter than the job? are the batches oversized? Fix the cause. Demoting the build or the review to even out a chart treats the chart and leaves the cause running. A meter that makes you downgrade the thinking is not saving money; it is pre-paying for rework. On a real project the biggest line in the bill is work that had to be done twice — not a fleet that ran at full strength once.
• Pick your own high-water mark, and when a line crosses it, tell the person paying — once. Choose that fraction in advance; what counts as "getting close" depends on your plan, your month and your appetite, and there is no universal number. Crossing it is not your cue to quietly downshift. It is your cue to say it plainly: this line is at the mark, here is the current pace, here is what is left, and here is what buying more headroom would take if the plan offers it. Slow down, carry on, or pay for overage is the human's call, and they should get it while there is still room to make it.
• If the ceiling is genuinely close, climb down in this order. Shrink fan-out first. Then lower the frequency of optional passes. Then cut batch sizes. Tier is the last thing you touch — and even then, planning, final review and the deciding vote never come down. A thin budget is exactly when you cannot afford a bad plan or a missed defect.
• When you hit the wall, fall back and say so in the same breath. Real rate limits or exhausted quota: cut the fan-out (halving is a reasonable reflex), retry, and report it. Grinding against a hard wall burns the budget and the hour both. A silent fallback is worse than the wall itself — the next plan gets built on a pace that no longer exists.

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. No role was demoted to make a usage chart look tidier, and no limit was reached without the person paying hearing about it first.