What you’ll be able to do
- Match model tier to task profile in both directions
- Recognise over-serving as a failure equal to under-serving
- Plan for breaking behaviour changes across model releases
- Justify a tier choice from the properties of the workload
What you need to know
The tier spectrum
Sonnet is the default you move away from with a reason. Moving down needs the task to be bounded and repetitive; moving up needs the reasoning depth to be the thing you're actually paying for.
Profiling a workload before choosing
Three properties decide it, and the scenario always supplies them:
- Volume — thousands of near-identical items, or a handful of hard ones?
- Boundedness — is the task well-specified with a narrow answer space, or open and ambiguous?
- Stakes — what does a wrong answer cost here?
A clinician-facing assistant reasoning through an ambiguous presentation in live chat: low volume, open-ended, high stakes, someone waiting. Opus, real-time, extended thinking. Both are correct answers to the same question asked about different workloads.
Over-serving is a real failure
Candidates internalise "don't under-serve a hard task with a small model" and then miss the mirror image. Routing every task — trivial and complex alike — to the most expensive tier with maximum thinking effort is equally wrong, and it's the version the exam asks about more often.
Proportionality cuts both directions. "Use Opus everywhere to be safe" is not a safe default; it's an unjustified default with a bill attached.
Breaking behaviour changes across releases
A prompt tuned against one model version can behave differently on the next. That's not a defect — it's the expected consequence of a model improving, and the blueprint names it directly.
It makes selection and configuration one concern rather than two: choose a tier, pin the exact version, and re-run your evaluation set before moving to a newer one. Pinning without re-evaluation just postpones the surprise; re-evaluating without pinning means it arrives unannounced.
Key concept
Profile the workload on volume, boundedness, and stakes, then justify the tier from those properties. Over-serving is as wrong as under-serving. Pin the version and re-evaluate before upgrading.
Practice scenario
Work it through, then open this
Over-serving, which the exam treats as exactly as wrong as under-serving. Safety isn’t a tier. Profile each task on volume, boundedness, and stakes, then justify the tier from those three properties. A bounded high-volume classification is a small-tier task whatever industry it’s in.
Build exercise — Justify every tier in one pipeline
Intermediate · 25 min
What you’ll learn
- Profiling a task on volume, boundedness, and stakes
- Spotting over-serving as well as under-serving
-
List every model call in one pipeline and tag each with its volume, how bounded the task is, and what a wrong answer costs.
- Why: These three properties are what the tier decision actually rests on — not the domain the app is in.
- You should see: Tasks clustering at the ends rather than spread evenly.
-
For each call, write one sentence justifying its current tier from those three properties alone.
- Why: If the justification is ‘it’s what we started with’ or ‘to be safe,’ you’ve found either over-serving or an unexamined default.
- You should see: At least one call that can’t be justified — usually something simple running on the top tier.
-
Change one over-served call down a tier, run your eval set, and compare.
- Why: Tier is the lever that trades quality, so it never moves without a measured before and after.
- You should see: Either a cost win with no quality loss, or evidence that the tier was right after all. Both are useful.
Exam traps
Defaulting everything to the top tier “to be safe”
Over-serving simple tasks is a tested failure, not a conservative choice. Match the tier to the task profile.
Downgrading tier as the first cost lever
Caching and context trimming come first — they cut cost without touching quality. Tier is the third step, not the first.
Treating a behaviour change after an upgrade as a bug
It is the expected consequence of a new model version. Pin, re-evaluate, then move deliberately.
Choosing a tier from the domain rather than the workload
“Healthcare so use Opus” is not the reasoning. A bounded, high-volume extraction task in healthcare is still a Haiku task.