Choose a Claude Model

Su Suriya Ravichandran Updated 10 Nov 2026

13 min read ·Lesson 12 of 200

What the `model` Parameter Does

Every Messages API request names the model that should process it:

message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
)

Claude is not a single model. It is a family of models that trade off intelligence, speed, and cost. The model value, called the model ID, decides:

quality: how well complex reasoning, coding, and writing tasks are handled,
latency: how quickly the response arrives,
cost: the price per input and output token, and
capabilities and limits: context window size, maximum output, and supported features.

Choosing well can change the cost of an application several times over without any loss in quality, or noticeably improve quality on hard tasks. This lesson explains the current lineup, how model IDs work, and a practical method for choosing.

The Current Model Lineup

As of November 2026, the current Claude models are:

Model	Model ID	Best for	Relative latency	Price per million tokens (input / output)
Claude Fable 5.1	`claude-fable-5-1`	Demanding reasoning and long-horizon agentic work	Slower	$10 / $50
Claude Opus 5.5	`claude-opus-5-5`	Long-running agentic coding and knowledge work; the recommended starting point	Moderate	$4 / $20
Claude Sonnet 5.5	`claude-sonnet-5-5`	The best combination of speed and intelligence	Fast	$2 / $10
Claude Haiku 5.5	`claude-haiku-5-5`	High-volume, latency-sensitive tasks: classification, extraction, routing	Fastest	From $0.10 / $0.50

Shared specifications:

Specification	All four current models
Context window	1M tokens
Maximum output (`max_tokens`)	128K tokens
Input	Text and images
Output	Text
Tool use, vision, multilingual	Supported
Reliable knowledge cutoff	June 2026

A few terms in these tables need explanation:

MTok means one million tokens. "$4 / MTok" means $4 for every million tokens.
Context window is the maximum amount of text, measured in tokens, that the model can consider at once. That includes your prompt, the conversation history, documents, and the reply.
Knowledge cutoff is the date through which the model's training knowledge is most reliable. The model does not know about events after it unless you provide the information in the prompt.
Haiku's price says "From" because its price depends on the request. Check the official pricing page for the exact rates.

Note: Model lineups and prices change. The Models overview and Pricing pages in the Claude Platform documentation are the authoritative sources. You can also query models programmatically, as shown later in this lesson.

Thinking Behavior

All current models use adaptive thinking: the model decides when and how much to reason before answering. On Claude Fable 5.1 and Claude Opus 5.5, thinking is always on and cannot be turned off. Its depth is guided by the effort setting (Lesson 152). This has two practical consequences, covered in Lessons 11 and 13:

responses can contain thinking blocks before the text, and
thinking tokens count toward max_tokens and are billed as output tokens.

How Model IDs Work

The ID Format

Current model IDs follow this pattern:

claude-{name}-{major}[-{minor}]

Model ID	Name	Version
`claude-opus-5-5`	opus	5.5
`claude-sonnet-5-5`	sonnet	5.5
`claude-opus-5`	opus	5 (a major release with no minor segment)

Older models, released before the Claude 4.6 generation, include a snapshot date, as in claude-sonnet-4-5-20250929.

IDs Are Pinned Snapshots

A model ID always refers to the same fixed model. claude-opus-5-5 does not quietly change into a newer model later. When Anthropic releases an improved model, it ships under a new ID.

Why this matters: your application's behavior does not change unexpectedly when Anthropic releases new models. Upgrading to a newer model is a deliberate change in your code or configuration, which you can test first.

Note: For some older dated models, the API also accepts shorter aliases, such as claude-sonnet-4-5, which point to the latest snapshot of that version. Current-generation IDs are not aliases; they are the snapshots themselves.

IDs on Cloud Platforms

The same model can have a slightly different ID on other platforms:

Platform	ID for Claude Opus 5.5
Claude API	`claude-opus-5-5`
Amazon Bedrock	`anthropic.claude-opus-5-5`
Google Cloud, Microsoft Foundry, Claude Platform on AWS	`claude-opus-5-5`

Lessons 161–170 cover cloud platforms.

Model Lifecycle: Active, Deprecated, Retired

Models do not stay available forever. Each model ID moves through stages:

Stage	Meaning	What to do
Active	Available and open to new users	Use normally
Deprecated	Still works for existing users, but scheduled for retirement and closed to new adopters	Plan a migration to a newer model
Retired	No longer available. Requests naming it fail.	Must use another model

For example, the Claude Opus 5.5 documentation states that it will not be retired sooner than September 22, 2027. Anthropic publishes retirement dates on the Model deprecations page and notifies customers in advance.

Practical consequence: model IDs copied from old blog posts or tutorials, such as claude-3-... models, may already be retired and return errors.

Listing and Inspecting Models with the SDK

The Models API reports which models your account can use, together with their limits and lifecycle status. These requests use no tokens.

List Models

from anthropic import Anthropic

client = Anthropic()

for model in client.models.list():
    print(f"{model.id:<22} {model.display_name:<20} {model.lifecycle}")

Example output (the exact list depends on your account and the date):

claude-fable-5-1       Claude Fable 5.1     active
claude-opus-5-5        Claude Opus 5.5      active
claude-sonnet-5-5      Claude Sonnet 5.5    active
claude-haiku-5-5       Claude Haiku 5.5     active
claude-opus-5          Claude Opus 5        active
...

client.models.list() returns an auto-paginating iterator. The for loop fetches further pages automatically as needed. By default, the list contains active and deprecated models.

Inspect One Model

model = client.models.retrieve("claude-opus-5-5")

print("Name:          ", model.display_name)
print("Max input:     ", model.max_input_tokens)
print("Max output:    ", model.max_tokens)
print("Lifecycle:     ", model.lifecycle)
print("Retires at:    ", model.retires_at)

Example output:

Name:           Claude Opus 5.5
Max input:      1000000
Max output:     128000
Lifecycle:      active
Retires at:     None

Field	Meaning
`id`	The model ID to use in requests
`display_name`	Human-readable name
`max_input_tokens`	The context window size
`max_tokens`	The largest allowed value for the `max_tokens` request parameter
`lifecycle`	`active`, `deprecated`, or `retired`
`retires_at`	Scheduled retirement date, or `None` if none is scheduled
`line`	The model family, such as `opus` or `sonnet`. Use this instead of parsing the ID.
`capabilities`	Detailed feature support, such as thinking options and server tools

Why query this instead of hardcoding limits: values such as maximum output differ between models and change with new releases. Reading them from the API keeps your application correct when you switch models.

How to Choose a Model

Step 1: Start with a Capable Default

For a new application, start with Claude Opus 5.5. Anthropic's documentation recommends it for most workloads. Starting with a strong model tells you what "good" looks like for your task.

Step 2: Match the Model to the Task

Task type	Examples	Good starting model
Hard reasoning, long autonomous work	Multi-step research agents, complex refactoring, deep analysis	Opus 5.5; Fable 5.1 if Opus at higher effort falls short
General applications	Chatbots, writing help, code explanation, summarization	Opus 5.5 or Sonnet 5.5
Real-time, interactive features	Autocomplete, live chat with many users	Sonnet 5.5 or Haiku 5.5
High-volume simple tasks	Classification, tagging, extraction, routing	Haiku 5.5

Step 3: Test Cheaper or Faster Models on Real Examples

Collect 10–50 realistic inputs. Run them through the candidate models and compare the outputs. If a smaller model's results are just as good for your task, use it. Classification and extraction often work equally well on smaller models at a fraction of the cost.

Step 4: Consider Mixing Models

Applications are not limited to one model. A common design routes each request to the model that fits it:

User request ──► Haiku 5.5: classify (simple question? complex task?)
                     │
         ┌───────────┴───────────┐
         ▼                       ▼
  Sonnet 5.5: answer      Opus 5.5: handle complex task
  simple questions        with deeper reasoning

The cheap, fast model handles the high-volume decision. The expensive model is used only where it adds value.

The Trade-offs Summarized

If you need…	Prefer…	You give up…
The highest quality on hard problems	Fable 5.1 or Opus 5.5	Speed and cost
A balance of quality and speed	Sonnet 5.5	Some depth on the hardest tasks
The lowest latency and cost at scale	Haiku 5.5	Capability on complex reasoning

Estimating Cost

Cost depends on tokens and the model's prices:

cost = (input_tokens  × input_price  / 1,000,000)
     + (output_tokens × output_price / 1,000,000)

Example: a request with 2,000 input tokens and 500 output tokens:

Model	Input cost	Output cost	Total
Fable 5.1	2,000 × $10 / 1M = $0.020	500 × $50 / 1M = $0.025	$0.045
Opus 5.5	2,000 × $4 / 1M = $0.008	500 × $20 / 1M = $0.010	$0.018
Sonnet 5.5	2,000 × $2 / 1M = $0.004	500 × $10 / 1M = $0.005	$0.009

At 100,000 such requests per month, that is about $4,500 on Fable 5.1, $1,800 on Opus 5.5, and $900 on Sonnet 5.5. That is why model choice matters at scale.

Remember that thinking tokens are billed as output tokens. Always calculate cost from the usage.output_tokens reported by the API, not from the length of the visible answer.

Note: As a rough guide, the tokenizer used by current models fits about 555,000 English words into 1 million tokens, so one word is a little under two tokens on average. Exact counts vary by language and content. Lesson 46 shows how to count tokens exactly before sending a request.

Practical Example: Comparing Models on Your Own Prompt

This script sends the same prompt to several models and reports the answer, latency, token usage, and estimated cost of each. It turns "which model should I use?" into a measured decision.

"""compare_models.py: run one prompt on several models and compare the results."""

import time

from anthropic import Anthropic
from anthropic.types import Message

# Prices in USD per million tokens (input, output).
# Verify against the official pricing page before relying on them.
PRICES = {
    "claude-opus-5-5": (4.00, 20.00),
    "claude-sonnet-5-5": (2.00, 10.00),
}

PROMPT = (
    "A customer writes: 'I was charged twice for my order #4821.' "
    "Classify the message as billing, shipping, or technical, "
    "and draft a two-sentence reply."
)

client = Anthropic()


def get_text(message: Message) -> str:
    return "".join(block.text for block in message.content if block.type == "text")


def estimate_cost(model: str, input_tokens: int, output_tokens: int) -> float:
    input_price, output_price = PRICES[model]
    return (input_tokens * input_price + output_tokens * output_price) / 1_000_000


for model_id in PRICES:
    start = time.perf_counter()
    message = client.messages.create(
        model=model_id,
        max_tokens=2048,
        messages=[{"role": "user", "content": PROMPT}],
    )
    elapsed = time.perf_counter() - start

    usage = message.usage
    cost = estimate_cost(model_id, usage.input_tokens, usage.output_tokens)

    print(f"=== {model_id} ===")
    print(get_text(message).strip())
    print(
        f"[{elapsed:.1f}s | in={usage.input_tokens} out={usage.output_tokens} "
        f"| ~${cost:.5f} | stop={message.stop_reason}]\n"
    )

Example output (wording, timings, and token counts will vary):

=== claude-opus-5-5 ===
Category: billing
Reply: I'm sorry you were charged twice for order #4821. I've flagged the duplicate charge for a refund, and you'll see it back on your statement within 3–5 business days.
[4.2s | in=52 out=180 | ~$0.00381 | stop=end_turn]

=== claude-sonnet-5-5 ===
Category: billing
Reply: Sorry about the double charge on order #4821. We're refunding the duplicate payment now, and it should appear on your statement within a few business days.
[2.1s | in=52 out=96 | ~$0.00106 | stop=end_turn]

How the Script Works

PRICES maps each model ID to its input and output price per million tokens. The loop iterates over its keys, so adding a model to compare means adding one line. Haiku 5.5 is not included because its price varies by request. Add it with the exact rates from the pricing page.
time.perf_counter() is a high-resolution timer suited to measuring elapsed time. The difference before and after the call is the total latency, including network time and any thinking.
estimate_cost() applies the cost formula to the reported token usage. That usage includes thinking tokens, so the estimate reflects what you are actually billed.
stop_reason is printed so that you notice if any model ran out of output tokens, which would make the comparison unfair.

Run the script on several realistic prompts from your application before choosing, not just one. A single prompt can be misleading.

Making the Model Configurable

Hardcoding model IDs throughout an application makes switching models painful. Keep the ID in configuration (Lesson 8):

import os

DEFAULT_MODEL = os.environ.get("CLAUDE_MODEL", "claude-opus-5-5")
CLASSIFIER_MODEL = os.environ.get("CLAUDE_CLASSIFIER_MODEL", "claude-haiku-5-5")

Benefits:

trying a different model requires no code change,
staging can test a new model while production keeps the current one, and
each purpose, such as answering or classifying, can be tuned independently.

Common Mistakes

Using Outdated Model IDs

What happens: an ID copied from an old article returns a 404 not_found_error, because the model is retired or the ID never existed.

Fix: take IDs from the official Models overview or from client.models.list().

Typos in Model IDs

What happens: claude-opus-5.5 (with a dot) or claude-opus5-5 fails with a 404 error.

Fix: IDs use hyphens only: claude-opus-5-5. Keep IDs in constants or configuration instead of retyping them.

Defaulting to the Most Expensive Model Everywhere

What happens: costs grow far beyond what the task requires.

Fix: test smaller models on real examples. Many tasks, especially classification and extraction, do not need the largest model.

Choosing Only by Price

What happens: a cheap model produces errors that cost more to fix, in support time and user trust, than the savings.

Fix: measure quality on realistic inputs first, then optimize cost.

Assuming a Model Never Changes

What happens: a deprecated model reaches retirement and requests start failing.

Fix: watch deprecation notices, check lifecycle and retires_at through the Models API, and plan migrations early.

Reusing Token Estimates Across Model Generations

What happens: cost estimates and max_tokens values tuned for an older model are wrong for a newer one. Newer models use a tokenizer on which the same text can count as more tokens.

Fix: recount tokens and recalculate costs whenever you change model generations.

Best Practices

Start with Claude Opus 5.5, then evaluate faster and cheaper models on your real workload.
Make decisions with data: run representative prompts and compare quality, latency, and cost.
Use different models for different jobs, such as small models for routing and classification and larger ones for complex reasoning.
Keep model IDs in configuration, not scattered through the code.
Read limits from the Models API instead of hardcoding them.
Monitor lifecycle status and migrate before retirement dates.
Track usage per model to understand where your costs come from.

Exercise

List all models available to your account and their lifecycle status.
Retrieve claude-sonnet-5-5 and print its max_input_tokens and max_tokens.
Using the prices in this lesson, calculate the cost of 10,000 requests with 1,500 input tokens and 400 output tokens each, on Opus 5.5 and on Sonnet 5.5.
Run compare_models.py on three prompts from a project of your own. Which model would you choose for each, and why?

Show answers for steps 1–3

Steps 1–2:

from anthropic import Anthropic

client = Anthropic()

for model in client.models.list():
    print(model.id, model.lifecycle)

sonnet = client.models.retrieve("claude-sonnet-5-5")
print(sonnet.max_input_tokens, sonnet.max_tokens)

Step 3:

Opus 5.5 per request: 1,500 × $4 / 1M + 400 × $20 / 1M = $0.006 + $0.008 = $0.014. For 10,000 requests: $140.
Sonnet 5.5 per request: 1,500 × $2 / 1M + 400 × $10 / 1M = $0.003 + $0.004 = $0.007. For 10,000 requests: $70.

Actual output tokens, including any thinking, may differ between models, so measure real usage before making a final decision.