Claude Models, Prompting & Context Engineering · Lesson 1 of 5

6.1 - Selecting a Claude Model on Cost, Latency and Capability Trade-offs

Choose a Claude model tier and effort setting by measuring cost per completed task, latency and capability on your own evals, and decide when routing or multi-model patterns beat a single model.

On the exam, model selection is never “pick the newest, biggest model.” It is an engineering decision made with evidence: which tier, at which effort setting, for which step, justified by measured quality, latency and cost on your workload. The lineup below is a snapshot from Anthropic’s Models overview page as of September 2026. Model names, prices and limits change often, so treat the method as the durable part and re-check the current page before quoting any number.

The lineup is a menu, not a ladder

Model (API ID)	Anthropic’s positioning	Relative latency	Context	Thinking
Claude Fable 5.1 (`claude-fable-5-1`)	Demanding reasoning and long-horizon agentic work	Slower	1M tokens	Adaptive, always on
Claude Opus 5 (`claude-opus-5`)	Complex agentic coding and enterprise work	Moderate	1M tokens	Adaptive
Claude Sonnet 5 (`claude-sonnet-5`)	Best combination of speed and intelligence	Fast	1M tokens	Adaptive
Claude Haiku 4.5 (`claude-haiku-4-5-20251001`)	Fastest, near-frontier intelligence	Fastest	200K tokens	Extended thinking; no effort parameter

Listed input prices rise from $1 (Haiku 4.5) to $2 (Sonnet 5), $5 (Opus 5) and $10 (Fable 5.1) per million tokens, with output priced at five times input on each. Every step up is a 2x to 2.5x per-token premium, so the real question for each pipeline step is what that premium buys.

Two structural facts matter beyond the table. First, defaults differ by tier: thinking is on by default on Opus 5 and Sonnet 5 when you omit the thinking parameter, is always on for Fable 5.1, and can be disabled on Opus 5 only at effort high or below. Cost and behaviour tested on one tier do not transfer unchanged. Second, model IDs are pinned snapshots: a dateless ID such as claude-opus-5 is not an evergreen pointer, and every ID has its own retirement schedule, so a model choice carries a maintenance date.

Decide on four axes, priced per completed task

Capability needed. Multi-step reasoning, ambiguity and long-horizon autonomy point up the ladder; lookup, classification and formatting rarely need the top tier. Judge difficulty by the structure of the task, not by how technical the topic sounds.
Latency budget. The overview’s latency column is relative only; actual latency depends on prompt length, output length and thinking effort. An interactive turn and a nightly job have very different budgets (see 1.3 and 3.5).
Cost. Per-call price x volume x retries. Measure cost per completed task, not cost per token: a cheaper model that fails and retries can cost more than a stronger one that succeeds first time.
Cost of a wrong answer. An unreviewed, high-stakes action justifies more capability than a classification a human re-routes in seconds. This is often the deciding axis in a scenario question.

Anthropic’s own optimisation guidance adds a warning worth remembering: compare candidates on the hardest slice of the workload, not the median. Easy cases look identical across tiers; the difference (and the cost, since a failure still bills, then the retry, then the downstream damage) concentrates in the tail.

Effort is a selection lever, not a footnote

The output_config.effort parameter trades intelligence for latency and cost inside one model, and Anthropic’s model-choice guide says tuning effort is often a better lever than switching models. Levels run from low through medium, high, xhigh and max, with availability varying by model; the API default is high on Fable 5.1, Opus 5 and Sonnet 5. Effort affects all output tokens (text, tool calls and thinking) and is a behavioural signal, not a hard token budget. Three practical consequences:

Effort settings carried over from an earlier model need a fresh sweep on your evals; do not reuse them.
On Opus 5, effort changes how much the model thinks, not reliably how much it says; control visible length by prompting for it.
Changing top-level effort between requests of a cached conversation invalidates the cache (see 6.5), so vary effort across workloads, not mid-conversation. (A beta per-message effort change on a few models, including Opus 5 and Fable 5.1, is documented to preserve the cache.)

Key concept: change one lever at a time, effort before tier before multi-model

Start from a provisional tier, then reduce cost one lever at a time, validating each change on the same eval set: (1) sweep effort on the current tier; (2) if a gap remains, price the stronger model alone at low effort, because that number is what any multi-model design must beat; (3) only then consider routing or advisor/orchestrator patterns. (This ordering is a synthesis of Anthropic’s guidance, not a named Anthropic procedure.) Anthropic’s guidance is that a multi-model strategy must beat the whole single-model effort curve, not just one point on it.

Two starting points, then multi-model patterns

Anthropic describes two ways to begin. Efficiency-first: start on Haiku 4.5, test thoroughly and upgrade only for specific capability gaps (best for prototyping, tight latency, high-volume simple work). Capability-first: start on the strongest fit (Opus 5 in the guide), optimise prompts, then lower effort or step down tiers as evals allow, moving up to Fable 5.1 only if evals at xhigh or max still fall short. Both converge on the same rule: evals decide.

For mixed workloads the guide describes two patterns. In the advisor pattern a lower-cost executor runs the loop and escalates hard decisions to a stronger model; the payoff depends on the capability gap and on the consult rate (an executor at low effort can stop noticing it is stuck and consult rarely, then score below the executor alone), and if the advisor’s model at low effort already clears your quality bar it is simpler and often cheaper to run it alone. In the orchestrator pattern a stronger model delegates bulk, independent work to cheaper workers; Anthropic’s measurements show it paying off on fan-out work that exceeds one context window or has a long cost tail, and losing to a single model at lower effort on one dependent chain. Those figures are directional and should be re-measured on your workload (orchestration itself is covered in 2.4).

Re-evaluate; do not assume

A selection is not permanent. Volume grows, new generations reshuffle what each tier can do, and retirement dates arrive. Recount tokens when you change model: Claude 4.7 and later models use a tokenizer that yields roughly 30 percent more tokens for the same text, so counts measured on an older model must not be reused for cost or context planning. For regulated deployments, check the API and data-retention page as well: some models carry model-specific data-retention requirements, and zero-data-retention eligibility excludes them (see 4.4).

Common exam distractor

Watch for answers that assign one tier to everything (“the most capable model for quality” or “the cheapest model for cost”), that jump to a cheaper tier before sweeping effort, or that decide from a single run or from average-case prompts. The defensible answer matches tier and effort to each step, measured on an eval that includes the hard tail and judged on cost per completed task.

Exam traps

Use the most capable model for every step because it is the newest and highest quality.

Capability is one axis among four. High-volume, low-difficulty steps such as routing or extraction gain little from the top tier but pay the per-token premium and latency on every call.
Drop straight to the cheapest tier to cut cost, without first tuning effort on the current tier.

Effort is a within-model lever that is cheaper to validate than a model swap. Anthropic recommends tuning effort first and pricing the stronger model at low effort as the baseline any cheaper design must beat.
Assume defaults (thinking, effort, tokenizer, context window) are identical across tiers and generations, so prompts and cost estimates carry over.

Thinking defaults and disable rules differ by model, Haiku 4.5 has no effort parameter and a smaller context window, and Claude 4.7 and later tokenise the same text into roughly 30 percent more tokens. Re-test and recount when the model changes.
Compare candidate models on a handful of typical prompts from a single run and keep the cheaper one if the results look equal.

Cost and error concentrate in the hardest slice of a workload, and single-run differences of a task or two are noise. A defensible decision needs an eval set with hard cases, repeated trials and cost per completed task.

Practice question

An agentic pipeline runs every step on the most capable tier at default effort and the monthly bill is too high. Step A classifies inbound requests into five categories at very high volume with a tight latency target; Step B plans multi-file changes that are reviewed by an engineer before merging. What should the architect do first?

A Build an eval set per step that includes hard-tail cases, sweep effort on the current tier, then test a lower tier for Step A while keeping the stronger tier for Step B unless evals show otherwise. Correct
This matches tier and effort to each step's difficulty, volume and cost of error, measures the hard tail, and follows the stepping-down order (effort first, then tier), changing one lever at a time.
B Move the entire pipeline to the cheapest, fastest tier immediately, since that produces the largest single reduction in per-token cost and the classifier at least will clearly benefit from the lower latency.
This is an untested, all-or-nothing change. It may save money on Step A but risks quality on the planning step, and nothing has been measured. It also skips the effort lever.
C Freeze the pipeline and wait for the next model generation, because newer generations have often been both cheaper and more capable than the tier currently in use.
Selection is a decision made against current evidence, not deferred. New generations do change the picture, which is why the lesson recommends periodic re-evaluation, not inaction.
D Keep the current models and default effort but shorten the prompts across both steps, because the price difference between tiers is too small to matter at scale.
Listed prices differ by 2x to 2.5x per tier step, and at high volume that multiplier dominates spend. Prompt trimming may help, but it does not address the mismatch between tier and task.

Build exercise: Write a model-selection decision record backed by a cost-per-completed-task eval

Intermediate · 60 minutes

You'll practice:

Score a multi-step workload on capability, latency, volume and cost-of-error to shortlist tiers per step
Run a model-by-effort matrix on an eval set that includes hard-tail cases and record tokens and latency
Compute cost per completed task using current pricing and account for failures and retries
Justify a per-step configuration in a decision record with re-evaluation triggers

Pick a real or hypothetical pipeline with at least two steps. For each step write the four axes (capability needed, latency budget, monthly volume, cost of a wrong answer) and one measurable pass criterion.

Selection is a per-step decision. Writing the axes first stops you defaulting to one tier for everything and gives the eval something concrete to measure.

You should see: A short table with one row per step, a shortlist of two or three candidate configurations for each, and a numeric pass criterion (for example, at least 95 percent correct category).

Hints

Which of the four axes is most likely to dominate for each step, and would the same axis dominate for every step?

Rank the axes per step rather than treating them equally. A high-volume classifier is usually dominated by cost and latency; an unreviewed high-stakes action by cost of error.

Step A | classify 5 categories | latency <1s | 2M/day | wrong = re-routed by a human | pass: >=95% exact match
Step B | plan multi-file change | latency minutes | 300/day | wrong = wasted review time | pass: reviewer accepts plan >=80%
Shortlist A: Haiku 4.5; Sonnet 5 low effort. Shortlist B: Sonnet 5 high; Opus 5 high.

Build an eval set per step of 20 to 30 cases, deliberately including about a quarter hard-tail cases (ambiguous, multi-signal or edge-case inputs), each with an expected answer or a grading rubric.

Models look alike on easy cases; the tail is where tiers diverge and where most cost and risk sit. Without hard cases you cannot tell whether a cheaper tier is safe.

You should see: A JSON or CSV file per step with prompt, expected answer or rubric, and a hard flag, plus a note on how each case will be graded (exact match, code check, or an LLM grader on a different model).
Hints
1. ```
What makes a case hard for this step: ambiguity, conflicting signals, unusual formatting, or length?
```
2. ```
Take real production samples if you have them and add cases from past failures; prefer automated grading (exact match or code) where possible and reserve an LLM grader for subjective outputs.
```
3. ```
{'id': 'A-014', 'input': 'Package says delivered but I never got it, and I was charged twice', 'expected': 'billing', 'hard': True, 'note': 'shipping and billing signals'}
```

Run every case against a matrix of candidate model and effort settings, recording pass or fail, input tokens, output tokens and wall-clock latency. Pass effort only to models that support it.

This produces the data the decision rests on. Recording tokens and latency per call lets you compute cost and check the latency budget, and splitting results by the hard flag exposes the tail.

You should see: A results table with one row per (case, model, effort) and columns for correct, hard, input tokens, output tokens and seconds.

Hints

Which models in your matrix do not accept an effort setting, and how will your harness avoid sending one to them?

Wrap the call in one function that adds output_config only when an effort is given, and set max_tokens generously because thinking tokens count toward it on models that think by default.

import time, anthropic
client = anthropic.Anthropic()

def run_case(model, prompt, effort=None):
    kwargs = {}
    if effort:  # Haiku 4.5 does not support effort
        kwargs['output_config'] = {'effort': effort}
    t0 = time.time()
    r = client.messages.create(model=model, max_tokens=4000,
        messages=[{'role': 'user', 'content': prompt}], **kwargs)
    text = next((b.text for b in r.content if b.type == 'text'), '')
    return text, r.usage.input_tokens, r.usage.output_tokens, time.time() - t0

Compute cost per completed task for each configuration using the input and output prices from the current Anthropic pricing page. Add a fixed penalty per failed case to represent a retry or human fix, and repeat each configuration at least three times to see run-to-run spread.

Cost per token hides failures. Dividing total spend (including retries) by the number of successes is the number you can defend, and repeat runs show whether a difference is real or noise.

You should see: A per-configuration line with pass rate on easy cases, pass rate on hard cases, mean cost per completed task, p95 latency and the spread across repeats.

Hints

If one configuration fails 10 percent of cases, what does that do to its cost per completed task compared with its cost per call?

Sum call costs, add retry_cost times the number of failures, and divide by the number of passes (not the number of cases). Read the rates from the pricing page rather than hard-coding remembered values.

RATES = {'claude-sonnet-5': (IN, OUT)}  # fill in $/MTok from the current pricing page

def cost(model, in_tok, out_tok):
    i, o = RATES[model]
    return in_tok / 1e6 * i + out_tok / 1e6 * o

def cost_per_completed(rows, retry_cost=0.0):
    total = sum(cost(r['model'], r['in'], r['out']) for r in rows)
    fails = sum(1 for r in rows if not r['correct'])
    return (total + fails * retry_cost) / max(len(rows) - fails, 1)

Write a one-page decision record: chosen model and effort per step, the evidence (tail pass rate, cost per completed task, latency), the rejected alternatives and why, and the triggers that force re-evaluation.

A decision you cannot justify is a habit. The record is what a stakeholder or reviewer can challenge, and the re-evaluation triggers keep the choice from going stale.

You should see: A document with a per-step table, a short rationale, a list of risks (differing defaults, tokenizer changes, data-retention requirements, retirement dates) and explicit triggers such as a new model release, a volume change of an order of magnitude, or a retirement notice.
Hints
1. ```
What events would make this decision wrong even though nothing in your code changed?
```
2. ```
List triggers in three groups: model-side (new release, retirement, tokenizer change), workload-side (volume, difficulty mix, new input types) and requirement-side (latency SLA, compliance).
```
3. ```
Re-evaluate when: (1) a new tier or generation is announced on the models overview; (2) monthly volume for a step changes 10x; (3) hard-tail pass rate drops below target for two consecutive weeks; (4) a retirement date falls within 6 months; (5) latency SLA or data-handling requirements change.
```

Sources

Models overview (Claude API docs) - Anthropic
Choosing the right model (Claude API docs) - Anthropic
Optimizing for cost and intelligence: multi-model strategies (Claude API docs) - Anthropic
Effort parameter (Claude API docs) - Anthropic
Model IDs and versioning (Claude API docs) - Anthropic
Token counting (Claude API docs) - Anthropic