When Should You Use Opus vs. Sonnet vs. Haiku (CCA-F D5)?

The reflex of the last cycle was simple: pick the most capable model and use it for everything. That reads as caution. It is actually waste, because most work does not need the flagship and most budgets cannot afford running it everywhere.

The shift now is tiered specialization: a clear hierarchy of models chosen per task by cost, speed, and the reliability the task demands (first-hand: Claude ships in distinct tiers, Haiku, Sonnet, and Opus, built for different operating points).

The mental model:

• Haiku is the throughput layer. Real-time classification, log analysis, routing, low-stakes triage.
• Sonnet is the daily driver. Standard professional work, content, routine coding.
• Opus is the final stretch. Accuracy-critical, multi-step work where one error breaks the system.

Routing is two decisions, made per unit of work.

• Tier (which model). Match the task's accuracy and reliability bar to the smallest model that clears it. Do not reach for the flagship by default.
• Escalation (when to climb). Let a cheap tier handle the common case and escalate only the hard or high-stakes items. A small model can even triage and route to a larger one.

Worked example - "process a queue of support tickets."

1. Triage on the cheap tier: classify and route every ticket on the throughput model.
2. Handle the routine on the mid tier: standard replies and lookups go to the daily driver.
3. Escalate the hard cases to the strong tier: ambiguous or high-stakes tickets, where an error is expensive, get the flagship.
4. Verify the escalations: the strong tier is where reliability matters most, so check its output, not the triage.

That is Task-Tier Routing: cheap by default, strong where it counts.

The Convenience Tax - the premium you pay for routing all work to one big model because it is easier than choosing. It shows up as a larger bill, slower responses, and reliability effort spread thin across work that did not need it. You stop paying the Convenience Tax by routing per task tier and escalating selectively, not by buying a bigger default.

This sits in D5 - Context Management & Reliability, which is 15% of the exam and connects to context window, prompt caching, and evaluation.

The proprietary read: D5 questions reward right-sizing under cost and reliability limits, not maximizing capability.

• Old instinct: the biggest model is the safe choice.
• D5 instinct: the smallest model that meets the bar, with the flagship reserved for the reliability-critical step.

The distractor pattern to memorize. On D5 scenarios about runaway cost, latency, or reliability, the trap answer is "upgrade to the biggest model." The architecturally correct move is one of:

1. Route by task tier (smallest sufficient model per unit of work), or
2. Escalate selectively (cheap tier triages, strong tier finishes), or
3. Reserve the flagship for the critical step (and verify there, not everywhere).

See developer productivity agent for a mixed-tier workflow in practice.

1. Stop defaulting to the flagship. Start every task from the smallest tier that could plausibly meet the bar.
2. Triage cheap, finish strong. Let a throughput model route, escalate only the hard cases.
3. Tie tier to stakes. Reserve the strongest model for work where one error breaks the system.
4. Evaluate before you trust a downgrade. Prove the cheaper tier meets the bar on the real task.
5. Pair routing with caching. Cheap tier plus caching is where the cost savings compound.
6. Measure the Convenience Tax. If everything runs on the flagship, that uniform bill is the tax.

The meta-skill, and the D5 exam skill, is the same: capability per dollar comes from routing work to the right tier, not from a bigger default.