CCDV-F 5.3 — Choosing a model

Which model does this workload need?

What is the binding constraint?

Latency or unit cost
Haikureal-time, high-volume, simple tasks
Everyday build work
Sonnetcoding, analysis, content, vision
Hard, agentic, costly to get wrong
Opuslong autonomous runs, refactors
Already on the right model
Tune effortoften the better lever

Start from the binding constraint. Most applications end up using more than one model, chosen per task rather than per project.

The families, and what each is for

Anthropic's naming has been stable in intent for a long time: Opus is the most capable family, Sonnet the balanced one, Haiku the fastest and cheapest. The documentation's own framing is that Opus suits complex agentic coding, long autonomous sessions and enterprise work; Sonnet suits everyday coding, data analysis, content and visual understanding; Haiku suits real-time applications, high-volume processing and cost-sensitive deployments.

Model	Input / output per million tokens	Context	Thinking
Claude Fable 5.1	$10 / $50	1M	Adaptive, always on
Claude Opus 5.5	$4 / $20	1M	Adaptive, always on
Claude Sonnet 5	$2 / $10	1M	Adaptive
Claude Haiku 4.5	$1 / $5	200K	Extended

Read that table as ratios rather than as figures to memorise: the gap between the cheapest and most expensive listed model is an order of magnitude per token, and output costs several times what input costs on every one of them. A workload that is mostly long prompts and short answers has a very different economics from one that generates long documents, and that difference often matters more than the model choice itself.

Quality, latency and cost are one dial with several settings

The documentation frames the choice on four criteria — capabilities, speed, cost, and effort — and is explicit that effort is often the better lever: it trades intelligence against latency and cost within a single model, without a migration. Effort levels run from low through medium and high to higher settings still, and the sensible default differs per model, so an effort value carried over from one model is not automatically right on the next.

Two ways to arrive at the right model

Efficiency-first

Start on the fastest, cheapest model
Test thoroughly against real inputs
Upgrade only where quality actually fails
Suits prototyping, high volume, tight latency

Capability-first

Start on a frontier model
Get the prompt and evals right first
Then tune effort down, or move down a tier
Suits accuracy-critical and agentic work

Both are documented starting points. The choice between them is about what failure costs you during development.

Both routes converge on the same instruction, and it is the step teams skip: build benchmark tests on your own prompts and your own data, then compare models on accuracy, quality and edge-case handling before weighing cost. A model comparison without an eval set is a preference, not a decision. Evaluation itself belongs to Domain 4.

Nor is the choice one model per application. The documentation describes pairing a cheaper model with a frontier one: an executor that escalates the hard decisions to an advisor, or an orchestrator that delegates bulk work to cheaper workers. Most production systems end up here, because most workloads are a small number of hard steps surrounded by a large number of easy ones.

Worked example · A retailer's returns triage, costed properly

An online retailer processes about 40,000 return requests a month. Each one needs a category, a refund decision and a short note to the customer. The first build sends every request to a frontier model with default settings, and the monthly bill lands badly.

Separate the steps. Categorising a return is a short, highly patterned classification. Deciding an out-of-policy refund is a judgement call with money attached. They are not the same task.
Measure before moving. Two hundred labelled requests become an eval set. The fastest model matches the frontier model on categorisation, and is clearly weaker on the contested refund cases.
Route accordingly. Haiku categorises everything; roughly one request in twelve is escalated to a more capable model for the refund decision.
Tune effort, not model, on the escalations. A lower effort level is tested on the escalated path and re-run against the eval set; quality holds, so it stays.
Recheck the latency story. Customers now see the acknowledgement in under a second, because the common path never touches the slower model.

Takeaway: The saving came from splitting one task into two with different constraints — not from finding one model that was cheap and clever at once. Route by task, and let the eval set decide each route.

Breaking behaviour changes across releases

This is the half of the objective people do not prepare for. A new model is not a drop-in faster version of the last one. Anthropic publishes migration guides precisely because upgrades change API contracts and behaviour, and the changes documented for recent Opus releases are a good map of the kinds of thing to expect.

Kind of change	Concrete example from the migration guide	What it breaks
Parameters rejected	`temperature`, `top_p` and `top_k` with non-default values return `400`	Any code carrying sampling settings forward
Thinking mode replaced	Manual `budget_tokens` rejected; adaptive thinking plus `effort` instead	Requests built for extended thinking
Defaults inverted	Thinking on by default, so `max_tokens` now bounds thinking plus text	Output budgets tuned on the previous model
Response shape	Thinking blocks arrive before text blocks	`content[0].text` and positional stream handling
Features withdrawn	Assistant-message prefill returns `400`	Prompts that steered the opening of a reply
Tokenizer changed	The same text can cost noticeably more tokens	Cost models and `max_tokens` arithmetic
Style and behaviour	Longer answers, more literal instruction-following, more self-verification	Prompts tuned against the old model's habits

Notice the last row. Nothing in it returns an error; the application keeps working and quietly produces different output. A model that follows instructions more literally will stop doing the helpful generalisation your prompt relied on. A model that verifies its own work will over-verify if you left in “double-check your work”. This is why a model upgrade is a release that needs evals re-run, not a configuration edit.

A model-upgrade checklist

Passes: Model id read from configuration, not hard-codedMakes the change, and the rollback, a deploy setting
Fails: Deprecated sampling parameters removedNon-default temperature, top_p, top_k now return 400
Fails: Thinking configured for the new modebudget_tokens replaced by adaptive thinking plus effort
Fails: Responses parsed by block type, never by positionThinking blocks may precede text blocks
Check: max_tokens re-checked against the new defaultsThinking may now count inside the same budget
Check: Token counts and cost re-baselinedTokenizer changes shift both
Missing: Eval set re-run and prompts re-tunedLength, tone and verification habits change silently

The first four items are API contract; the last three are behaviour. Only the first four will tell you they are wrong.

Worked example · The upgrade that broke a working integration

A bank's internal summariser is switched to a newer model on a Friday. Nothing errors in staging. On Monday, half the summaries are empty strings and the rest are twice as long as the template allows.

The empty strings. The formatter read response.content[0].text. On the new model the first block is a thinking block, so position zero has no text at all.
The fix. Select blocks by type and concatenate the text blocks — the pattern the migration guide gives explicitly.
The long summaries. Nothing broke here; the new model simply writes at greater length by default, and no instruction in the prompt constrained it.
The second fix. The system prompt now states the length limit in words, and the eval set checks it. Lowering effort was tried first and did not help, because effort reduces reasoning, not visible answer length.
The process change. Model ids move to configuration, and an upgrade now requires the eval suite to be re-run before the change reaches production.

Takeaway: One failure was a contract change that a type-safe parse would have survived; the other was a behavioural change no exception would ever have reported. Plan for both.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Defaulting every call to the most capable model	Route by task; escalate only the steps that need it.
Switching model to fix a quality problem with a known cause	Fix the prompt, the examples or the validation first; tune `effort` before changing tier.
Comparing models by impression instead of an eval set	Build benchmark tests on your own prompts and data, then compare on accuracy and edge cases.
Treating a model upgrade as a configuration change	Re-run evals and re-tune prompts; behaviour changes without raising errors.
Carrying sampling parameters and effort values across a migration	Read the migration guide; deprecated parameters now fail and defaults are recalibrated.

You should now be able to

Match Opus, Sonnet and Haiku to workloads from stated latency, cost and quality constraints.
Use effort and adaptive thinking as a within-model lever before changing model.
Design a multi-model routing strategy that escalates only the hard steps.
Anticipate the breaking API changes a model migration brings, and parse responses defensively.
Recognise silent behavioural changes across releases and plan an eval-backed upgrade.

Choosing a model