Opus 5 thinks by default — and your max_tokens pays for it

Swap claude-opus-4-8 for claude-opus-5 in an API request and nothing else in the request body needs to change. What the request does changes in three ways, each documented, each easy to miss, and each with a cost attached.

The default flipped

On the models most production workloads run today — Claude Opus 4.8, Opus 4.7, Opus 4.6 and Sonnet 4.6 — thinking is off until you ask for it: Anthropic's thinking documentation says these models leave thinking off "until you set thinking: {type: "adaptive"} in your request."

On the Claude 5 generation the same page says the opposite:

On Claude Opus 5, Claude Sonnet 5, Claude Fable 5, Claude Mythos 5, and Claude Mythos Preview, thinking is already on: no configuration needed.

Anthropic, "Thinking", platform.claude.com

So a migration that only swaps the model string silently turns reasoning on. You will not necessarily see it, either: on the Claude 5 models the display setting defaults to "omitted", meaning thinking blocks come back with an empty thinking field. The model reasons; the text of that reasoning is not returned.

Where the money goes

The same documentation is plain about the billing:

The tokens Claude spends reasoning are billed as output tokens, even when the thinking text isn't returned to you, and they count toward max_tokens alongside the response text.

Anthropic, "Thinking", platform.claude.com

That second clause is the operational trap. A classification endpoint sized at max_tokens: 500 for a 300-token answer on Opus 4.8 had 200 tokens of headroom. On Opus 5, reasoning spends from that same 500 before the answer starts. The failure mode is not an error — it is stop_reason: "max_tokens" on requests that used to complete, or answers that arrive truncated.

The only per-request evidence is in usage accounting: usage.output_tokens_details.thinking_tokens reports how many billed output tokens were internal reasoning, per the extended thinking documentation. If you monitor one new field after a Claude 5 migration, monitor that one.

The old switch now returns a 400

Teams that already controlled thinking the old way have a second migration to do. The manual configuration — thinking: {type: "enabled", budget_tokens: N} — is deprecated on the 4.6 models, and on everything newer it is gone:

Claude 4.7 and later models do not support it and reject requests that use it, returning a 400 error.

Anthropic, "Extended thinking", platform.claude.com

The documented replacement is thinking: {type: "adaptive"} with depth controlled by output_config: {effort: ...} rather than a token budget. The default effort is high.

Turning it off is model-dependent

If your workload genuinely does not want reasoning, the way out varies by model. Opus 5 accepts thinking: {type: "disabled"} — but only at effort high or below; combined with xhigh or max effort the API returns a 400. Fable 5 and Mythos 5 reject disabled outright: on those models thinking cannot be turned off at all. Anthropic also warns that Opus 5 with thinking disabled "can occasionally emit tool calls as plain text" — the model is tuned to think.

What to do before you migrate

Three checks, all cheap. First, send one representative request to both model strings and diff the usage objects — the thinking spend is right there. Second, re-examine every hard-coded max_tokens that was sized to fit an answer exactly; the ceiling now covers reasoning plus answer. Third, if you set budget_tokens anywhere, migrate it before the model forces you to — on Claude 4.7 and later it is not deprecated, it is a request that fails.

Primary sources: Anthropic's Thinking and Extended thinking documentation, read 2026-07-30.