What Is a Reasoning Model? A Definition You Can Check

A reasoning model is not a new architecture. It is the same transformer with a trained habit: emit a long internal segment first, answer second. Nearly everything that makes one awkward to operate follows from where that segment lands in your bill and on your clock.

A definition you can check

Vendors describe these models with verbs — it thinks, it deliberates, it reflects before responding. None of that is checkable against anything. Three properties are, and a model either has them or does not:

• It emits tokens you did not ask for, before the answer, which you may or may not be shown.
• Those tokens are billed at the output rate — the expensive one — even when they are hidden from you.
• Their number varies between requests by an order of magnitude, and you influence it with an effort level or a token budget rather than with max_tokens.

Anything with those three properties behaves like a reasoning model whether or not it is marketed as one, and anything without them does not — however much step-by-step working appears in the visible answer. A model that writes out its steps in the response you receive is doing chain-of-thought prompting, which has a different cost profile and a different failure set.

The distinction has become blurrier in one specific way worth naming. Several families now ship as a single model with thinking as a mode — one identifier, a parameter that turns deliberation on, off, or on to a degree. That is not a third category; it is the same three properties available conditionally, and the practical consequence is that you can no longer infer behaviour from a model name. Two requests to the same identifier can differ by an order of magnitude in cost because one of them had the flag set. If you are aggregating spend by model name and wondering why the average is unstable, that is usually why.

Where the habit came from

The habit is trained, not prompted. The recipe that became public first was DeepSeek’s R1 report in January 2025, which described reinforcement learning against tasks with automatically checkable answers — competition maths, unit-tested code — with a rule-based grader scoring the final answer rather than the working. The paper documents that response length grew steadily over training as a consequence of that reward, not as a target anyone set. The model discovered that longer traces scored better, and kept going.

That origin explains the shape of everything downstream. The trace is optimised to produce a correct final answer, not to be short, not to be readable, and — importantly — not to be an honest account of how the answer was reached. See whether you can trust a stated chain of thought for what the evidence says about the last one.

Reading it off the response

The cheapest way to know what you are dealing with is to look at the usage object of a call you have already made. On the OpenAI-shaped APIs, reasoning tokens are reported in a nested field and are included in the completion total:

"usage": {
  "prompt_tokens": 812,
  "completion_tokens": 4310,
  "completion_tokens_details": {
    "reasoning_tokens": 3968
  }
}

The visible answer in that call was 342 tokens. The other 3,968 — ninety-two per cent of what you are billed for at the output rate — you never saw. If you had estimated the cost of this request from the length of the reply, you would have been out by a factor of twelve. Anthropic’s extended thinking takes the other approach and returns the trace inline as thinking content blocks, but bills them as output tokens just the same; the accounting is identical, only the visibility differs.

Do this measurement before you commit to anything, and do it on your real prompts rather than on a sample question. The ratio you are looking for is reasoning tokens over completion tokens, and it varies enormously by task: a well-specified extraction might sit at 0.2, while an under-specified planning question can sit above 0.9. That single ratio tells you what fraction of your bill is invisible, and it is the input every cost estimate in this cluster needs. It also tends to be higher than people guess, because the requests that produce long traces are exactly the ones nobody thinks to spot-check.

The control is a budget, not a limit

This is the distinction that costs people their first week. The knob you are given — an effort level, or an explicit thinking budget — is an instruction to the policy about how much to deliberate. It is not the same object as max_tokens, which is a hard truncation of the whole completion, thinking included.

The resulting bug is reliably the first one everybody hits. You set max_tokens: 2000 because your answers have always been short. The model spends all 2,000 on thinking, the completion is cut off mid-trace, and you get back a finish_reason of length with empty or truncated content — having paid full output price for a response containing nothing. OpenAI’s reasoning guide addresses this directly by recommending a large token allowance (on the order of 25,000) while you are calibrating. Anthropic enforces the relationship structurally instead: the thinking budget has a documented minimum of 1,024 tokens and max_tokens must exceed it, so the arithmetic cannot silently come out at zero.

Four things that behave differently

None of these is a defect. They are the direct consequences of moving work from training time to request time, which is the whole point — see test-time compute for what that trade buys and what it costs.