CCAR-P 2.1 — Choosing a Claude model

How an architect arrives at a model

Define the barquality, latency, cost per task
Build a small evalreal prompts and real data
Test candidatescompare models on the same eval
Tune effortbefore moving up or down a tier

Re-run when volumes, prompts or the model line-up change

Selection is an experiment, not a lookup. Notice that tuning effort comes before switching models — it is the cheaper lever.

The current line-up and what separates it

Anthropic’s models overview lists four generally available models at the time of writing. They differ on four axes an architect has to weigh together: capability, speed, price and features such as context size and how the model thinks.

Model (API id)	Input / output per MTok	Context · max output	Positioned for
Claude Fable 5.1 (`claude-fable-5-1`)	$10 / $50	1M · 128K	Hardest reasoning, multi-hour agent sessions; thinking always on
Claude Opus 5 (`claude-opus-5`)	$5 / $25	1M · 128K	Complex agentic coding and enterprise work; the docs’ default starting point
Claude Sonnet 5 (`claude-sonnet-5`)	$2 / $10	1M · 128K	Best balance of speed and intelligence
Claude Haiku 4.5 (`claude-haiku-4-5-20251001`)	$1 / $5	200K · 64K	Fastest and cheapest; real-time and high-volume work

Two details in that table change designs. First, Haiku 4.5 has a 200K window while the others have 1M — a long-document workload can rule it out on context alone. Second, the pricing page says models from Claude 4.6 onward charge no long-context surcharge: a 900K-token request costs the same per token as a 9K one. The cost of a big context is volume, not a premium rate (context budgeting is covered in 2.4).

Two starting strategies

The choosing-a-model guide describes two honest ways to begin. Efficiency-first: start with the small, fast model (Haiku 4.5) and move up only where evals show it falling short. This suits high-volume, straightforward, latency-sensitive or cost-sensitive work. Capability-first: start with a frontier model (the docs name Opus 5) to learn what “good” looks like, then try cheaper models against that bar. This suits complex reasoning, nuanced judgement and autonomous agentic work where accuracy matters more than cost.

Which model do I start with?

What dominates this workload?

Tight latency, huge volume
Haiku 4.5move up only if evals fail
Balanced everyday work
Sonnet 5tune effort for cost
Complex agentic or enterprise
Opus 5the docs’ default start
Evals still fail at high effort
Fable 5.1deepest reasoning, highest cost

A starting point, not a verdict. Every branch still ends in an eval against your own data.

Effort: the lever inside a model

Before swapping models, look at effort. On current models output_config.effort takes low, medium, high (the default), xhigh or max, and it governs every output token — text, tool calls and thinking. Lower effort means fewer, terser tool calls and less or no thinking; higher effort means more planning and more thorough answers. The choosing-a-model guide advises tuning effort before switching models, and the models overview says to reach for Fable 5.1 when Opus 5 at higher effort still falls short.

Thinking has changed shape too. Current models use adaptive thinking (thinking: {"type": "adaptive"}), where Claude decides whether and how much to think, steered by effort. The older manual mode with budget_tokens is rejected on Claude 4.7 and later, and is still the only option on Haiku 4.5. Opus 5 turns adaptive thinking on by default, so expect more output tokens per request than an Opus 4.8 baseline. Thinking tokens are billed as output whether or not you display them.

Same model, two effort settings for two kinds of workpython

import anthropic

client = anthropic.Anthropic()

def classify(ticket: str):
    # Short, well-defined task: cheaper, faster answers
    return client.messages.create(
        model="claude-sonnet-5",
        max_tokens=512,
        output_config={"effort": "low"},
        messages=[{"role": "user", "content": ticket}],
    )

def investigate(incident: str):
    # Hard, multi-step analysis: let the model think more
    return client.messages.create(
        model="claude-sonnet-5",
        max_tokens=16000,
        thinking={"type": "adaptive"},
        output_config={"effort": "xhigh"},
        messages=[{"role": "user", "content": incident}],
    )

Lever	What it changes	When to pull it
Model tier	Underlying capability, price per token, context size	Evals fail even at high effort, or a feature is missing
Effort	How many tokens the model spends thinking, calling tools and explaining	Quality is close but cost or latency is off
Fast mode (Opus 5, research preview)	Up to 2.5× output speed at premium prices; no change in intelligence	Long streamed outputs where throughput, not first-token time, is the pain
Batch API	50% off input and output; asynchronous	Work that can wait — nightly reports, backfills

Mixing models in one system

Enterprise systems rarely run one model. The choosing-a-model guide describes pairing a lower-cost model with a frontier one: an executor handles the routine path and escalates hard decisions to a stronger advisor, or an orchestrator delegates bulk work to cheaper workers. The architect’s job is to draw the line — which requests are routine — and to prove it with evals on each path (orchestration patterns are covered in 1.4).

Worked example · A retailer’s support assistant

A retailer handles 400,000 support messages a month. Most are order-status and returns questions; about 3% are disputes needing policy judgement. The business wants replies in under two seconds and a budget cap.

Define the bar. Routine answers must match policy and cite the order; disputes must apply the refund policy correctly. Latency target is for routine traffic only.
Efficiency-first for the bulk. An eval of 300 real routine messages shows Haiku 4.5 meets the bar. It is the fastest and cheapest model, so it takes the routine path.
Capability-first for the hard slice. On 100 historical disputes Haiku misapplies an exception clause; Sonnet 5 at medium effort gets them right. Disputes route there, where a few extra seconds are acceptable.
Offload what can wait. The nightly summary of complaint themes goes to the Batch API at half price.
Re-test on change. When a new model ships, the same eval set decides whether to switch — not the launch post.

Takeaway: Two models, one batch job and an eval set beat “use the best model” on cost and latency, without giving up quality where it matters.

Worked example · A law firm’s due-diligence agent

A law firm wants an agent that reads a 600-page data room, cross-references contracts and drafts an issues list overnight. Accuracy matters far more than speed.

Context rules one model out. The data room runs to several hundred thousand tokens; Haiku 4.5’s 200K window cannot hold it in one pass, while the 1M-window models can.
Start capability-first. Opus 5 at high effort produces a good issues list but misses two subtle cross-references in the eval set.
Pull the cheaper lever first. Raising effort to xhigh catches one of the two. The team sets a large max_tokens, as the effort docs recommend for high effort levels.
Escalate only on evidence. Fable 5.1 catches both at twice the per-token price. Because the job runs overnight at modest volume, the firm accepts the cost — and records the eval that justified it.

Takeaway: Context size and the quality bar drove the choice; the price difference was justified by a measured failure, not by prestige.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Defaulting every request to the most capable model	Match each workload slice to the smallest model that passes its eval.
Choosing the cheapest model because the volume is high	Check the quality bar first; route the hard minority to a stronger model.
Switching tiers as the first response to a cost or quality problem	Tune effort (and batching for async work) before changing models.
Picking a model from benchmarks or launch posts	Run the candidates on your own prompts and data and compare.
Ignoring context and feature limits	Check window size, max output and thinking mode against the workload before comparing price.

You should now be able to

Compare Claude models on capability, latency, price, context window and thinking mode.
Choose between efficiency-first and capability-first starting strategies for a workload.
Use effort as the first lever for cost, latency and quality before changing model tier.
Design a multi-model system that routes routine and hard work to different models.
Justify a model choice with an eval on representative data rather than reputation.

Choosing a Claude model