Model options and reasoning modes

Learning objectives

• Describe the four Claude tiers and the cost, latency and capability trade-off each represents.
• Apply the practical default: start with the balanced tier and move up or down only when an eval says so.
• Explain why reasoning mode (adaptive thinking, tuned by effort) is a per-request setting separate from model choice.
• Recognise when reasoning earns its cost and when it is wasted.

Estimated teaching time: 10 min · Prerequisites: M01-L02 How LLMs behave (tokens, evals)

Two dials, not one

The Harbor Goods team now has two very different jobs for Claude. One is tagging thousands of tickets a day with a category: simple, high volume, latency matters. The other is untangling a refund dispute that spans three orders and a returns policy: rare, hard, and correctness matters more than speed. One setting cannot serve both well. Claude gives you two separate dials: which model runs, and how much it reasons.

1. The Claude model family

Model tier

In plain English: A member of the Claude family. Each tier is a different trade-off across cost, latency, and capability.

Analogy: Like choosing between a scooter, a car, a van, and a truck: all get you there; they differ in speed, running cost, and what they can carry.

The practical default from the source is to start with Sonnet. Move up a tier only when an eval shows the current tier missing your quality bar. Move down to Haiku only when an eval shows the quality drop is acceptable for the task. Notice that both moves are triggered by an eval, never by a hunch.

• Common mistake: picking the biggest model by default and paying for capability the task never uses.
• Common mistake: dropping to a cheaper model without an eval, then discovering quality loss from customer complaints.
• How to apply: write the eval first, then let it choose the tier.

2. Reasoning modes are a separate setting from model choice

Reasoning mode

In plain English: Whether, and how much, the model thinks before answering. On current models this is adaptive thinking: the model decides when and how much to think, and you tune depth with an effort setting.

Why it matters: Thinking improves hard, multi-step answers but costs output tokens and time. Making it a per-request setting lets each call pay only for the reasoning it needs.

Choosing which model runs is one decision. Whether the model reasons before answering is a separate decision you make per call. You tune depth with an effort setting rather than a fixed token budget: the older budget_tokens control is deprecated and, on the newest model generations, returns a 400 error.

import anthropic

client = anthropic.Anthropic()

# Lever 1: which family member runs.
MODEL = "claude-sonnet-5-5"

# Lever 2: how much it reasons, set per request.
response = client.messages.create(
    model=MODEL,
    max_tokens=8000,  # caps thinking + answer together
    thinking={"type": "adaptive", "display": "summarized"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "A customer was charged twice for "
               "order A1042 and refunded once. Work out what they are owed."}],
)

for block in response.content:
    if block.type == "thinking":
        print("[summarized thinking]", block.thinking)
    elif block.type == "text":
        print(block.text)

Thinking content is omitted from responses by default on the newest models. When you need to show it, for example in an internal review tool, request summarized display. You are billed for the full thinking either way; display only changes what you see.

3. How the two work together

Because model choice and reasoning mode are independent, each can be set separately. A capable model with reasoning off (or at its lowest setting) is fast and direct. A smaller model with reasoning on spends more tokens to think. The most demanding tasks pair a capable model with a higher effort setting.

Module 2 teaches the mechanics of enabling reasoning and handling the thinking blocks it returns. The decision of which model to run, weighed against cost, latency, and quality, is taken up in Module 4.

References

• Models overview (Claude Platform Docs) · checked 2026-10-20
  Current lineup and IDs; Fable 5.1 and Opus 5.5 think adaptively 'always on'; extended thinking (budget_tokens) not accepted on later models; current docs suggest starting with Opus 5.5 when unsure.
• Steering thinking: effort, cost and pricing · checked 2026-10-20
  Effort levels and defaults; effort lives at output_config.effort; display 'summarized' vs 'omitted'; thinking billed as output tokens.
• Thinking (Claude Platform Docs) · checked 2026-10-20
  Turning thinking on and reading thinking blocks (Module 2 goes deeper).
• anthropic Python SDK 1.15.0 (installed locally) · checked 2026-10-20
  ThinkingConfigAdaptiveParam has fields type='adaptive' and display ('summarized'|'omitted'); messages.create accepts thinking and output_config.

Source notes

• Primary source: S03 of 'MSO Foundations: Developer Module 1', three tab panels.
• Discrepancy D05: the source's default is 'start with Sonnet'; Anthropic's current models overview says to start with Opus 5.5 when unsure. The lesson teaches the source rule and shows the docs recommendation as an update.
• Discrepancy D06: the source and quiz Q2 talk about reasoning on or off. On Opus 5.5 and Fable 5.1 adaptive thinking is always on, and Sonnet 5.5 rejects thinking 'disabled'; there the practical low end is a low effort setting.
• Discrepancy D03: quiz Q2 uses 'extended thinking'. Current docs call extended thinking the older manual budget_tokens mode, not accepted on later models.