AnthropicClaude Certified Architect – Professional2026-102.1 Select appropriate Claude models based on trade-offs
Choose tiers with workload measurements
Completed by the knowledge check
Learning objective
Compare current Claude model tiers by capability, modality support, latency, cost, context window, and feature support, and confirm the choice with task-specific evaluations.
Core idea
A model tier is a starting hypothesis for a workload. It becomes a production choice only after its capabilities fit the request and its measured quality, latency, and cost fit the business requirement. A public benchmark cannot establish that your extraction rules or exception policy are handled correctly.
Anthropic offers efficiency-first and capability-first selection. Start efficiency-first for high-volume, straightforward work with tight latency or cost constraints. Start capability-first when reasoning quality is the uncertain requirement, establish a usable baseline, and test whether less expensive configurations preserve it. Neither approach grants a model permanent ownership of the workload. Anthropic names Opus 5.5 as the starting point for most workloads and Fable 5.1 as the step up when evaluations on Opus 5.5 at higher effort still fall short. Tune effort before changing tiers; see 2.1.3.
How it works
Compare the actual lineup
Anthropic’s models overview compares these four models. Prices are base Claude API prices per million input and output tokens; latency labels are relative, not response-time guarantees.
| Model and Claude API ID | Workload starting point | Relative latency | Input / output price |
|---|---|---|---|
Haiku 5.5, claude-haiku-5-5 | High-volume classification, extraction, and routing | Fastest | $0.10 / $0.50 up to 100,000 prompt tokens; $0.50 / $2.50 above that threshold |
Sonnet 5.5, claude-sonnet-5-5 | Everyday coding, analysis, and agentic work | Fast | $2 / $10 |
Opus 5.5, claude-opus-5-5 | Long-running agentic coding and knowledge work | Moderate | $4 / $20 |
Fable 5.1, claude-fable-5-1 | Demanding reasoning and long-horizon agentic work | Slower | $10 / $50 |
All four accept text and images and produce text; all support vision, multilingual work, and tool use. Image input therefore does not, by itself, justify choosing Opus over Haiku. Nor does text output imply native audio or video output. Evaluate the modality the documented interface actually accepts.
All four have a 1M-token context window and a 128K-token maximum synchronous Messages API output. Capacity is an admission constraint, not a promise of equal reasoning quality across a million tokens. A valid request that fits is still a task the candidate must pass. The context window and output ceiling answer different questions: whether the request fits and how much the reply can generate.
Their reasoning controls also differ operationally. All four support adaptive thinking and effort; Opus and Fable have always-on adaptive thinking. Haiku and Opus default to medium effort, while Sonnet and Fable default to high. Compare explicit settings rather than accidentally comparing different defaults; 2.1.3 owns the configuration details.
Check capabilities before ranking quality
On the Claude API, use the Models API to inspect max_input_tokens, max_tokens, and capabilities for the candidate. These identifiers let a model-selection service check documented limits rather than infer them from a name. The response’s line field groups model lines; don’t parse a supposedly permanent list from the id string. Anthropic’s Amazon Bedrock, Google Cloud, and Microsoft Foundry pages each list the Models API as unsupported, so those deployments check limits against their platform’s documentation; see 2.1.4.
A capability flag has a scope. For example, server_tools.web_search.supported means the model accepts at least one web-search tool version, not every version. Organization settings can still prevent its use. Record the specific tool version and deployment platform required by the workload, then test that combination. Platform availability, feature gaps, and residency are deployment filters owned by 2.1.4.
Run a task-specific comparison
Keep the actual prompt, input distribution, tools, and scoring criteria comparable. Include routine cases, edge cases, long inputs, and the hardest tenth separately. A model can win average accuracy while failing the slice that determines financial loss.
Record the model ID, effort setting, accepted-result rate, end-to-end latency distribution, and spend per accepted result. Use response usage for token accounting, but compare completed tasks rather than price per token. Models can consume different numbers of tokens and attempts. A cheaper failed answer followed by an expensive correction can exceed the cost of a stronger first attempt; 1.6.2 owns the whole workflow ledger.
A stronger model is a useful challenger, not the ground truth. Score against verified fields, executable checks, or a business rubric approved by the task owner. Otherwise a weaker candidate can be penalized for correctly disagreeing with the baseline model.
Key distinctions and trade-offs
Capability versus price: A higher tier can reduce retries or failed tasks enough to offset its higher token price. Conversely, unused capability adds expense without improving the accepted outcome.
Relative speed versus service latency: The lineup’s speed labels omit your prompt length, output length, tool delays, and thinking effort. Measure the finished workflow against its latency target, rather than converting “fastest” into an invented SLA.
Limits versus feature support: Sharing a 1M window says nothing about whether the required tool or output mode works on the selected platform. Keep the request shape in the comparison, not merely the model string.
Quality floor versus average score: Treat a hard business requirement as a rejection criterion. An inexpensive candidate that misses it is not a saving waiting for finance approval.
Architecture / decision scenario
A retailer processes 80,000 photographed delivery receipts daily. Finance requires at least 99% exact totals overall and 97% on damaged receipts, with a five-second p95 completion target. The operations lead proposes Opus for every receipt because errors create disputes; finance proposes Haiku because of volume.
In a hypothetical evaluation using verified receipts and the same extraction prompt, Haiku 5.5 meets 99.3% overall, 97.4% on damaged receipts, and a 2.1-second p95. Sonnet reaches 99.5%, 97.8%, and 3.2 seconds. Opus reaches 99.6%, 98.0%, and 6.4 seconds. These are scenario measurements, not vendor performance claims.
The architect selects Haiku for this route: all candidates read images and fit the inputs, Haiku passes both quality floors, and Opus misses the deadline. Sonnet’s incremental accuracy does not justify its measured accepted-result cost under the stated requirements. The receipt-service owner retains the damaged-receipt slice and reruns it before model or prompt changes. If dispute costs alter the acceptance floor, the selection is reopened rather than defended by the original price table.
Common exam traps
- Choosing the highest tier without measuring the workload’s acceptance requirements.
- Assuming Haiku 5.5 has Haiku 4.5’s context or reasoning restrictions.
- Treating image support as a feature exclusive to a high tier.
- Comparing token prices while ignoring prompt-length pricing, retries, and successful outcomes.
- Treating relative latency labels or context capacity as quality guarantees.
- Accepting a model-generated baseline as verified ground truth.
What to remember
Filter candidates by actual capabilities and limits, then compare them with your prompts and data. Choose the configuration that satisfies the workload’s quality and latency requirements at an acceptable cost per accepted result. Preserve the hard slices and explicit settings that made the choice defensible.
Knowledge check
An insurer routes 50,000 inbound claim emails a day into categories. The routing owner requires at least 98% correct routing on a verified holdout set, at least 95% on its multilingual slice, and a three-second p95. A replay with the same prompt and explicit effort settings measured:
- Haiku 5.5: 98.4% overall, 95.6% multilingual, 1.2-second p95, $0.0004 per accepted result
- Sonnet 5.5: 98.9% overall, 96.8% multilingual, 2.6-second p95, $0.006 per accepted result
- Opus 5.5: 99.1% overall, 97.2% multilingual, 4.1-second p95, $0.012 per accepted result
Which configuration meets every requirement at the lowest cost per accepted result?
A legal-operations team is choosing between Haiku 5.5 and Sonnet 5.5 for extracting renewal dates from contracts. To save labeling effort, the evaluation plan scores each candidate by its agreement with Opus 5.5’s extractions from the same contracts. What should change before the comparison decides the model?
max effort before scoringOn the Claude API, a model-selection service reads the Models API and finds server_tools.web_search.supported: true for a candidate model. The research workflow depends on one specific web-search tool version. What does the flag establish?
A team compares Haiku 5.5 and Sonnet 5.5 for drafting warranty-claim replies. A draft that fails review is regenerated, and some claims need several attempts before a draft passes. Finance wants the configuration with the lowest cost for the work actually delivered. Which figure should decide the comparison?
usage token count per request for each modelReferences
- Anthropic, Models overview
- Anthropic, Choosing the right model
- Anthropic, Claude in Amazon Bedrock
- Anthropic, Claude on Google Cloud
- Anthropic, Claude in Microsoft Foundry
- Anthropic, Claude Haiku 5.5
- Anthropic, Optimizing for cost and intelligence