What You Need to Know
Model selection is choosing which Claude model runs each task in a system. A task's quality bar is the standard its output must reach; an eval checks it on representative data. The latency budget is how long the next step can wait. The question is never "which model is best". It is "which model clears this task's quality bar at the lowest cost that meets the latency budget".
Take a petrol station with three Claude stages: sorting thousands of customer messages a week, drafting replies, and writing the manager's weekly summary. Each stage has its own volume, latency budget and quality bar.
Model Selection Is Constraint Satisfaction
Five axes decide the choice:
- Capability: does the model clear the task's quality bar? The bar is measured, not assumed (Domain 4 supplies the machinery).
- Latency: time-to-first-token and throughput compound across chained calls and agent loops. Each call waits for the one before it, so a per-call latency that looks fine in isolation multiplies along the hot path.
- Cost: price × tokens × volume. Work out per-task unit economics, not the per-token sticker price. The petrol station's sorter runs at the highest volume, so this axis weighs most there.
- Context window and output limits: these gate long-document and generation-heavy work outright.
- Lifecycle and platform availability: model availability differs across the Claude API, Amazon Bedrock, Google Cloud and Microsoft Foundry. The partner-operated platforms (Bedrock, Google Cloud) set their own retirement schedules. In enterprise designs, that is a compliance and procurement constraint.
Constraints rule candidates out before preference comes in. Capture the constraints first and the selection largely makes itself.
The Model Tiers
As of October 2026, the lineup has four tiers:
- a frontier tier for the hardest reasoning and long-running agents (Claude Fable 5.1)
- a heavyweight tier for complex agentic coding and enterprise work (Claude Opus 5.5)
- a balanced tier for speed and capability on everyday workloads (Claude Sonnet 5.5)
- a fast, low-cost tier for high-volume, latency-sensitive work such as classification, extraction and routing (Claude Haiku 5.5)
The tiers differ in capability, latency and price. So selection is constraint satisfaction, not a leaderboard read.
Durable vs Dated
Names and figures move; the tier structure and the selection logic do not. Current prices, context windows and output limits live in the Domain 2 quick reference as a dated snapshot. Re-verify them against the live models and pricing pages before relying on them.
Right-Sizing, Per Stage
Anthropic documents two starting points. Efficiency-first starts with Haiku 5.5, tests thoroughly and upgrades only where a capability gap is measured. Capability-first starts with Opus 5.5 and optimises down with greater workflow optimisation. Either way, benchmark tests on representative data decide whether a model clears the bar.
Right-size per pipeline stage, not per application. One model everywhere pays top prices on easy stages. A pipeline can run Haiku-class models for classification and routing and Sonnet-class for drafting. Keep Opus-class for the one synthesis step that measurably needs it, such as the station's weekly summary. The smallest model that clears each stage's measured bar is the cost lever with zero architectural cost. Only each stage's model changes.
Before switching tiers, try the effort parameter on current models. It trades intelligence for latency and cost within one model. Anthropic's model-choice guidance notes that tuning effort is often a better lever than switching models. If the station's replies run slow, check effort first.
Escalation Cascades
An escalation cascade sends each request to the small model by default. It escalates to the larger tier on low confidence, failed validation or an explicit trigger. Most requests never escalate, so the cascade buys near-big-model quality at near-small-model average cost. At the station, the sorter escalates low-confidence messages. Anthropic's agent guidance documents the underlying pattern as routing: easy or common requests go to smaller models, hard or unusual ones to a more capable tier.
Lifecycle Discipline
Every Claude model ID is a pinned snapshot. From the Claude 4.6 generation onwards, even dateless IDs are pinned snapshots, not evergreen pointers. Models move through a published lifecycle: active, legacy, deprecated, retired. Anthropic gives at least 60 days' notice before retiring publicly released models. Requests to retired models fail.
So pin versions, monitor deprecation notices and re-run evals before migrating. A model change is an architecture change. Never let an alias or a provider default silently move the production model. The station's sorter switches only after its eval passes.
In the exam
Every item on this objective tests whether you select on measured constraints or on prestige, and whether you demand eval evidence before moving in either direction. It tests the reasoning, not price recall: the smallest model that clears the measured bar, escalating where needed. The escalation cascade recurs as the keyed answer in cost-versus-quality stems because it addresses both sides of the trade instead of sacrificing one.
Escalation cascade is this site's shorthand for the trigger-driven variant of Anthropic's routing pattern.
Exam Traps
Running everything on the biggest model 'to be safe' when a cheaper tier clears the measured bar
Prestige selection burns the cost pillar for no measured quality gain. The premium is paid on every token of every request at volume, and no eval evidence supports the spend. The exam rewards the smallest model that clears the measured bar.
Switching to the smallest model as a cost fix without re-running quality evals
The guide's own sample plants exactly this distractor. Blind downsizing is a quality regression shipped on purpose: the cost saving is visible, the accuracy loss is not — until customers find it. Movement in either direction needs eval evidence.
Letting production run on an alias or a soon-to-retire model
Aliases and provider defaults can silently move the model under your evals. The keyed answer pins the snapshot, monitors deprecation notices, and schedules an eval-gated migration — never an in-place silent upgrade.
Upgrading the model tier because outputs are inconsistent
If the instructions are ambiguous, a larger model obeys the ambiguity more expensively. Diagnosis precedes spend: instruction clarity is the cheaper first fix, and a capability upgrade only helps a measured capability gap.
Practice Scenario
A document pipeline classifies incoming documents (high volume, latency-sensitive), extracts structured fields, and writes a one-paragraph executive summary (quality-sensitive, low volume). Everything runs on the largest available model and unit cost is 8x budget. The architect needs a change that can ship within days and must not lower summary quality. What should the architect do first?
Build Exercise
Write a Model Selection Dossier
What you'll learn
- How to characterise each pipeline stage by task shape, volume, latency tolerance, and quality bar
- How to assign the smallest model tier that clears each measured bar
- How to compute per-task unit economics for competing designs
- How to design an escalation rule with triggers and expected escalation rate
- How to write a lifecycle plan that keeps model changes eval-gated
- Pick a real or realistic multi-stage Claude pipeline and list each stage with its task shape, volume, latency tolerance, and quality bar
Why: Right-sizing is per stage, not per application. The stage inventory is the raw material for every later decision.
You should see: A table with one row per stage and four constraint columns filled in with real numbers or honest estimates.
- Assign each stage the smallest model tier you believe clears its bar, and record the eval you would run to prove it before shipping
Why: Selection without eval evidence is the planted wrong answer in both directions. The eval is what makes the assignment defensible.
You should see: A tier per stage plus one line each naming the eval set and pass threshold.
- Compute per-task unit cost for the current uniform-model design and the right-sized design at your monthly volume
Why: Cost is price x tokens x volume. Making the arithmetic explicit is what turns a vague saving into a business case.
You should see: Two monthly totals and the percentage difference, with the token assumptions written down.
- Design the escalation rule for the one stage where failure is costly: trigger, escalation target, and expected escalation rate
Why: The cascade is how you keep small-model economics without accepting small-model worst cases.
You should see: One sentence of the form: on [trigger], re-run on [tier]; expected escalation rate [n]%.
- Write the lifecycle note: pinned model IDs, where deprecation notices are monitored, and the eval gate a migration must pass
Why: Model lifecycle is a scheduled event, not a surprise. The note is what stops an alias or provider default silently moving production.
You should see: Three lines: the pinned IDs in use, the monitoring channel, and the migration gate.
Sources
- Building Effective AI Agents — Anthropic
- Models overview — Anthropic
- Choosing the right model — Anthropic
- Pricing — Anthropic
- Model deprecations — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 2 — Anthropic