Product and Model Selection · Lesson 1 of 4

3.1 — Choosing a Model for the Task

Differentiate Claude's Haiku, Sonnet, and Opus model tiers by their speed/cost/quality trade-offs, and match each to the task it's actually built for.

Claude isn't one model with a single dial — it's a family of distinct tiers, and picking the right one is itself a tested skill, not a formality. Haiku is the fastest and cheapest tier, tuned for near-instant responses on simple, well-defined work. Sonnet is the balanced mid-tier: strong reasoning at a practical cost and speed, and the right default for most day-to-day business tasks. Opus is the most capable tier, built for the hardest reasoning problems and the longest autonomous runs — and it costs more and responds more slowly per request than the other two.

The trade-off underneath all three is the same one: speed and cost on one side, depth of reasoning on the other. A model that answers in a fraction of a second and costs a fraction of a cent per request is, by construction, not spending as much computation second-guessing itself as a model built to reason carefully through a genuinely hard problem. Neither end of that trade-off is "better" in the abstract — the exam consistently tests whether you can read a scenario's actual requirements (volume, complexity, stakes, how autonomous the run is) and match them to the tier built for that shape of work.

Reading the Signals: Haiku vs. Sonnet vs. Opus

Three concrete signals point toward each tier:

Haiku — high volume, simple, well-defined work: classifying support tickets into categories, tagging or extracting a known field from many short documents, quick factual lookups against a clear reference. When you're processing thousands of similar, low-complexity items and speed/cost at scale matters more than squeezing out the last percentage point of accuracy, Haiku is built for exactly that.
Sonnet — the default all-rounder: drafting, editing, analysis, everyday coding, summarizing, most single-conversation business reasoning. If a scenario doesn't specifically call out extreme volume-plus-simplicity, or a long autonomous run at the highest stakes, Sonnet is usually the right starting assumption.
Opus — long, high-autonomy, or highest-stakes reasoning: a multi-hour autonomous agent run refactoring a large, interdependent codebase, or a single decision where an error would be very costly and cost/latency are explicitly secondary concerns. Opus earns its higher cost when accuracy compounds over many steps, or when the one answer has to be right the first time.

Don't Default to Either Extreme

Two mirror-image mistakes show up in exam scenarios. The first is always reaching for the cheapest, fastest tier to save cost "by default," even on a long autonomous run where an early mistake from an under-capable model can quietly cascade through many later steps before anyone catches it — the cleanup costs far more than starting with the right tier would have. The second is always reaching for Opus "to be safe," even on a high-volume, low-complexity job like ticket tagging, where the extra cost and latency buy you nothing the task actually needed. The correct move is reading what the scenario specifies — volume, complexity, stakes, autonomy length — and matching the tier to that, not defaulting to either end out of habit.

It's also worth keeping model tier separate from a different lever covered in the next lesson: the effort parameter tunes how thoroughly a given model works on a request, without changing which model is doing the work. Tier selection answers "which model family fits this task's shape"; effort answers "how hard should this chosen model work on this particular request." They're related decisions, but they're not the same decision, and the exam tests both separately.

Key Concept

Match model tier to the task's actual shape: Haiku for high-volume, simple, well-defined work; Sonnet as the default all-rounder for everyday business reasoning; Opus for long, high-autonomy runs or single highest-stakes decisions where accuracy matters far more than cost or speed.

Common Exam Distractor

Watch for "always start with the cheapest model and escalate only if it fails" on a long, high-autonomy, high-complexity scenario — compounding early errors usually cost more than starting right. Watch equally for reaching for Opus on a task explicitly described as high-volume and simple, where the added cost and latency buy no real benefit.

Exam traps

Assuming one model tier is universally 'best' regardless of the task described

Each tier trades speed/cost against reasoning depth differently. The exam tests matching a scenario's volume, complexity, and stakes to the tier built for that shape of work, not picking a single favorite.
Defaulting to the cheapest/fastest tier on a long, high-autonomy, high-complexity task to save cost

On a long autonomous run, an early mistake from an under-capable model can cascade through many later steps before it's caught, costing far more in rework than starting with the right-sized model.
Confusing model tier selection with the effort parameter

Model tier decides which model family handles the task at all; the effort parameter (lesson 3.2) tunes how thoroughly the already-chosen model works on a given request. They are separate, related decisions.

Practice question

A team needs to automatically tag 50,000 incoming support tickets per day into one of six categories, as quickly and cheaply as possible. Accuracy matters but isn't mission-critical for any single ticket. Which model tier best fits this task?

A Claude Opus, because it will produce the most accurate categorization of any tier
Opus's extra reasoning depth is built for long, high-autonomy, or highest-stakes work — at this volume and with per-ticket accuracy explicitly described as important but not mission-critical, its added cost and latency buy little the task actually needs.
B Claude Haiku, because high-volume, well-defined classification at speed and low cost is exactly what the fastest tier is built for Correct
50,000 well-defined classification calls a day, prioritizing speed and cost with accuracy that's important-but-not-critical, is the textbook signal for Haiku.
C Claude Sonnet, because it's the correct default choice for every business task regardless of its shape
Sonnet is the right default when a task doesn't point strongly toward either extreme — but this scenario's explicit high volume and simplicity point specifically toward Haiku, not a blanket default.
D Whichever model is quickest to select in the interface, since model tier doesn't materially affect a classification task at this scale
Model tier directly affects both cost and latency at high volume — at 50,000 calls a day the difference between tiers compounds significantly, so the choice matters a great deal here.

Build exercise: Match Model Tiers to Task Shape

Beginner · 20 minutes

You'll practice:

Read the tier descriptions Claude presents for Haiku, Sonnet, and Opus
Practice matching volume, complexity, and stakes to a model tier
Distinguish a tier decision from an effort decision

In claude.ai, open the model picker and read through the description of each available tier (Haiku, Sonnet, Opus). In the Console, find the model list or pricing/comparison page and note the relative cost-per-token and speed positioning of each tier.

Grounding the speed/cost/quality trade-off in the actual product surfaces, rather than from memory, builds the concrete picture needed to reason about real scenarios.

You should see: Short descriptions distinguishing a fast/efficient tier, a balanced tier, and a most-capable tier, plus a visible cost or speed differential between them in the Console.
Hints
1. ```
If the picker doesn't show cost directly, check a linked model comparison or pricing page.
```
2. ```
Look for language like 'fastest,' 'balanced,' or 'most capable' as the distinguishing cues.
```
3. ```
Note which tier is positioned for advanced/agentic work specifically — that's your Opus signal.
```
Write two short hypothetical task descriptions from your own work or studies: one high-volume and simple (e.g. sorting a large batch of short items into categories), and one long-running, complex, and high-stakes (e.g. a thorough, careful analysis where an error would be costly). Assign a model tier to each in writing, with a one-sentence justification.

This exercises the actual decision skill the exam tests — matching tier to task shape — rather than just recalling tier names.

You should see: Two task descriptions, each paired with a tier choice and a justification that references volume/speed/cost for one and accuracy/stakes for the other.
Hints
1. ```
For the high-volume task, justify in terms of cost and latency at scale, not just 'it's simple.'
```
2. ```
For the complex task, justify in terms of what a compounding early mistake would cost to unwind.
```
3. ```
If you're stuck, imagine defending your choice to a teammate who asks 'why not just use the cheapest one for everything?'
```
Take one of your two task descriptions and deliberately argue, in writing, for the opposite tier choice — then explain in one or two sentences specifically why that choice would be worse.

Arguing the wrong answer directly rehearses the exam's distractor pattern: defaulting to either extreme regardless of what the scenario actually specifies.

You should see: A short written explanation of why the mismatched tier would either waste cost/latency (Opus on the simple task) or risk compounding errors (Haiku on the complex task).
Hints
1. ```
Be concrete: name the actual cost, latency, or accuracy consequence, not just 'it wouldn't be ideal.'
```
2. ```
This is the reasoning pattern the exam's incorrect answer options are built from — recognizing it here helps you spot it on the exam.
```
3. ```
Keep this to a couple of sentences; the point is the reasoning, not a long essay.
```

Sources

Reused/adapted from Associate lesson 2-5-model-selection (earlier draft)
Anthropic docs — Models Overview