Opus, Sonnet, and Haiku Use Cases for the CCDV-F Exam

Why Claude comes in tiers

The Claude Certified Developer - Foundations (CCDV-F) exam expects you to treat model choice as a first-class design decision, and that starts with understanding why there is more than one model to choose from. Anthropic publishes Claude in a small family of capability tiers, most commonly framed as Opus, Sonnet, and Haiku. The single organising principle behind the family is a trade of capability against speed and cost: larger models handle the hardest reasoning, while smaller models are faster and cheaper for simpler tasks. Every use-case decision in this knowledge point flows from that one sentence.

That framing only makes sense once you understand how a model actually produces output, which is why tokens, context windows, and next-token generation is the prerequisite here. A larger model spends more computation per token generated, so it can hold more of a hard problem in view and reason through it, but each of those tokens costs more and arrives more slowly. A smaller model spends less per token, so it answers faster and cheaper, but it has less headroom for genuinely difficult reasoning. The tiers are three points chosen along that same curve.

What each tier is suited for

Think of the three tiers as answers to three different shapes of task rather than as good, better, and best versions of one thing. The largest tier is suited for the work where reasoning quality is the binding constraint: multi-step analysis, hard code generation, ambiguous problems where a wrong answer is expensive, and tasks that genuinely need the model to hold a lot in mind at once. You reach for it when the difficulty of the task is high enough that a smaller model would visibly fall short.

The middle tier is the balanced default for the large space of tasks that need solid reasoning but not the absolute ceiling: most drafting, summarisation, routine code assistance, and workflows where quality matters but the problem is not at the frontier of difficulty. The smallest tier is suited for simpler, high-volume work where speed and cost dominate: classification, extraction, routing, short transformations, and anything you run at scale where each call must be cheap and fast. The key concept to internalise is that the suitability of a tier is a function of the capability the task demands, not a ranking you apply uniformly.

Selection starts from the task, not the model

The most important habit this knowledge point teaches is the direction of reasoning. You do not start from a favourite model and ask what it can do; you start from the task and ask what it needs. Concretely, model selection starts from the task's difficulty and its latency and cost budget. Name the hardest thing the task requires the model to do, decide how good the output has to be, and note how fast and how cheap each call must be. Only then do you map those requirements onto the smallest tier that can still meet them.

That ordering matters because it is the discipline that both exam traps violate. When you start from the model instead of the task, you either reach reflexively for the biggest tier and overpay on everything, or you reach for the smallest tier to save money and quietly ship work it cannot do well. Starting from the task keeps you honest in both directions, and it is the same discipline that the quality, latency, and cost tradeoffs knowledge point turns into an explicit balancing act.

Adaptive thinking as a second lever

Tier is not the only dial. Some tiers support an adaptive or extended thinking mode that can be enabled for harder reasoning when a task needs it. This lets the model spend additional internal reasoning before it answers, which raises quality on difficult problems, but it adds latency and consumes extra tokens. The practical consequence is that a middle tier with adaptive thinking enabled can sometimes reach a quality bar you might otherwise assume requires the largest tier, at a different point on the cost and latency curve.

Treat adaptive thinking the same way you treat tier selection: enable it where the task's difficulty justifies the extra time and cost, and leave it off where it would only slow down work that did not need it. This interacts with the prompting choices covered in model options and shot-based prompting, because the same task can sometimes be met by a smaller tier with a better prompt rather than a larger tier with a heavier configuration.

What the exam tests you on

The CCDV-F exam trips candidates on two opposite failure modes, and the questions are usually built so that one of them is the tempting wrong answer. The first trap is defaulting to the largest model for every task regardless of cost and latency. This feels safe because bigger sounds better, but it wastes money on trivial calls and adds latency that a user-facing feature cannot afford. A scenario that describes a simple, high-volume classification job running on the top tier is signalling this trap: the credited answer moves the workload down to a smaller tier that still meets the quality bar.

The second trap is the mirror image: using the smallest model for a task whose quality bar it cannot meet. This shows up as a team that chose the cheapest tier to save money and now sees poor results on genuinely hard reasoning. Here the fix is to move up, not to keep tuning a model that lacks the capability the task requires. The exam wants you to notice that saving cost is only correct when the smaller tier still clears the quality bar, and to recognise when it plainly does not.

Putting it to work

Once you can place a task on the capability curve, the rest of task statement 5.3 follows naturally. The same difficulty-first reasoning feeds directly into quality, latency, and cost tradeoffs, where you make the balance explicit against a task's non-functional requirements, and it sets up breaking behavior changes across model releases, where you learn that a chosen tier is not a permanent decision. The measured token usage from those tasks then becomes the input to cost modeling, which turns your tier choices into a spend forecast.

A useful mental checklist locks this in. Ask what the hardest thing this task requires the model to do is, how good the output must be, and how fast and cheap each call must be. Map those answers onto the smallest tier that still clears the bar, and enable adaptive thinking only if the difficulty warrants it. Do that per task rather than per application, and you will avoid both of the traps the exam is built to catch.