Model Selection and Trade-offs

What You Need to Know

Claude models come in families, or tiers: Haiku, Sonnet, Opus and a frontier model. Effort is a request setting that trades intelligence for latency and cost within one model. Adaptive thinking lets a model set its own reasoning depth. An eval is a set of your own tasks, each with a check.

A lettings agency runs two Claude jobs. One answers tenant messages in its website chat, hundreds a day, where tenants expect a quick reply. The other compares check-out reports with check-in inventories and proposes deposit deductions, where a wrong deduction means a dispute.

The Ordering Is Durable, the Line-Up Is Not

The order of the families and the method for choosing between them survive every release. The line-up, the model IDs and the prices do not. The order is stated first-party and worth memorising. As of 14 October 2026 the cost guidance lists the current models from lowest to highest cost and capability. Its order is Claude Haiku 5.5, Claude Sonnet 5.5, Claude Opus 5.5, and Claude Fable 5.1 (the frontier model). A month earlier it began with Claude Haiku 4.5 and Claude Sonnet 5. So learn the family order, not the version numbers.

Comparative latency runs the other way, from Fastest at Haiku 5.5, through Fast and Moderate, to Slower at the frontier. So quality, latency and cost are not independent. Moving up the order buys capability and spends both money and time.

Haiku is for "The lowest latency and price": real-time applications, high-volume intelligent processing and sub-agent tasks. Sonnet is "The best combination of speed and intelligence", for code generation, data analysis and agentic tool use. Opus is for "Complex agentic coding and enterprise work", for multihour autonomous coding agents and large-scale refactoring. The frontier tier is for long-running agents, deep reasoning and long-horizon agentic tasks.

The guide names adaptive thinking support in its scope because support was not uniform when it was written. Claude Haiku 4.5, the fastest model then, rejects adaptive thinking and supports only the older extended thinking form. It has no effort parameter and no interleaved thinking either. As of 14 October 2026 every model in the current line-up has adaptive thinking. It is always on in Claude Fable 5.1 (the frontier model) and Claude Opus 5.5, and Claude Sonnet 5.5 and Claude Haiku 5.5 support it too. Haiku 4.5 is now a legacy model, still available. So check thinking support for the exact model you pin, not the family. A design that needs the model to set its own reasoning depth, or to reason between tool calls, rules out Haiku 4.5 before cost comes up. If the agency's deposit agent must reason between tool calls, Haiku 5.5 can and Haiku 4.5 cannot.

Current state (checked 14 October 2026): the guide's "adaptive thinking support" dates from a line-up in which the fastest model, Claude Haiku 4.5, lacked it. The Models overview now shows adaptive thinking on all four current models. On the exam, treat adaptive thinking support as something that varies by model, and check the model a question names.

Selection Is Constraint-Matching

The documentation names four criteria: Capabilities ("What specific features or capabilities will you need"), Speed ("How quickly does the model need to respond"), Cost ("What's your budget") and Effort. Candidates skip the fourth. Effort is a lever inside one model, not a choice between models. In the documentation's words, "Several Claude models support an effort parameter that trades intelligence for latency and cost within a single model". It adds: "Tuning effort is often a better lever than switching models".

Because tuning effort is often the better lever, it comes first. A workload that costs too much at the default gets an effort sweep before a tier change. One that answers shallowly gets an effort increase before an escalation. If the agency's deposit proposals miss damage, it raises effort before moving up a tier.

There are two documented starting strategies. Efficiency-first begins with the fastest tier, tests thoroughly, and upgrades "only if necessary for specific capability gaps". It is documented for initial prototyping, tight latency requirements, cost-sensitive implementations and high-volume straightforward tasks. Capability-first begins with "the strongest starting point for your task" and optimises the prompt for it. It then considers "increasing efficiency by lowering effort or downgrading models over time". That starting point is not automatically the most capable model. As of September 2026 the page names Claude Opus 5.5, moving to Claude Fable 5.1 only if evals at xhigh or max effort still fall short. Capability-first is documented as best for complex reasoning, tasks that need subtle understanding, and applications where accuracy outweighs cost.

Neither is a default; the stated constraint picks one. The agency's chat job, with its latency bar and volume, starts efficiency-first. The deposit job, where accuracy outweighs cost, starts capability-first.

Then compare on the right unit and sample. The unit is cost per completed task, because "You pay for completed tasks". A more capable model finishes a task with less work: "fewer turns, less searching, less re-reading of its own context, and less backtracking". The sample is the tail, not the median: the hardest tenth of your tasks. On the typical task every model looks similar and the cheapest looks best. The bill is decided by the tasks the cheaper model fails. A failed task still bills its tokens, then the retry, then whatever the failure costs downstream. So "The ranking flips by workload, and no price list tells you which way". The agency's hardest tenth are the long deposit reports with contested damage.

The Eval Is the Gate, for Selection and for Migration

A small eval turns an opinion into a decision, for selection and migration alike. The documented process has four steps. First, "Create benchmark tests specific to your use case - having a good evaluation set is the most important step in the process". Second, "Test with your actual prompts and data". Third, compare accuracy, response quality and handling of edge cases. Fourth, weigh performance and cost trade-offs. The agency's eval is a set of past deposit reports, each with a check on the deductions.

The sweep below varies one thing at a time. It records cost beside a boolean outcome check, not a rating. It sends no effort argument when a row gives no level, as for a legacy model that does not carry the parameter.

import json
import anthropic

client = anthropic.Anthropic()

# {"<model-id>": {"input": <usd per Mtok>, "output": <usd per Mtok>,
#                 "cache_write_5m": <usd per Mtok>, "cache_read": <usd per Mtok>}}
RATES = json.load(open("rates.json"))


def request_cost(model, usage):
    r = RATES[model]
    return (
        usage.input_tokens * r["input"]
        + usage.cache_creation_input_tokens * r["cache_write_5m"]
        + usage.cache_read_input_tokens * r["cache_read"]
        + usage.output_tokens * r["output"]
    ) / 1_000_000


def sweep(model, effort, cases):
    """Return pass rate and cost per COMPLETED task for one model at one effort."""
    options = {"output_config": {"effort": effort}} if effort else {}
    spend, passed = 0.0, 0
    for case in cases:
        response = client.messages.create(
            model=model,
            max_tokens=64_000,
            messages=[{"role": "user", "content": case.prompt}],
            **options,
        )
        spend += request_cost(model, response.usage)
        passed += 1 if case.check(response) else 0   # a boolean, never a rating
    return passed / len(cases), spend / max(passed, 1)


for model, effort in [
    ("claude-haiku-5-5", "low"),
    ("claude-sonnet-5-5", "low"),
    ("claude-sonnet-5-5", "high"),
    ("claude-opus-5-5", "medium"),
]:
    rate, cost = sweep(model, effort, hardest_tenth_of_traffic)
    print(f"{model} effort={effort or 'n/a'} pass={rate:.0%} cost/completed=${cost:.4f}")

A benchmark table or a price cut is not a migration gate, because published numbers are measured on somebody else's tasks. The gate is your own suite, run with your own prompts and data against the candidate model.

Hold the other variables still and change one thing at a time. Run each effort level in a separate session, because changing the top-level effort value mid-session starts the prompt cache over and distorts the cost comparison. As of September 2026 a per-message effort change, in beta on the models that support it, keeps the cache. It is a production tool for conversations whose later turns need less reasoning. A clean comparison still gives each level its own session. A prompt tuned for the old model is also not a neutral test of the new one.

A sweep need not end in one fixed level. As of September 2026 Anthropic's cost guidance documents a policy for checkable work: "run every task at a low setting and re-run only the failures at a higher one". On its coding benchmark that slightly beat the pass rate of running everything at high, for a little over half the cost. It needs a failure signal you trust, such as the boolean check above. Every first-pass failure takes two runs of wall-clock time, so the saving is paid for in latency.

Lifecycle States, and Why a Model Change Is a Behavioural Change

The lifecycle vocabulary is exact and testable.

Anthropic commits to "providing at least 60 days' notice before model retirement for publicly released models", and states that "Every Claude model ID is a pinned snapshot". A retirement date is a deadline on your roadmap, so staying on what works is a strategy with an expiry. Because IDs are pinned snapshots, nothing changes underneath you unless you change it, so a planned migration is possible. When the agency's chat model is deprecated, its retirement date goes in the calendar.

A new model is a new system, with differences documented in three kinds. Behaviour shifts in named ways: default response length, how literally instructions are interpreted, tool-calling tendency and readiness to delegate to subagents. Interface changes break code outright. Manual extended thinking with budget_tokens, assistant prefill, and non-default temperature, top_p or top_k all return a 400 on the newest models. Cost changes arrive even when nothing breaks. A newer model follows literally a prompt written to compensate for an older one, which can cost materially more for no accuracy gain. If the agency's deposit prompt carries instructions written for an older model, a newer one follows them literally and the job can cost more.

In the exam

The guide's scope here is "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". Two of those three are durable and one expires. Adaptive thinking is named in that scope because support is not uniform. A stem names the deciding constraint: a latency bar, a volume, an accuracy threshold or the cost of one error. The keyed answer matches the tier to that constraint, usually tries effort before a tier change, and gates any switch on your own eval. The usual trap is tier dogma in either direction.

Dated Facts

The current line-up, model IDs and prices live on the domain quick reference, with a date on them.

Exam Traps

Practice Scenario

Build Exercise

Sources

• Models overview — Claude Docs, the current line-up, comparative latency, adaptive thinking support and pinned snapshots
• Choosing the right model — Claude Docs, the four criteria, the two starting strategies and the four-step evaluation process
• Optimizing for cost and intelligence — Claude Docs, the cost and capability ordering, cost per completed task, pricing the tail and re-running failures at higher effort
• Model deprecations — Claude Docs, the lifecycle states, the notice period and the parameter deprecations
• Migration guide — Claude Docs, breaking behaviour and interface changes across releases
• Define success criteria and build evaluations — Claude Docs, building the evaluation set that gates the decision
• Effort — Claude Docs, effort levels and the per-message effort change that keeps the prompt cache
• Claude Certified Developer Foundations Exam Guide — Domain 5, Model Selection and Tradeoffs — Anthropic