Adaptive vs always-on thinking: the difference

Two separate questions hiding behind one word

"Thinking" is not one uniform behaviour across the lineup, and the confusion usually comes from collapsing two different questions into one. First: when you send nothing about thinking, does the model think? Second: can you turn it off? The current models answer those two questions in four different combinations, and budgeting or debugging against the wrong one produces surprised bills and truncated responses alike.

The four behaviours in the current lineup

Off unless asked. Opus 4.8, 4.7 and 4.6, and Sonnet 4.6, run without thinking when the field is omitted; send adaptive thinking to turn it on. On by default, can be switched off. Opus 5 and Sonnet 5 think when the field is omitted, and accept thinking: disabled — on Opus 5 only at effort high or below. On, and cannot be switched off. Fable 5, Fable 5.1 and Opus 5.5 reject every thinking configuration other than adaptive; the only control is effort. On, with a lowest setting instead of an off switch. Sonnet 5.5 rejects disabled but accepts between_tools, which does no extended thinking and is valid only at effort high or below.

"Always on" does not mean "always thinking hard"

The name misleads. On the models where thinking cannot be disabled, thinking is still adaptive: the model decides how much to think, and effort sets how much it is willing to. At a low effort level the documentation describes these models keeping their thinking short, with how often they skip it altogether depending on the prompt. So the lever for cost and latency on these models is not a thinking switch you no longer have — it is the effort level. (Opus 5.5, which lost its off switch, also defaults to a lower effort level than Opus 5 did — see its reference page before comparing the two.)

What adaptive thinking is actually deciding

A model with adaptive thinking evaluates the request and decides whether extended reasoning is worth it for that task — a simple request may get little or none, a hard one substantially more. That is efficient in aggregate, but it means thinking spend isn't a fixed quantity per request. Cost forecasting for these models is a distribution informed by your task mix, not a constant.

Reading and steering thinking you can't turn off

Two consequences follow for code. A response from these models can begin with one or more thinking blocks, and under the default display setting their text is empty — so read the content by block type, never by position. And instructions that tell the model not to think should go: it can't comply, and on Opus 5.5 such rules make it more likely to leak internal tags into the visible answer.

If you need less thinking, lower effort first. On Opus 5.5, a system-prompt line such as "Answer directly without deliberating." can trim it further, at some risk to accuracy that you should measure. On Sonnet 5.5, from medium upward the model thinks briefly before almost every reply, and a request to think less has almost no effect — low is the lever that works.

What this means for `max_tokens`

Thinking draws from the same output budget as the visible answer, whether or not its text comes back to you. Any route that moves from an off-by-default model to one where thinking is on — or can no longer be turned off — needs max_tokens re-sized for thinking plus the reply, or the answer truncates after the reasoning.

Testing which behaviour your workload actually has

Don't infer a model's behaviour from its position in the lineup: confirm it against the model's own reference page before building projections. A router or fallback chain that spans behaviours needs to branch explicitly — a between_tools setting sent to any model but Sonnet 5.5 is a 400, and a disabled setting sent to Opus 5.5 is too.

See the effort & thinking cost estimator for the cost side, and each model's page under model reference for its exact thinking row.