Adaptive vs always-on thinking: the difference

Two different defaults, and neither is universal across the lineup

"Thinking" isn't a single uniform behaviour across the current model lineup — some models decide for themselves, per request, whether extended reasoning would actually help before spending tokens on it; others think on every single request regardless of whether the task warranted it, with no way to turn that off. Confusing the two, or assuming one model's thinking behaviour describes the whole lineup, is a common source of surprised bills and surprised truncated responses alike.

What adaptive thinking is actually deciding

A model with adaptive thinking evaluates the request and decides whether extended reasoning is worth the cost for that specific task — a simple, well-scoped request may get little or no thinking at all, while an ambiguous or genuinely hard one gets substantially more. This is efficient in aggregate, since it avoids paying for reasoning depth on the easy majority of requests a typical workload actually contains, but it also means thinking spend on this kind of model isn't a fixed, predictable quantity per request — it varies with what the model itself judges the task to need, which makes cost forecasting for adaptive-thinking models inherently a distribution rather than a constant.

Why always-on thinking exists despite the cost

A model with always-on thinking pays the reasoning cost on every request, including ones that didn't need it, and that's a deliberate trade for the model positioned at the top of a lineup's capability range — where the cost of an occasionally-unnecessary thinking pass is considered acceptable in exchange for never risking an under-thought answer on the requests that did need it. This is the right trade specifically for the highest-stakes tier of work, and a much worse one to apply reflexively to a workload dominated by simple, low-stakes requests where most of that thinking spend buys nothing.

What this means for budgeting

An adaptive-thinking model's per-request cost is genuinely variable and harder to forecast precisely than a fixed-price mental model assumes — budget for a distribution informed by your actual task mix, not a single number. An always-on thinking model is more predictable per request in one sense (thinking always runs) but that predictability comes at a cost floor that a lighter-weight, adaptive alternative wouldn't carry on your easier requests.

Choosing which behaviour fits your workload

If your workload is a genuine mix of easy and hard requests, an adaptive-thinking model generally serves that mix more efficiently than a uniformly always-on one, since it isn't spending on reasoning the easy majority never needed. If your workload is uniformly high-stakes — every request genuinely benefits from maximum reasoning depth — the case for always-on thinking is stronger, since there's little easy-request cost being wasted in the first place.

Testing which behaviour your workload actually has

Don't assume which category a model falls into from its position in the lineup alone — confirm it directly against that model's own documentation before building cost projections or latency expectations around an assumed behaviour. A model you've been treating as adaptive that's actually always-on, or the reverse, will throw off both your cost forecasting and your understanding of why a specific request cost what it did, in ways that are easy to misattribute to something else entirely if the underlying thinking behaviour was never confirmed directly.

A mixed workload sometimes benefits from a mixed model strategy

Where a single workload genuinely spans both easy and very hard requests, it's sometimes worth routing the easy majority to a cheaper, adaptive-thinking model and reserving an always-on model specifically for the harder subset, rather than running the entire workload through one model chosen to handle the hardest cases adequately. That split adds routing complexity, but for a workload with a wide difficulty spread, the cost difference between running everything through the more expensive option and splitting by difficulty can be substantial enough to justify it.

See the effort & thinking cost estimator for how this plays out in actual cost terms across the current lineup, and each model's own entry under model reference for which thinking behaviour it carries specifically.