3.2 Model Selection: Haiku, Sonnet, and Opus

Anthropic's model family spans a spectrum of capability, speed, and cost, and the names map to a consistent ordering you can rely on across the whole exam. Haiku sits at the fast, low-cost end -- built for speed and efficiency on straightforward tasks. Sonnet is the balanced middle -- strong general capability at moderate cost and speed, the everyday workhorse for most business tasks. Opus sits at the far end -- the most capable tier, reserved for the deepest reasoning on genuinely complex problems, at the highest cost.

It's tempting to treat Opus as simply "the good one" and default to it whenever there's any doubt. That instinct is exactly backwards. "Always use the most capable model to be safe" wastes cost and latency budget on simple work that a faster, cheaper model would have handled just as well -- there's no safety gained by paying more for capability the task never asked for.

A related trap sits right next to it: assuming a bigger model fixes a bad prompt. A clearer, more specific prompt often matters more than moving up a model tier. Reaching for Opus to compensate for a vague or poorly structured request treats the model tier as a lever for a problem that actually lives in the prompt itself.

Model selection is about matching a model to what the task actually demands, not to a general sense of importance. Three buckets cover almost every scenario the exam will hand you.

• •Speed/cost matter, reasoning is simple -- a faster, lower-cost model (Haiku). The canonical exam example: generating a high volume of short customer-reply drafts, where speed and cost matter more than deep reasoning. The correct choice is the faster, lower-cost model, not the top-tier one.
• •Balanced everyday work -- Sonnet handles most drafting, summarizing, and analysis well.
• •Hard, high-value reasoning -- Opus, where the quality gain is worth the added cost and time.

For a single request, using a slower, more capable model just means one slower answer -- a cost that's easy to shrug off. That reasoning breaks down the moment volume enters the picture. For a high-volume batch workflow -- thousands of short replies, for example -- that same per-request slowdown compounds across the whole batch. A top-tier model can bottleneck an entire workflow even though each individual answer it produces is higher quality.

Every task carries an implicit budget across cost, latency, and quality. Selection is the act of matching the model to that target -- not maximizing one dimension (usually quality) while ignoring the other two. A model that is more capable than the task requires is not a safer choice; it is an over-spend of both money and time, with no offsetting benefit for a task that did not need the extra capability.

This reframes the whole domain: model selection isn't about ranking models from worst to best and picking the top of the list. It's about reading the task's actual budget -- how fast does this need to be, how much can it cost, how good does it truly need to be -- and choosing the model that clears that bar without paying for headroom nobody asked for.

One more constraint sits underneath everything above: which models and features are reachable at all also depends on the plan/pricing tier currently in use. Selection happens within whatever the current plan makes available -- a model that would be the ideal fit for a task may simply be out of reach on a given tier, which is a separate constraint from the cost/latency/quality tradeoff itself.

When cost becomes a real pressure, the correct lever is to right-size the model within the current plan -- not to switch AI platforms or disable product features to cut cost. Those moves address the wrong problem: they change the toolset rather than matching the tool already in hand to the task at hand.