The Sonnet-First Default Heuristic for the CCAR-P Exam

A default that saves you from your instincts

The Claude model family gives you a spectrum, but a spectrum on its own does not tell you where to start. The Sonnet-first heuristic answers that. Begin every new workload on Sonnet, the balanced middle tier, and treat any move away from it as a decision that has to be earned. The Claude Certified Architect - Professional (CCAR-P) exam treats this as an understand-level skill because the reasoning behind the rule matters as much as the rule: Sonnet is the default not because it is always best, but because it is the point on the capability-cost-latency spectrum from which a measured move in either direction is cheapest to justify.

The heuristic exists mostly to protect you from two instincts. One instinct reaches for Opus at the outset because the task "sounds important." The other refuses to consider Haiku because a cheaper model "surely can't be good enough." Both skip the only thing that settles the question, which is a measurement.

Why Sonnet is the starting point

Sonnet earns the default position because it balances intelligence, speed, and cost for the majority of production workloads. Starting there means most workloads land on a tier that already meets their bar, so no change is needed at all. When a change is needed, starting from the middle means you have a clear reference: you know what Sonnet produced, and you can measure whether Opus closes a gap Sonnet left open, or whether Haiku holds quality while cutting cost.

Contrast this with starting on Opus. If Opus works, you have no idea whether Sonnet or even Haiku would have worked just as well, so you are likely overpaying with no way to know. Starting from the top hides the information you need to make the tier decision defensible.

Moving up: only on a demonstrated gap

Moving up to Opus is justified only when an eval shows Sonnet fails to meet the quality bar. The trigger is a demonstrated gap, not a feeling that the task deserves the best model. In practice this means you run Sonnet against a representative test set, grade the outputs, and find that the quality falls short of what the task requires. That measured shortfall is your license to spend more on Opus. Absent it, the upgrade is speculative spending.

This is the discipline the exam probes with its first trap: selecting Opus at the outset because the task sounds important, without an eval showing Sonnet is insufficient. Importance is not evidence. Only the eval is.

Moving down: validated, not assumed

Moving down to Haiku is justified only when an eval confirms the quality tradeoff is acceptable for the specific task. The mirror-image trap is assuming a cheaper model can never be validated for a task without first testing it. That assumption leaves real savings on the table. A well-specified, high-volume step may run on Haiku with no meaningful quality loss, but you only know that once you have tested it against the same graded set you would use for any tier decision.

Both directions share one rule: the tier change is gated by a measurement. That is what makes the heuristic evidence-driven, and it connects directly to the release discipline in eval-gated model swaps.

What the exam trips candidates on

The two traps are symmetrical. The first is selecting Opus at the outset because the task "sounds important" without an eval showing Sonnet is insufficient. A scenario will dress up a task as high-stakes and invite you to reach for the top tier; the credited answer starts on Sonnet and upgrades only on measured evidence. The second is assuming a cheaper model can never be validated for a task without first testing it against an eval set. A scenario will dismiss Haiku out of hand; the credited answer tests it before ruling it out.

Notice that both traps are the same error in different costumes: substituting intuition for measurement. The heuristic is the antidote in both directions.

Common misreadings to avoid

How this shows up on the exam

Understand-level questions describe a team about to pick a tier by instinct, in either direction, and ask what an architect should do. The reliable answer starts on Sonnet and makes any move contingent on a measured eval: up to Opus on a demonstrated gap, down to Haiku on a confirmed acceptable tradeoff.

This heuristic builds on the Claude model family trade-offs and feeds directly into eval-gated model swaps, which formalises the measurement into a release gate, and per-step model tiering, which applies the same start-and-justify logic step by step. Skipping the default is itself a mistake, as diagnosing an undeclared model-tier default shows.