Model Selection and Trade-offs

What You Need to Know

Claude models belong to families, or tiers: Haiku, Sonnet, Opus and a frontier model (the most capable and most expensive family). 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.

This lesson uses one made-up example throughout: a company that sells project management software and runs two Claude jobs. One job answers customer messages in the product's help chat. It answers hundreds a day, and customers expect a quick reply. The other job compares each customer invoice with the usage records and proposes billing corrections. In that job, a wrong correction means a dispute.

The Ordering Is Durable, the Line-Up Is Not

The order of the families and the method for choosing between them stay the same in every release. The line-up (the set of current models), the model IDs and the prices do not stay the same in every release. Anthropic states the order in its own documentation, and the order is worth memorising. As of 13 November 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.2 (the frontier model). In October 2026 the list ended with Claude Fable 5.1. In September 2026 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. Haiku 5.5 is Fastest and Sonnet 5.5 is Fast. Opus 5.5 and the frontier model are both Moderate. So quality, latency and cost are not independent. A model higher in the order gives more capability and costs more money, and it is no faster.

Haiku is for "The lowest latency and price": real-time applications, high-volume intelligent processing and sub-agent tasks (tasks that one agent gives to another agent). 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 family is for long-running agents, deep reasoning and long-horizon agentic tasks (agentic tasks with many steps).

The guide names adaptive thinking support in its scope because support was not uniform when the guide 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 (reasoning between tool calls) either. As of 13 November 2026 every model in the current line-up has adaptive thinking. Adaptive thinking is always on in Claude Fable 5.2 (the frontier model) and Claude Opus 5.5. Claude Sonnet 5.5 and Claude Haiku 5.5 support it too. Haiku 4.5 is an older model, and it is 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, excludes Haiku 4.5 before cost is considered. If the company's billing 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. The first is Capabilities: "What specific features or capabilities will you need". The second is Speed: "How quickly does the model need to respond". The third is Cost: "What's your budget". The fourth is Effort, and candidates skip it. Effort is a setting 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 option, tune effort first. For a workload that costs too much at the default, run an effort sweep (a test of the workload at several effort levels) before a tier change. For a workload that answers shallowly, increase effort before you move to a higher tier. If the company's billing proposals miss overcharges, the company raises effort before it moves to a higher tier. Anthropic's cost guidance makes one exception: upgrade a model that is one or two models behind the current line-up first.

There are two documented starting strategies. Efficiency-first begins with the fastest tier, tests thoroughly, and upgrades "only if necessary for specific capability gaps". The documentation lists it 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 13 November 2026 the page names Claude Opus 5.5 as the starting point. The page says to move to Claude Fable 5.2 only if evals at xhigh or max effort are still not good enough. The documentation lists capability-first as best for complex reasoning, tasks that need subtle understanding, and applications where accuracy outweighs cost.

Neither strategy is a default. The stated constraint selects one. The company's chat job starts efficiency-first because of its latency requirement and its volume. The billing job, where accuracy outweighs cost, starts capability-first.

Then compare the models on the right unit and the right 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 model looks best. The tasks that the cheaper model fails decide the bill. A failed task still bills its tokens, then the retry, then whatever else the failure costs later. So "The ranking flips by workload, and no price list tells you which way". The company's hardest tenth are the long invoices with disputed charges.

The Eval Is the Gate, for Selection and for Migration

A small eval replaces an opinion with evidence for 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 company's eval is a set of past invoices, each with a check on the corrections.

The sweep below varies one thing at a time. Its rates are in US dollars per million tokens (Mtok). It records cost beside a boolean outcome check, not a rating. It sends no effort argument when a row gives no level, as for an older model that does not support 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_write_1h": <usd per Mtok>,
#                 "cache_read": <usd per Mtok>,
#                 "over_100k": {<the same five keys>}}}  # only for a model priced by prompt length
# Standard rates. The Batch API discount and data residency pricing stack on top.
RATES = json.load(open("rates.json"))


def request_cost(model, usage):
    r = RATES[model]
    writes = usage.cache_creation  # the cache writes, split by lifetime
    writes_5m = writes.ephemeral_5m_input_tokens if writes else 0
    writes_1h = writes.ephemeral_1h_input_tokens if writes else 0
    reads = usage.cache_read_input_tokens or 0
    prompt = usage.input_tokens + writes_5m + writes_1h + reads
    if prompt > 100_000 and "over_100k" in r:  # Claude Haiku 5.5 is priced by prompt length
        r = r["over_100k"]
    return (
        usage.input_tokens * r["input"]
        + writes_5m * r["cache_write_5m"]
        + writes_1h * r["cache_write_1h"]
        + reads * 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 (a test that must pass before you migrate), because published numbers are measured on somebody else's tasks. The gate is your own suite. You run it with your own prompts and data against the candidate model.

Keep the other variables fixed, and change one thing at a time. Run each effort level in a separate session, because a mid-session change to the top-level effort value can invalidate all or part of the prompt cache. That distorts the cost comparison. As of 14 November 2026, a per-message effort change keeps the cache. This change is in beta on the models that support it. The per-message change 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. The policy is to "run every task at a low setting and re-run only the failures at a higher one". On Anthropic's coding benchmark, this policy slightly beat the pass rate of running everything at high, and it cost a little over half as much. The policy needs a failure signal that you trust, such as the boolean check above. Every first-pass failure takes the elapsed time of two runs, so the saving has a cost 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". It also states that "Every Claude model ID is a pinned snapshot" (one fixed version of the model). A retirement date is a deadline on your roadmap. So a strategy of staying with the model that works has an end date. Because model IDs are pinned snapshots, nothing changes unless you change it. So a planned migration is possible. When Anthropic deprecates the company's chat model, the company puts its retirement date in the calendar.

A new model is a new system. The documentation describes its differences in three kinds. Behaviour changes 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 (a last assistant turn that you write), 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 that was written to compensate for an older model. That literal reading can cost materially more for no gain in accuracy. If the company's billing prompt contains instructions written for an older model, a newer model 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 stay true across releases, and one changes over time. The guide names adaptive thinking in that scope because support is not uniform. A question names the deciding constraint: a latency requirement, a volume, an accuracy threshold or the cost of one error. The right answer matches the tier to that constraint. It usually tries effort before a tier change. It makes any switch depend on your own eval. The usual trap is a fixed rule of always choosing the highest tier, or always the lowest.

Dated Facts

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

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
• Pricing — Claude Docs, the per-model rates and the prompt-length pricing of Claude Haiku 5.5
• 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 top-level effort change that can invalidate the cache
• Per-message effort — Claude Docs, the per-message effort change that keeps the prompt cache, in beta on select models
• Claude Certified Developer Foundations Exam Guide — Domain 5, Model Selection and Tradeoffs — Anthropic