Claude Model Family Trade-offs for the CCAR-P Exam

Three tiers, one spectrum

The first thing the Claude Certified Architect - Professional (CCAR-P) exam wants you to internalise about the model family is a framing, not a feature list. Opus, Sonnet, and Haiku are not three editions of one product where you always want the newest and biggest. They are three deliberately different points on a single spectrum that trades capability against cost and latency. Move toward one end and you gain reasoning depth while paying more per token and waiting longer; move toward the other and you gain speed and low cost while accepting a lower capability ceiling. Every model decision an architect makes is a position on that line.

Getting this framing right matters because the wrong framing produces a predictable class of mistake. If you think of the tiers as good, better, best, you will reach for the top every time and never notice the cost. If you think of them as points on a spectrum, you start asking the only question that matters: what does this specific piece of work actually require?

What each tier is built for

Opus is Anthropic's most capable tier, built for the demanding end of the work: multi-step reasoning, advanced coding, and research synthesis where the quality of the answer depends on getting hard judgment right. When a step genuinely stresses the model's reasoning, Opus is where the extra capability earns its cost.

Haiku sits at the other end. It is optimised for high-volume, low-latency, cost-sensitive work: the classification, routing, extraction, and short-response tasks that a system runs thousands of times a day and where speed and price dominate. Its capability ceiling is lower than Opus by design, and for the tasks it targets that ceiling is not the binding constraint.

Sonnet is the balanced middle and, for most production workloads, the right place to begin. It carries enough capability to handle the bulk of real work while costing far less and running faster than Opus. That balance is exactly why the platform treats it as the conventional default, a point developed in the Sonnet-first default heuristic.

Why the spectrum framing changes design decisions

Once you see the tiers as a spectrum, two design habits follow. First, you stop assuming a single tier must be applied uniformly across an entire architecture. A pipeline can route its cheap classification step to Haiku and reserve Opus for the one synthesis step that needs it, an idea covered in per-step model tiering. Second, you start treating any move along the spectrum as a decision that needs evidence rather than intuition, because each move trades measurable cost and latency for measurable capability.

The spectrum also reframes what "expensive" means. The top tier is not wasteful in itself; it is wasteful when applied to work that a cheaper tier would handle indistinguishably. The skill is placing each task at the lowest point on the spectrum that still meets its quality bar.

What the exam trips candidates on

Two traps recur on this knowledge point, and both come from collapsing the spectrum into a ranking.

The first is treating "most capable" as a synonym for "correct choice" at every step of a pipeline. A scenario will describe a system that runs a trivial routing or classification step on the top tier and ask what is wrong. The credited reading is that capability the step never uses is being paid for on every call. The second is assuming a single model tier must be used uniformly across an entire architecture. A scenario will present a multi-step system and imply one tier must cover all of it. The correct reading is that different steps can and often should sit at different points on the spectrum.

Common misreadings to avoid

How this shows up on the exam

Remember-level questions on this knowledge point ask you to identify what distinguishes the three tiers or to spot the framing error in a design that treats them as a ranking. The reliable reading is always the spectrum: Opus for the hardest reasoning, Haiku for high-volume low-latency work, Sonnet as the balanced default, and no assumption that one tier must cover an entire system.

This knowledge point is the foundation for the Sonnet-first default heuristic, which turns the spectrum into a starting rule, and for per-step model tiering, which applies it across a pipeline. It also underpins diagnosing an undeclared model-tier default, where failing to place work on the spectrum silently defaults to the most expensive tier.