Which Claude model to use: Haiku, Sonnet or Opus

Classify the task, write down the quality bar it has to clear, pilot the lightest tier that could plausibly clear it, and escalate only when a measured result misses that bar. That you should not reflexively reach for the largest model is the half everyone already knows — it is one of the shortcuts that recur across all four exams. What the exams actually score is the half nobody writes down: the evidence behind the choice.

Which Claude model to use, in one pass

The decision is a constrained optimisation, not a ranking. Fix a minimum acceptable quality in terms specific to the task — extraction accuracy, required fields present, citations that hold, a reviewer accepting the draft — and then minimise cost and latency subject to that bar. Ranking the tiers against each other in the abstract answers a question nobody asked.

The order matters and it runs upward. Start at the lightest tier that could plausibly work and buy capability on measured failure, rather than starting at the top and negotiating down on price.

Models are one objective of four

Worth noticing, because it changes what to revise. The Associate domain is called Product and Model Selection, and its four published objectives are product features, model types, aligning selection to task requirements, and context limits — when to restart, summarise or persist.

So a scenario that opens with a model question is often settled by a feature, a source or a context decision instead. Choosing a project over a one-off chat, or resolving what happens when a conversation outgrows its working set, are separately examinable — and neither is fixed by a heavier tier. The tier names themselves come from that objective, which lists Haiku, Sonnet and Opus as examples of capability tiers rather than as a fixed catalogue.

What actually justifies moving up a tier

Three questions, in order, and a no at any of them means the answer is not a bigger model.

That first gate is worth dwelling on. If the threshold gets defined after the cheaper output comes back, it will be defined to fit what came back — the bar quietly moves to meet the result instead of the result having to meet the bar. Written down first, it is a test; written down afterwards, it is a justification.

The second gate matters just as much. A heavier tier buys reasoning capability. It cannot supply a source nobody provided, resolve two documents that contradict each other, or repair an instruction that never said what the output was for.

Cheaper is not cheaper if someone has to fix it

Per-request price is never the unit of comparison. The comparison that counts runs end to end: retries, reviewer time, rework, escalations, and the cost of an error that reaches someone. A lighter tier that halves generation time and doubles the reviewing is more expensive, not less, and the exam expects you to notice.

Latency has the same trap in a different shape. Optimising average response time while ignoring the tail means the deadline that actually matters is the one you miss. Averages are not commitments.

One workflow, more than one tier

The reframe that makes the answer better than the question: the unit of decision is the step, not the application — though what shape those steps form is decided separately. Asked which model a system should use, the defensible answer is frequently "more than one".

One pipeline can route extraction to a light tier, synthesis to a heavier one, and a final check to a qualified human — and the ladder does not stop at the largest model, because a reviewer is the last tier. How those steps actually hand work to each other is a contract in its own right. A scenario offering one model for the whole system is usually offering the wrong shape of answer. Both Claude Certified Associate – Foundations and Claude Certified Architect – Foundations examine this, from different ends.

Why this survives the lineup changing

The published objective names those tiers as examples, and the exam guides say plainly that lineups, surfaces and feature availability change frequently. That is not a caveat bolted onto the exam — it is why the exam is written the way it is. Items turn on relative fit, so they keep working when a new tier ships and an old one is retired.

Which means the preparation that pays is the method, not the spec sheet. Verify current specifics against official Anthropic documentation close to your test date rather than relying on any guide, including this one. How the rest of the blueprint is weighted is set out in what the Claude exam actually tests, and the Claude certification study guide covers how to build practice around a domain like this one. If you are still choosing an exam, the guide to choosing a Claude certification compares the four.

Key takeaways

• Set the quality bar before you look at a tier. Defined afterwards, it will be defined to fit the result you already have.
• Escalate on measured failure, not on nerves — and only when the gap is capability rather than a prompt, a source or missing context.
• Every tier is a trap when chosen by reflex, including the middle one. Short output is not the same as a simple task.
• Compare end to end. Retries, reviewer time and rework decide which option was actually cheaper.
• Choose per step, not per system, and remember the last tier in the ladder is a qualified human.