model-tieringlisted

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 hav