Selecting Claude Models on Trade-Offs

What You Need to Know

Model selection means choosing which Claude model runs each task in a system.

This lesson uses one made-up example throughout: the customer service department of a car manufacturer. It has three Claude stages. The first sorts thousands of messages from car owners each week by topic. The second drafts replies. The third writes the weekly summary for the head of customer service. Each stage has its own volume, latency budget and quality bar.

A task's quality bar is the standard that its output must reach. An eval checks the quality bar on representative data, such as past messages from car owners. The latency budget is how long the next step can wait. The question is never "which model is best". The question is "which model clears this task's quality bar at the lowest cost that meets the latency budget".

Model Selection Is Constraint Satisfaction

Five factors decide the choice:

1. Capability: does the model reach the task's quality bar? You measure the bar. You do not assume it (Domain 4 covers how to measure it).
2. Latency: time-to-first-token is the wait before the first part of a response arrives. Throughput is how fast the output arrives after that. Both accumulate across chained calls and agent loops, where an agent calls the model many times in sequence. Each call waits for the call before it. So a per-call latency that looks acceptable for one call alone multiplies along the hot path (that chain of calls).
3. Cost: price × tokens × volume. Calculate the unit economics (what one task costs) for each task, not the list price per token. The car manufacturer's sorting stage runs at the highest volume, so this factor matters most for that stage.
4. Context window and output limits: these are hard constraints on long-document and generation-heavy work.
5. Lifecycle and platform availability: model availability differs across the Claude API, Amazon Bedrock, Claude Models on Google Cloud (Google managed) and Microsoft Foundry. The partner-operated platforms, Bedrock and Google Cloud (Google managed), set their own retirement schedules. In enterprise designs, platform availability and retirement schedules are compliance and procurement constraints.

Constraints exclude candidate models before preference has an effect. Capture the constraints first. Then the constraints largely decide the selection.

The Model Tiers

As of November 2026, the lineup has four tiers:

• a frontier tier for the hardest reasoning and long-running agents (Claude Fable 5.2)
• 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 model selection is constraint satisfaction (finding the model that meets the constraints), not reading a leaderboard.

Right-Sizing, Per Stage

Anthropic documents two starting points. Efficiency-first starts with Haiku 5.5 and tests it thoroughly. It upgrades only where a capability gap is measured. Capability-first starts with Opus 5.5. As the workflow is optimised, it then lowers the effort setting (explained below) or moves to smaller models. Either way, benchmark tests on representative data decide whether a model reaches the bar.

Right-size the model (choose the smallest model that reaches the bar) for each pipeline stage, not for the whole application. A system that uses one model everywhere pays the highest prices on easy stages. A pipeline can run Haiku-class models for classification and routing and Sonnet-class models for drafting. Keep Opus-class models for the one synthesis step that measurably needs them, such as the weekly summary for the head of customer service. The smallest model that reaches each stage's measured bar is the way to reduce cost with zero architectural cost. Only the model of each stage changes.

Before you switch tiers, try the effort parameter on current models. It lets you choose between more intelligence and lower latency and cost within one model. Anthropic's model-choice guidance notes that tuning effort is often a better option than switching models. If the car manufacturer's reply drafts are slow, check the effort setting first.

Escalation Cascades

An escalation cascade sends each request to the small model by default. It escalates a request to the larger tier on low confidence, failed validation or an explicit trigger. Most requests never escalate. So the cascade gives quality near that of the big model, at an average cost near that of the small model. At the car manufacturer, the sorting stage escalates low-confidence messages. Anthropic's agent guidance documents the underlying pattern as routing. Easy or common requests go to smaller models, and hard or unusual requests go to a more capable tier.

Anthropic's cost guidance says to tune the single model first, by trying it at different effort levels. Add a second model only if the pair gets a better score for its spend than the single model does at any effort level.

Lifecycle Discipline

Every Claude model ID is a pinned snapshot. From the Claude 4.6 generation onwards, even dateless IDs are pinned snapshots, not pointers that move to newer versions. 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 you migrate. A model change is an architecture change. Never let an alias (a model name that can move to a newer version) or a provider default silently change the production model. The car manufacturer's sorting stage changes to a new model only after its eval passes.

In the exam

Every question on this objective tests whether you select on measured constraints or on prestige. It also tests whether you demand eval evidence before moving in either direction. The questions test the reasoning, not price recall: the smallest model that reaches the measured bar, and escalation where needed. The escalation cascade is repeatedly the right answer in cost-versus-quality questions 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

Practice Scenario

Build Exercise

Sources

• Building Effective AI Agents — Anthropic
• Models overview — Anthropic
• Choosing the right model — Anthropic
• Optimizing for cost and intelligence — Anthropic
• Effort — Anthropic
• Pricing — Anthropic
• Model deprecations — Anthropic
• Claude Certified Architect Professional Exam Guide (v1.0) — Domain 2 — Anthropic