AI / Claude OPUS & Sonnet 5.5 Interview questions

Claude Sonnet 5.5 is the Sonnet-tier model in Anthropic's 5.5 generation, positioned as the best combination of speed and intelligence. Its Claude API model ID is claude-sonnet-5-5.

It offers a 1M-token context window and up to 128K output tokens, priced at $2 per million input tokens and $10 per million output tokens. Thinking is adaptive, the default effort is high, and latency is rated Fast.

It follows Claude Sonnet 5 and is the cheaper, quicker sibling of Claude Opus 5.5.

Claude Opus 5.5 is the Opus-tier model of the 5.5 generation, built for long-running agentic coding and knowledge work. The API model ID is claude-opus-5-5.

It shares the 1M-token context window and 128K max output with Sonnet 5.5, but costs $4 per million input tokens and $20 per million output tokens, with Moderate latency.

Adaptive thinking is always on and cannot be disabled; the default effort is medium.

On the Claude API the IDs carry no date suffix. Use the bare string for each tier:

Amazon Bedrock and Google Cloud use their own identifiers. Each model page lists them under Availability, so copy from there instead of guessing.

List prices per million tokens (MTok) are below, with two other models for context:

Opus 5.5 costs exactly twice Sonnet 5.5 on both input and output. The Message Batches API takes 50% off input and output. Check the full price list for caching rates.

Both Opus 5.5 and Sonnet 5.5 give you a 1M-token context window and 128K max output tokens per request.

On the Message Batches API, both can reach 300K output tokens with a beta header (see the batch question later).

A token is not a word. On the current tokenizer, 1M tokens is roughly 555k words, or about 2.5M Unicode characters. Size your inputs in tokens.

With adaptive thinking the model decides whether to reason and how deeply, per request, guided by the effort setting. You do not hand it a fixed token budget.

On Opus 5.5 it is always on. On Sonnet 5.5 it is on when you send no thinking field, and sending the field below is equivalent:

thinking = {"type": "adaptive"}

By default the thinking text is not returned (display is omitted), but you can request a display value that returns it.

The two models differ. Opus 5.5 defaults to medium; Sonnet 5.5 defaults to high.

Effort is the dial for thinking depth, latency, and cost. Sonnet 5.5 accepts levels up to xhigh and max through adaptive thinking, so you can go beyond its default for hard tasks.

Because defaults differ, a prompt tuned on one model will not cost or behave the same on the other until you set effort explicitly.

between_tools is the lowest thinking setting on Sonnet 5.5. It turns off up-front thinking, and it replaces the old disabled value.

thinking = {"type": "between_tools"}

It needs no beta header and works on every platform that offers Sonnet 5.5. It is accepted at low, medium, and high effort. The short progress notes the model writes between tool calls still come back as thinking blocks.

Opus 5.5 has no such setting, because its thinking cannot be turned off.

Forced tool use means setting tool_choice to {"type": "any"} or {"type": "tool", "name": "..."} so the model must call a tool.

Claude Sonnet 5.5 does not support it: such a request returns a 400 invalid_request_error. The Opus 5.5 release notes list the same change as a breaking change.

Use {"type": "auto"} instead and make the tool requirement explicit in the prompt.

Both Opus 5.5 and Sonnet 5.5 can cache a prompt prefix of 512 tokens or more.

A shorter prefix is simply too small to be cached, so a 300-token system prompt gets no caching benefit on its own. Pad it with real, stable context (tool definitions, reference text) if repeated calls share it.

Cached reads are billed at a discounted rate; see the pricing page for the exact figure.

The Message Batches API gives a 50% discount on both input and output tokens for Opus 5.5 and Sonnet 5.5.

Batches are asynchronous, so they suit evals, bulk classification, and backfills, not interactive chat.

Standard requests cap at 128K output tokens. On the Message Batches API, Opus 5.5 and Sonnet 5.5 can produce up to 300K output tokens when you send the beta header:

anthropic-beta: output-300k-2026-03-24

It helps with very long single outputs such as large generated documents or code bases. Without the header the 128K limit applies.

It is the computer-use toolset the 5.5 models need on the Claude API and Google Cloud. Declare it in tools like this:

{"type": "computer_toolset_20260801"}

The older computer_20251124 tool is rejected there with a 400 error. Amazon Bedrock is the exception: Sonnet 5.5 still accepts the earlier tool on that platform.

Browser use and integrations already built on the toolset need no change.

In the 5.5 generation, thinking blocks are bound to the model and the conversation that produced them. A block from one model may not be readable by another.

Moving from Sonnet 5 to Sonnet 5.5 keeps the reasoning. Moving from Sonnet 5.5 to any other model means the turns after the switch run without that reasoning.

If a request contains blocks the target model cannot read, the API drops them before the model sees them. The request still succeeds and dropped blocks are not billed. Always pass thinking blocks back unchanged.

The advisor tool lets the model you call consult a separate advisor model. Some pairings are not allowed: Sonnet 5.5 rejects Claude Opus 4.8, Claude Opus 4.7, and Claude Sonnet 5 as advisors.

Whatever advisor Sonnet 5.5 accepts, its advice comes back encrypted as an advisor_redacted_result block. Your client cannot read the advice text.

Check the advisor tool's model-compatibility table before wiring a pair, because the supported list changes between releases.

Anthropic offers a lower-latency version of Opus 5.5 on the Claude API as a research preview. It is priced separately from the standard model.

Choose it when you need Opus-level capability but standard Opus latency is too slow, for example an interactive coding assistant. Check the model page for current availability, since previews change.

It is a speed variant, not a different model tier.

From smallest to largest: Haiku (Haiku 5.5, claude-haiku-5-5), Sonnet (Sonnet 5.5), and Opus (Opus 5.5).

Above Opus sits the Mythos tier. Its current models are Claude Mythos 5.2 and Claude Fable 5.2, which share one underlying model; Fable adds extra safety measures for biology and cybersecurity. Claude Mythos Preview is not public and is used by a small set of organizations under Project Glasswing.

For interviews, know where Opus 5.5 and Sonnet 5.5 sit: the everyday upper and middle tiers.

Anthropic's models overview lists June 2026 for both. For comparison, Claude Sonnet 5 shows January 2026 and Claude Haiku 4.5 shows February 2025.

Anything after the cutoff is not in the training data. For recent events, library versions, or prices, give the model a search or retrieval tool rather than trusting recall.

Ask for current facts in your prompt flow, not in your assumptions.

Price and size are unchanged: both are $2 / $10 per MTok with a 1M window and 128K output. The changes are behavioural, and several break existing code.

A text-between-tool-calls change also alters the response shape without failing requests.

Four breaking changes hit code already running on Opus 5:

1. Thinking cannot be disabled; control depth with effort.
2. Forced tool use returns an error.
3. Thinking blocks are tied to the model and conversation.
4. On the Claude API and Google Cloud, the earlier computer_20251124 tool is no longer accepted.

The first three also apply to the Fable models. If your Opus 5 integration sends none of these patterns, the upgrade is mostly a model-ID swap, but run evals anyway.

Capacity limits match, so the choice is about capability per dollar and latency, not about how much you can send.

Pick Sonnet 5.5 when latency or cost drives the design: chat assistants, high-volume extraction, routing, and tool-light workflows. It is half the price and rated Fast.

Nothing in capacity pushes you to Opus, because both share a 1M window and 128K output. Start on Sonnet, build evals, and escalate only if you can show a measurable gap.

For tool-driven tasks that do not need up-front reasoning, between_tools trims latency further.

Choose Opus 5.5 for long-running agentic coding, multi-step knowledge work, and tasks where a failed run is expensive in engineer time or customer impact.

It costs twice as much per token, but a model that finishes in one run can beat a cheaper one that needs retries and human cleanup. Measure cost per completed task, not per token.

If Opus latency hurts, the lower-latency Opus 5.5 research preview is worth a look.

On Opus 5.5 adaptive thinking is always on. Anthropic removed the off switch, so a request that tries to disable thinking is rejected rather than silently ignored.

The control you have instead is effort. Lowering it makes the model reason less on easy requests, which cuts latency and cost without code that fights the model's design.

This is one of four breaking changes from Opus 5, so audit any shared client wrapper that hard-codes a thinking type.

Replace disabled with between_tools. Before and after:

# Sonnet 5
thinking={"type": "disabled"}

# Sonnet 5.5
thinking={"type": "between_tools"}

1. Keep effort at high or below (low, medium, high).
2. Do not change effort mid-conversation.
3. Pass any thinking blocks back unchanged with the assistant turn.

If your request uses no tools, the response is plain text, just like disabled on Sonnet 5.

The request returns a 400 error. between_tools only works at low, medium, and high effort.

To run at xhigh or max, use adaptive thinking: omit the thinking field or send {"type": "adaptive"}.

between_tools also accepts no other thinking fields. Sending display, budget_tokens, or block_binding with it returns a 400 as well.

With between_tools, effort is locked for the conversation. A per-message output_config.effort that differs from the level in effect returns a 400.

If your product raises effort for hard turns and lowers it for easy ones, use adaptive thinking instead.

History also matters: with between_tools, keep the conversation append-only, or remove thinking blocks from any edited turn onward.

Combine strict tool use, tool_choice: auto, and a clear instruction in the prompt:

client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    tools=[{**t, "strict": True} for t in tools],
    tool_choice={"type": "auto"},
    messages=[{"role": "user",
        "content": "What is the weather in Paris? Use the get_weather tool."}],
)

strict guarantees that any call the model makes matches the tool's input_schema. It does not force a call, which is why the prompt must say the tool is required.

Setting temperature, top_p, or top_k to a non-default value returns a 400 error on Claude Sonnet 5.5.

Remove those parameters and steer behaviour through the prompt and the effort setting. The Sonnet 5.5 page documents this; check the Opus 5.5 page for your own target before assuming the same rule there.

Shared client code that injects temperature=0 for determinism is the usual culprit after a migration.

Four changes on the Claude API or Google Cloud:

1. Remove the old beta header.
2. Replace the tools entry with {"type": "computer_toolset_20260801"}.
3. Update the agent loop to handle the toolset's member tool_use blocks and batch actions.
4. Read toolset_name in results.

Requests that still declare computer_20251124 get a 400 on those platforms. On Bedrock, Sonnet 5.5 still accepts the earlier tool.

On Sonnet 5.5, text the model writes between tool calls comes back in thinking blocks. The default display is omitted, so an app that only streams text blocks shows nothing during those gaps.

Two fixes: set a display value that returns the text, or turn off up-front thinking with between_tools, where the short progress notes arrive as thinking blocks with summary text.

The request never fails, which is why this bug is found by users, not by tests.

sequenceDiagram
participant App
participant API as Claude API
App->>API: Request with tools and thinking between_tools
API-->>App: Short progress thinking block and tool_use
App->>App: Run the tool
App->>API: tool_result and the thinking block unchanged
API-->>App: Final text answer

Each turn the model may emit a short progress note as a thinking block, then a tool_use. Your app runs the tool and sends the tool_result.

Send the thinking block back unchanged with the assistant turn. The model then receives the full note it wrote, not just the summary shown to you.

It controls what the API does when a request carries thinking blocks that do not match the model. You send the beta header thinking-binding-controls-2026-08-01 and set thinking.block_binding.prefix_mismatch_behavior to "drop_block".

On accounts created earlier, setting that field to either value turns the check on for that request.

It works only with thinking: {"type": "adaptive"}. With between_tools, keep history append-only or remove thinking blocks from the edited turn onward.

With server-side fallback, a between_tools request that falls back to Claude Sonnet 5 runs there with thinking: {"type": "disabled"}.

That mapping makes sense: Sonnet 5 does not know between_tools but does accept disabled, so the fallback keeps the same meaning, no up-front thinking.

Remember that thinking blocks are model-bound, so reasoning from the primary model is not carried into the fallback.

Effort sets thinking depth, so it moves latency, cost, and quality together. Sonnet 5.5 defaults to high.

A launch-day third-party test of a coding task reported that medium used roughly half the tokens and cost of high (about 6.2k versus 11.9k tokens) while matching its scores, whereas low dropped on one check set. Treat that as a data point, not a rule.

The practical approach: pick a representative eval, run it at low, medium, and high, and choose the cheapest level that holds your quality bar.

Opus 5.5 defaults to medium and cannot turn thinking off, so effort is your only reasoning dial.

Raise it to high, xhigh, or max for hard multi-step work: large refactors, ambiguous debugging, or planning where an early mistake compounds. Drop to low for simple lookups where depth adds cost, not value.

Raise effort per task type, and confirm with evals, since deeper reasoning also means more output tokens billed at $20 per MTok.

Stack the levers, cheapest first:

1. Use Sonnet 5.5 instead of Opus 5.5: half the per-token price.
2. Send non-urgent work through the Batches API for 50% off ($1 / $5 per MTok).
3. Keep stable prefixes of 512+ tokens cacheable.
4. Lower effort, or use between_tools where no up-front reasoning is needed.
5. Trim output length; output tokens cost five times input.

Measure cost per successful task after each change, so savings do not hide a quality drop.

Caching works on a stable prefix. Put content that never changes first (system prompt, tool definitions, reference documents), and variable content last.

"system": [{
  "type": "text",
  &quot;text&quot;: &quot;<long, stable instructions>&quot;,
  &quot;cache_control&quot;: {&quot;type&quot;: &quot;ephemeral&quot;}
}]

The prefix must reach 512 tokens. Avoid inserting timestamps or user IDs near the top, because any change in the prefix invalidates what follows it.

Work through the usual suspects:

The error message usually names the cause, and for disabled it points straight to between_tools.

Three migration patterns cause most failures:

Also check that thinking blocks are returned unchanged and are not mixed across models in one conversation.

Grep shared SDK wrappers first, since one helper often sets these for every call.

All three list a 1M window and 128K output, and Opus 5.5 and Fable 5.1 keep adaptive thinking always on.

Fable is the premium step: five times Sonnet's price. Use it only when evals show Opus 5.5 falling short.

flowchart TD
A["Change model ID to claude-sonnet-5-5"] --> B{Sends thinking disabled?}
B -- Yes --> C["Switch to between_tools"]
B -- No --> D{Forces tool_choice?}
C --> D
D -- Yes --> E["Use strict tools and tool_choice auto"]
D -- No --> F{Uses computer_20251124?}
E --> F
F -- Yes --> G["Move to computer_toolset_20260801"]
F -- No --> H["Remove budget_tokens and sampling params"]
G --> H
H --> I["Check display of inter-tool text"]
I --> J["Run evals and tune effort"]

Do the steps in this order because each one removes a hard 400. Evals come last, since they only make sense once requests succeed.

Do not forget advisor pairings: Opus 4.8, Opus 4.7, and Sonnet 5 are rejected as advisors.

flowchart LR
A["Sonnet 5.5 turn"] --> B{Task too hard?}
B -- No --> A
B -- Yes --> C["Switch model ID at a turn boundary"]
C --> D["API drops unreadable thinking blocks"]
D --> E["Opus 5.5 runs without prior reasoning"]
E --> F["Visible summary carries the state"]

Switch at a turn boundary. Because thinking blocks are model-bound, Opus 5.5 does not see Sonnet's reasoning. The API drops those blocks, the call still succeeds, and they are not billed.

So put what matters in visible text, such as a short state summary, before switching. Keep history append-only to avoid mismatches.

Sonnet 5.5 is already rated Fast, so tune the remaining levers:

• Use between_tools for tool-driven flows that do not need up-front reasoning.
• Run at medium or low effort where evals allow; avoid max.
• Cache stable prefixes of 512+ tokens to cut input processing.
• Stream, and make sure inter-tool text is displayed (display value or between_tools).
• Keep outputs short.

Do not use the Batches API for this; it trades latency for a 50% discount. If you need Opus capability, the Opus 5.5 lower-latency preview exists.

Anthropic publishes safety evaluations and deployment decisions for each model; the Sonnet 5.5 and Opus 5.5 pages link to them. Read the source, not a summary, before an enterprise review.

A launch-day third-party write-up of the Sonnet 5.5 system card reported that it crosses no new RSP threshold and rates alignment risk as low, while noting findings that matter for production use.

Treat that as secondary reporting and verify against Anthropic's own page.

Use the Models API, which reports a model's limits and capabilities so your code does not hard-code them.

curl https://api.anthropic.com/v1/models/claude-sonnet-5-5 \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

Do this at startup or in a health check. When a limit or capability changes, such as supported thinking types, your service notices without a code release.

The current tokenizer, introduced with Claude Opus 4.7, turns the same text into more tokens than older models did. A 1M window holds about 555k words now, versus about 750k on earlier models.

Two consequences: budgets set in words need recalculating, and the same document costs more input tokens than it did before.

Count tokens with the API's token counting rather than estimating from character counts.

A common pattern is Sonnet 5.5 as the default worker and Opus 5.5 for the hard steps. Route by task type, or escalate when the cheap model fails a check.

• Delegate planning or review steps to Opus 5.5; keep bulk execution on Sonnet.
• Consider the advisor tool, noting its pairing limits and encrypted results.
• Switch at turn boundaries and carry state as visible text, since thinking blocks do not cross models.

Track cost per completed task to confirm that the routing pays off.

Treat it as a migration with evals, not a drop-in swap.

1. Replay a golden set of real prompts on the old and new model.
2. Fix every 400 first (thinking, tool_choice, sampling, computer tool).
3. Compare task success, tool-call correctness, and output length.
4. Compare token usage and cost per task at each effort level.
5. Confirm the UI still shows text between tool calls.
6. Shadow a slice of live traffic, then ramp up.

Keep the previous model ID as a rollback path until the metrics hold for a full traffic cycle.

Effort changes how many thinking tokens are spent, and thinking tokens are billed as output. That is why the same prompt can cost very different amounts at different effort levels.

Sonnet gives you more knobs (including between_tools); Opus gives you one (effort) and a higher price per output token.