mattstackmodel-tieringlisted

# Model Tiering Use the least capable model that can succeed at each unit of work. An omitted model flag inherits the parent's model -- usually the most expensive one -- which silently defeats tiering. ## The tier table | Work shape | Model tier | Why | |------------|-----------|-----| | **Mechanical execution** -- fully specified, 1-3 files, existing pattern to follow, zero design decisions | Sonnet | Brief/plan contains everything. No triage or judgment needed. | | **Design / triage** -- multiple valid approaches, vague criteria, cross-layer, product decisions, brainstorming | Opus | Agent must assess, brainstorm, make design calls. It delegates mechanical subtasks to cheaper sub-agents. | | **Integration** -- merge branches, run verification, report | Sonnet | Mechanical by nature: merge, run tests, report. | | **Review** -- disposable artifact or diff reviewer | Sonnet | Read-only, throwaway context. | ## Complexity signals Use these to place a unit of work in the table above: - **File count and isolation.** 1-3 files with a clear spec = mechanical. Multi-file with integration concerns = design tier. - **Spec completeness.** Brief contains the exact code or precise instructions = mechanical. Brief describes intent and constraints = design tier. - **Decision load.** Zero design decisions left = mechanical. Any product, architecture, or pattern decision = design tier. - **Existing pattern.** Adding a field along an existing pattern, renaming, copy tweak = mechanical.