On this page
TLDR
Match the model tier to the task, not the other way round: Haiku for high-volume, straightforward work at the lowest cost/latency; Sonnet for the best speed/intelligence balance; Opus for complex, long-horizon agentic work; Fable as the highest-capability, slowest tier for work none of the other three can cover. Tune the effort parameter before switching tiers, and never assume a newer release is a drop-in swap - migrations carry breaking changes.
What you are deciding
Choose the model tier by measuring quality, latency and cost on your own task, then take the cheapest option that clears your quality bar. A default to the biggest or the cheapest tier is a guess.
Which model tier is the cheapest one that clears this task's quality bar, and how do I know?
What it is
Model selection is the API-level decision of which model ID to send to POST /v1/messages, balancing three axes: capability, latency, and cost per token. The production tiers are Opus (claude-opus-4-8) for complex agentic coding and enterprise work, Sonnet (claude-sonnet-5) for the best speed/intelligence balance, Haiku (claude-haiku-4-5) as the fastest, cheapest tier with near-frontier reasoning, and Fable 5 as the highest-capability, slower tier. Since Claude 4.6, model IDs are dateless but still pinned snapshots - not evergreen pointers, so a deployed app never silently changes model behavior underneath it.
Anthropic's recommended selection method is benchmark evals on your actual prompts and data, not intuition - start at the cheapest tier that plausibly covers the task, and upgrade only on a measured capability gap. Capabilities and token limits are also queryable programmatically via the Models API (max_input_tokens, max_tokens, capabilities), so a system can select or validate a model choice at run time rather than hard-coding assumptions.
How each certification frames it
CCA-P: The architect view: defend the trade-off
CCARP-D2-O1Select appropriate Claude models based on trade-offs
The Professional objective is to select appropriate Claude models based on trade-offs (PDF page 4, Domain 2). An architect justifies the choice against requirements and SLAs, and states what evidence would change it.
Expect to defend a mixed design, for example a fast tier for high-volume routing and a stronger tier for the hard minority, rather than one model for everything.
CCD-F: The developer view: measure and implement
CCDVF-D5-O3Model Selection and Tradeoffs: Claude model capabilities (Opus vs. Sonnet vs. Haiku use cases, adaptive thinking support), tradeoffs across quality/latency/cost parameters, and breaking behavior changes across model releases when selecting models for tasks
The Developer guide covers Opus, Sonnet and Haiku use cases, adaptive thinking support, quality, latency and cost trade-offs, and breaking behavior changes across model releases (PDF page 7, Domain 5).
The developer builds the evaluation, pins the model identifier, and re-runs the evaluation when a model changes. Anthropic documents that every Claude model ID is a pinned snapshot.
CCA-A: The associate view: match the tier to the task
CCAOF-D3-O2Differentiate between Claude model types (Haiku, Sonnet, Opus)CCAOF-D3-O3Align model selection with task requirements (cost, speed, quality)
The Associate guide asks candidates to differentiate Haiku, Sonnet and Opus and to align model selection with cost, speed and quality requirements (PDF page 5, Domain 3).
Without writing code, the associate reads a task description, decides how much depth it needs, and chooses the lighter tier for quick, repetitive work and the stronger tier for complex, high-stakes work.
How it works
Pricing and context. Per MTok (input/output): Opus 4.8 = $5/$25, Sonnet 5 = $3/$15 ($2/$10 introductory through 2026-08-31), Haiku 4.5 = $1/$5, Fable 5 = $10/$50. Context and output ceilings split the same way: Opus 4.8, Sonnet 5, and Fable 5 support a 1M-token context window with 128k max output; Haiku 4.5 is scoped to 200k context and 64k max output.
Latency ranks in the same order as capability, inverted: Haiku is fastest, then Sonnet, then Opus, then Fable slowest. This is the core tradeoff triangle the exam tests - you cannot maximize capability, latency, and cost simultaneously, so the architecture has to state which two matter more for the task at hand.
Adaptive thinking (thinking: {type: "adaptive"}) is supported on Opus 4.8, Sonnet 5, and Fable 5 (always-on on Fable); Haiku 4.5 does not support adaptive thinking, but supports extended thinking as an alternative. A task that genuinely needs adaptive thinking cannot be served by the cheapest tier - Sonnet 5 becomes the cheapest tier that qualifies.
The `effort` parameter (output_config.effort) trades intelligence for latency/cost within one model, and is often a better lever than switching tiers entirely. It defaults to high on Opus 4.8 and Sonnet 5; xhigh is recommended for most coding and agentic work. Tuning effort up or down inside a single model is cheaper to reason about and re-test than a full model migration.
Migrations are not drop-in swaps. Moving to Opus 4.7+, Sonnet 5, or Fable 5 removes manual extended thinking (thinking: {type: "enabled", budget_tokens: N} now returns a 400 - use adaptive thinking instead), rejects temperature/top_p/top_k sampling parameters, and 400s on assistant-turn prefills. Sonnet 5 also defaults adaptive thinking ON when thinking is omitted (Sonnet 4.6 ran thinking-off by default), and its newer tokenizer produces roughly 30% more tokens for identical text - shifting cost baselines even when the prompt hasn't changed. A separate research-preview fast mode gives up to 2.5x output speed at premium pricing on Opus 4.8/4.7 (Opus 4.7 fast mode is deprecated, removal 2026-07-24).
Worked example: choosing a tier for ticket routing
Authored teaching example, not a bank question.
A team routes incoming support tickets into categories. They are tempted to use the largest model because it is the most capable.
| Tier (as read on 2026-10-16) | Official positioning | What you measure on your task |
|---|---|---|
| Smallest tier | High-volume, latency-sensitive work such as classification, extraction and routing | Accuracy on labelled tickets, latency, cost per thousand |
| Middle tier | The best combination of speed and intelligence | The same three measures on the same set |
| Largest tier | Long-running agentic coding and knowledge work | The same three measures, only for the hard minority |
The decision is backed by a table the team can show, not by a habit. Check afterwards that the table has a row per candidate with measured values, and that the tier descriptions were read from the current models overview, not remembered.
How this decision goes wrong
Highest-tier default
Looks right: The most capable model cannot be wrong, so use it everywhere.
Why it fails: You pay more and wait longer for capability the task does not need, and you never learn whether a cheaper tier would have passed.
Instead: Set the quality bar, test the lighter tier first, and move up only where it fails.
Cheapest model without evaluation
Looks right: The task seems simple, so the smallest tier is fine.
Why it fails: Without a labelled set you cannot see the errors it makes, and rework can cost more than the saving.
Instead: Run the candidate on a labelled sample and compare against the bar before shipping.
Undated model claims
Looks right: A remembered statement such as 'tier X is the fastest' is used in a design document.
Why it fails: Lineups, prices and retirement dates change. Anthropic documents retirement commitments per model, so an undated claim can be stale.
Instead: Cite the models overview with its read date, pin the model identifier, and re-check on each release.
Where you'll see it
High-volume support classification
Haiku 4.5, often paired with the Batch API, for the lowest cost/latency on a straightforward, high-throughput task.
Long-horizon autonomous coding agent
Opus 4.8 at high or xhigh effort during development; downgraded toward Sonnet or a lower effort setting once the workflow is proven stable, to control ongoing cost.
Side-by-side
| Model | Best for | Price (in/out per MTok) | Context / max output | Adaptive thinking |
|---|---|---|---|---|
| Haiku 4.5 | High-volume, straightforward tasks - fastest, cheapest | $1 / $5 | 200k / 64k | No (extended thinking instead) |
| Sonnet 5 | Best speed/intelligence balance - default workhorse | $3 / $15 ($2/$10 intro thru 2026-08-31) | 1M / 128k | Yes (default ON) |
| Opus 4.8 | Complex, long-horizon agentic and coding work | $5 / $25 | 1M / 128k | Yes |
| Fable 5 | Highest-capability tier, slower | $10 / $50 | 1M / 128k | Yes (always-on) |
Decision tree
Is the task high-volume and straightforward (classification, extraction, simple chat)?
Is quality or latency underperforming inside the model already selected?
effort (e.g. raise to xhigh) before switching tiers - usually cheaper than a model upgrade.Is the task a multi-hour autonomous agentic or coding workload?
Does the task still underperform at Opus 4.8, high/xhigh effort, with adaptive thinking on?
Are you adopting a newer model release on an existing integration?
How each cert tests this
CCA-P
Practitioner (D2 · Models, Prompting & Context Engineering): tests selecting a model for a client's task against stated tradeoffs - justifying the choice in business terms (cost, SLA impact), not just raw capability.
CCA-A
Associate (D3 · Product & Model Selection): tests differentiating Haiku/Sonnet/Opus/Fable use cases in plain terms and aligning selection to task requirements (cost, speed, quality) without needing the API-level detail.
CCD-F
Developer (D5 · Model Selection & Optimization): tests the deepest technical layer - capabilities, adaptive thinking support, quality/latency/cost parameter tradeoffs, and breaking behavior changes across releases at the API-call level.
The exam trap
Assuming a newer model release is a pure drop-in swap, or reaching for a larger model "for quality" before tuning effort within the current tier. Both skip the cheaper lever (effort tuning, or a proper migration check) in favor of the more expensive one (a tier upgrade, or an untested release swap).
Question patterns
CCD-F practice questions
5 approved CCD-F questions for this topic. Tap an answer to check it, then read the rationale for every option.
A team is asked to build a system that only ever routes tickets to 3 known categories, but they build it as a fully autonomous agent with its own tool-selection loop "so it's more flexible for the future." Six months later, debugging a misrouted ticket requires tracing an unpredictable sequence of tool calls instead of a fixed decision. What is the architectural mistake?
CCA-P practice questions
1 approved CCA-P question for this topic. Tap an answer to check it, then read the rationale for every option.
A platform team pins a Claude 4.6-or-later model ID in production. What behavior should the team expect from that identifier?
CCA-A practice questions
No approved public CCA-A sample question is published for this topic yet. The worked example above is an authored teaching example.
Frequently asked
Showing 4 of 4 questions
effort parameter within a model before upgrading to a larger, pricier tier.Sources and next steps
- Claude Certified Architect - Professional Exam Guide v1.0 (July 2026), PDF page 4, section: Domain 2: Claude Models, Prompting & Context Engineering, detailed objectives. Checked 2026-10-16.
- Claude Certified Developer - Foundations Exam Guide v1.0 (July 2026), PDF page 7, section: Domain 5: Model Selection and Optimization (Model Selection and Tradeoffs, Cost and Token Management). Checked 2026-10-16.
- Claude Certified Associate - Foundations Exam Guide v1.0 (July 2026), PDF page 5, section: Domains 3, 5 and 6, detailed objectives. Checked 2026-10-16.
- Models overview (Claude API docs), section: Compare models; notes on Claude API ID and Retirement. Checked 2026-10-16.
- Create strong empirical evaluations (Claude API docs), section: Building evals and test cases: success criteria; eval design principles. Checked 2026-10-16.
CCD-F exam guide: Domain 5, Model Selection and Optimization