5.4 Model Tiers and Tradeoffs

Claude is offered in three tiers, and none of them is "the good one" in isolation — each is built for a different point on the capability/speed/cost spectrum. Haiku is the fastest and cheapest tier, positioned for high-volume, latency-sensitive, simpler work: classification, extraction, and routing are the textbook fits. Sonnet is the balanced workhorse — capable enough for most production application logic, priced and paced for everyday use, and the tier most systems default to for their core reasoning steps. Opus is the most capable tier, at the highest cost and latency, reserved for the hardest reasoning, the most complex agentic behavior, and the highest-value work where getting it right outweighs getting it fast or cheap.

The exam wants you to treat this as a matching problem, not a ranking problem. "Which model is best" isn't itself a well-formed question — the well-formed question is "which tier fits this specific task's difficulty and value." A routing step and a hard multi-step synthesis step have different right answers, even within the same application.

Every model choice sits inside a triangle of quality, latency, and cost. Push toward more quality and you typically pay in latency, cost, or both; push toward less latency and cost, and quality has less headroom. That triangle only resolves into an actual decision once it's pinned against a real, specific requirement — a latency SLA, a per-request cost ceiling, a quality bar a downstream reviewer would actually accept. "Which model is objectively best" is not a well-formed question in isolation; "which model resolves this specific constraint" is.

This is why "always pick the most capable model to be safe" is the wrong instinct on this exam. It sounds conservative, but it wastes cost and latency on tasks a cheaper tier already handles just as correctly — there's no safety benefit to paying Opus prices for a routing step Haiku nails. The inverse mistake also exists: running a genuinely hard reasoning task on the cheapest tier to save money can cripple quality on exactly the step where quality matters most.

A production workflow is rarely one uniform task — it's usually a sequence of distinct steps, each with its own difficulty, volume, and stakes. Treating "which model should our workflow use" as one system-wide decision throws away the biggest lever available: assigning each step to the tier that actually fits its own profile. A mixed-model architecture routes cheap, well-defined steps to Haiku and hard reasoning or orchestration steps to Sonnet or Opus, within the same workflow.

A document-processing pipeline is a clean illustration: Haiku classifies each incoming document's type (cheap, high-volume, simple); Sonnet extracts and summarizes the content (moderate reasoning, still frequent); Opus handles only the final step that synthesizes findings across documents into a decision memo (rare, hard, expensive to get wrong). Three tiers, one pipeline, each tier doing the job it's actually suited for — and adaptive-thinking support, which varies by tier, factors into which tiers are even viable for a step that needs that capability.

• 1.Break the workflow into its individual steps rather than treating it as one task.
• 2.Assess each step's own difficulty, volume, and stakes independently.
• 3.Assign each step the tier that fits its own profile — not the tier the hardest step needs.
• 4.Check whether a step's required thinking mode is supported on the tier being considered for it.

Domain 1's manager/subagent-hierarchy lesson covers WHEN a manager/subagent architecture is the right shape for a task, and mentions in passing that it multiplies token usage and adds coordination overhead. This note is the concrete number behind that caution — the figure that turns "should we use subagents" from a vibes-based call into a measurable cost tradeoff you can actually put in a budget.

In an orchestrator-worker setup, a lead agent breaks a task into pieces and hands each piece to a separate subagent, all running at the same time, each with its own context window; once every subagent has returned a result, the lead pulls those results together into one final answer. Anthropic's own multi-agent research team put a concrete number on what that structure actually costs. Running an internal research-quality benchmark, an orchestrator-worker configuration — Opus in the lead role, Sonnet running the subagents — beat a single Opus agent working alone by a meaningful margin on quality. That gain wasn't free, though: the multi-agent version burned **roughly 15 times the tokens of an ordinary single-agent exchange.**

Put round numbers on it to see the shape of the tradeoff. Say a lone agent handles a research question in roughly **10,000 tokens** total — it reads the sources, works through the reasoning, and writes the answer, all in one context. Send that exact same question through an orchestrator-worker setup instead, with one lead directing four subagents (five contexts running, since the lead itself burns tokens on planning and pulling the final answer together). At Anthropic's reported ratio of **~15x** for that five-context shape, the identical question now runs on the order of **150,000 tokens** (10,000 times 15). And that ratio isn't just on the input side — it hits output tokens equally, since every one of the five contexts generates its own complete response with nothing shared or reused between them.

The multiplier is not inherently good or bad — it's a cost that has to be earned by the task's shape. It pays off specifically when the task decomposes into genuinely independent subtasks that benefit from parallel exploration — research across several unrelated sources is the canonical fit, since each subagent's slice of work doesn't depend on what any other subagent finds. The multiplier is markedly LESS effective for tightly-coupled tasks, and coding is the textbook case: when each step depends on the previous step's output, there is nothing genuinely parallel to fan out across, so subagents mostly end up waiting on each other's results while each still burns its own full context. Paying 15x on a task that doesn't decompose in parallel buys capacity the task never uses.

• •Good fit: research across several independent sources — each subagent explores a slice that doesn't depend on any other subagent's findings.
• •Poor fit: tightly-coupled work like coding — each step depends on the last, so subagents mostly wait rather than working in parallel.
• •Mitigation: use a more capable (expensive) model only for the lead, and cheaper models for the subagents, to offset some of the multiplier without abandoning the architecture.
• •The mitigation reduces the multiplier's effect on total SPEND — it does not reduce the ~15x token-COUNT multiplier itself.

There's a distinct risk in model selection that has nothing to do with which tier you pick: what happens when the model itself changes underneath you. A new release can shift behavior — accuracy on your specific task, adherence to your output format, tone — even when the API contract is completely unchanged and even when the new version is, on paper, more capable overall. A prompt carefully tuned against one version is not guaranteed to hold on the next.

The safe discipline mirrors how you'd treat any other dependency upgrade: pin the exact model version production runs against rather than floating to "latest" and inheriting behavior changes automatically. When a new release becomes available, treat adopting it like any other change that needs validation — re-run your evaluation set against the pinned prompt paired with the new model, and promote deliberately only once results confirm quality held or improved. Switching immediately "to get the improvements," or changing only the API key/model-name string while assuming everything else still behaves the same, skips the step that actually protects production quality.

• 1.Pin the exact model version used in production rather than floating to "latest."
• 2.When a new release appears, re-run the evaluation set against the pinned prompt paired with the new version.
• 3.Promote deliberately, only after evals confirm quality held or improved — never on the assumption that newer automatically means better for your specific prompt.

Task Statement 5.4 questions typically describe a step's volume, latency budget, and stakes — or a multi-step pipeline, or an upgrade scenario — and ask which tier (and whether extended thinking) fits, or what discipline an upgrade requires.

• •Defaulting to the most capable tier "to be safe." ✗ Any answer reaching for Opus regardless of the stated constraint. ✓ The answer anchored to the specific SLA, budget, or quality bar given in the scenario.
• •Treating model choice as one system-wide decision. ✗ An answer picking a single model for an entire multi-step pipeline. ✓ The answer routing each step to the tier its own difficulty/volume/stakes justify.
• •Assuming a new release is a safe drop-in replacement. ✗ An answer switching to a new model immediately without re-testing. ✓ The answer pinning the version and re-running evals before promoting a new release.