Model selection trade-offs

What you’ll be able to do

• Select a Claude model tier per workload step by weighing capability, latency, cost and volume against an evaluation bar
• Design routing and cascades that send hard cases to a larger model without paying for it on easy ones
• Distinguish problems a bigger model solves from problems caused by prompts, context or retrieval
• Manage model versions as a production dependency: pinning, re-evaluation and controlled migration

What you need to know

The decision is per step, not per product

Claude is offered as a family of tiers. The larger models (the Opus line) are the strongest at multi-step reasoning, ambiguous judgment and long agentic work; the mid tier (Sonnet) balances capability with speed and cost and is the usual workhorse; the smallest tier (Haiku) is the fastest and cheapest and is well suited to high-volume, well-specified work such as classification, routing, extraction and short transformations. Exact prices, context limits and version names change, so read them from the current models page on docs.claude.com rather than memorizing them.

At the Professional level, "which model?" is rarely one answer. A production system is a pipeline: an intake classifier, a retrieval step, a drafting step, a checker, maybe an orchestrating agent. Each step has its own difficulty, its own volume and its own latency budget. A triage classifier that runs on every inbound ticket and must answer quickly is a different selection problem from a once-a-day planning agent that decides which of forty tools to call. Selecting one model for the whole product either overpays on the easy steps or under-serves the hard one.

The four forces and the evaluation bar

• Capability. Does the step need multi-hop reasoning, judgment under ambiguity, long-horizon tool use, or nuanced writing? Or is it pattern-matching against clear criteria?
• Latency. Is a person waiting on it (interactive chat, inline code suggestion), or is it a background job where minutes are fine?
• Cost × volume. Per-call cost matters only multiplied by how often the step runs. A small per-call saving on a step that runs millions of times a month can dominate the bill; the same saving on a nightly job is noise.
• Risk. What happens when the step is wrong? A mis-tagged ticket gets re-routed; a wrong figure in a regulatory filing does not get caught by anyone downstream.

Those forces are weighed against an evaluation bar: a task-specific test set with a threshold the step must pass. The working rule is to start each step on the smallest tier you think might pass, run the eval, and move up only when the eval says so. Public benchmarks tell you about general capability, not about your documents, your labels or your edge cases. When a cheaper tier fails, look at which cases fail. If the failures are concentrated in one class of hard input, that is a routing opportunity, not a reason to move the whole step up.

Routing and cascades

Two patterns let you pay for capability only where it's needed:

• Routing. A cheap first step (often a small model, sometimes plain rules) classifies the request and sends it to the tier that fits: simple FAQ to the small model, multi-document analysis to the large one.
• Cascade. Every request tries the cheaper tier first; an observable check decides whether to escalate. Good escalation signals are things you can verify: schema validation failed, a required field is missing, a citation doesn't resolve to a retrieved passage, a deterministic rule disagrees. A model's own stated confidence is a weak signal on its own, because it isn't well calibrated without validation against labeled data.

Both patterns add a component that can be wrong, so evaluate the router itself and track the escalation rate. If most traffic escalates, the cascade is just adding latency in front of the large model.

Capability is not the fix for every failure

A senior instinct worth un-learning: "it's giving wrong answers, try the bigger model." A larger model reasons better over the context it's given. It can't recover facts that retrieval never delivered, follow a rule the prompt never stated, or produce a format no example showed. Before attributing a failure to capability, check the context: was the right passage retrieved, was the instruction there, did the inputs change? Capability is the likely culprit when the context is demonstrably complete and correct and the model still reasons badly, typically on multi-step logic, conflicting evidence or long tool sequences.

Extended thinking is a related lever. Giving a model room to reason before answering can lift quality on hard reasoning steps, at the cost of latency and output tokens. Treat it as another configuration to evaluate per step, not a global switch.

Versions are a dependency

Models are released and retired on a schedule you don't control. Treat the model identifier like any pinned library version: production calls name a specific model version, the eval suite runs against any candidate replacement before cutover, and the migration has a rollback path. Model aliases that point to "the latest" are convenient for prototypes and risky in production, because behavior can shift without a deploy on your side. Watch the deprecation notices and budget time for re-evaluation, especially for prompts tuned to one model's quirks.

Key concept

Choose the smallest model that passes a task-specific evaluation for each step, escalate hard cases on observable signals, and pin versions so a model change is a deliberate, re-evaluated release.

Questions present a cost, latency or quality complaint and offer "switch everything to the largest model", "switch everything to the smallest" or "route per step". The strong answer almost always matches tier to step using evidence, and checks whether the failure is really about context before buying capability.

Practice scenario

Build exercise — Build a per-step model selection matrix

Advanced · 40 min

What you’ll learn

• Profiling pipeline steps by capability need, latency, volume and risk
• Running a tier-by-tier evaluation and reading where failures cluster
• Designing an escalation signal you can actually observe

1. List every model call in a real or sample pipeline and record, for each, its volume, its latency budget and the consequence of a wrong output.

   • Why: Model choice is a per-step trade-off. Without volume and risk on the page, cost and quality arguments are guesses.
   • You should see: Steps that differ by orders of magnitude in volume, and at least one step where an error is far more expensive than the others.

2. Build a small labeled eval set for two contrasting steps and run it against two tiers. Group failures by input type.

   • Why: The smallest tier that passes is the target; failure clusters tell you whether to move the step up or route a subset.
   • You should see: One step where the smaller tier passes outright, and one where failures concentrate on an identifiable class of input.

3. For the step with clustered failures, design an escalation rule based on a check you can run (schema validation, citation match, rule disagreement), and measure the escalation rate.

   • Why: A cascade only saves money if escalation is rare and triggered by something verifiable.
   • You should see: A minority of requests escalating, and quality on the escalated subset matching the larger tier’s.

Exam traps

Choosing the most capable model for every step because it is the safest default

It overpays and adds latency on simple, high-volume steps. “Safe” means passing the eval at the lowest cost and latency, not maximum capability everywhere.

Upgrading the model to fix failures that come from missing or wrong context

A larger model can’t use facts it was never given or rules it was never told. Check retrieval, inputs and instructions first.

Choosing the cheapest model for a high-stakes step because it scored well on average

Averages hide the tail. For high-risk steps, look at failures on the hard cases and the cost of each error, not the mean score.

Selecting a model from public benchmarks instead of an evaluation on your own task

Benchmarks measure general capability. Your documents, labels and edge cases are what production will see.

Pointing production at a moving model alias with no re-evaluation when it changes

Behavior can shift without a deploy on your side. Pin versions and treat a model change as a release that goes through the eval suite.

Routing by a model’s self-reported confidence instead of an observable signal

Self-reported confidence is poorly calibrated on its own. Escalate on checks you can verify, such as validation failures or unsupported citations.

Sources

• Claude Developer Platform Docs (models overview, extended thinking)
• Anthropic, Claude Certified Architect – Professional Exam Guide v1.0 (July 2026)