What Is a Reasoning Model?
A reasoning model is a configuration trained to produce an extended stretch of intermediate working before its final answer, and to spend a controllable amount of compute on it. The working is generated by the same next-token process as the answer that follows it. What sets the configuration apart is that the behaviour was trained in rather than requested, and that the length of the working is a parameter of the call rather than a sentence in the prompt.
What is genuinely different, and what is only packaged differently
Trained rather than prompted. Chain-of-thought prompting asks a general configuration to show its working; here the working appears without being asked for, because producing it is what the training rewarded. The usual recipe rewards final answers that can be checked mechanically — an arithmetic result that matches, a program that passes its tests, a puzzle whose constraints are satisfied — and leaves the intermediate text free to become whatever reaches those answers, which is why the working often does not read like an explanation written for a person.
Budgeted rather than instructed. How much working is produced is exposed as a setting on the call: an effort level, or a budget of tokens. It moves cost and latency rather than format, and it is set by whoever makes the call rather than argued for inside the prompt. An instruction whose only purpose is to elicit working therefore has nothing left to elicit, and reads as one more sentence in the context.
Returned, summarised, or withheld. What comes back varies between deployments. The working may be returned in full, returned as a shortened account of itself, or kept back while still being generated and charged for. Anyone intending to store the working as a record of how an answer was produced needs to know which of the three they are being given, because a shortened account is a description of the working rather than the working.
And what is not different at all: it is one sequence of tokens produced from left to right, and the working conditions the answer because it is in the context when the answer is generated. There is no separate deliberation engine underneath, and no second procedure being reported on. That is the same mechanism a prompted chain uses; the training and the budget are what changed around it.
| Effect | What happens on the call |
|---|---|
| Output tokens | The working is generated and billed as output, whether or not any of it is returned to the caller. |
| The output allowance | It counts against the same cap as the answer, so a long segment under a small cap can leave no room for a conclusion. |
| Latency | The answer begins only once the working ends, so time to the first token of the answer rises with the budget. |
| The next turn | Whether the working is carried forward is a deployment decision. Where it is dropped, a later turn starts without it. |
| Verification | Nothing in the segment checks the answer. A check is a separate step, and a wrong answer under long working is still a wrong answer. |
Every row is paid on each call, before anyone knows whether the question needed it. That is the practical shape of the trade: the budget is chosen in advance of the question being understood, and the working is generated whether or not the question had steps in it.
Where the extra tokens pay for themselves, and where they do not
The tasks that reward the working are the ones carrying intermediate state that can be got wrong: arithmetic carried across several stages, a constraint that has to hold across a whole assignment, a derivation whose third line depends on its second, code whose behaviour depends on a branch taken four calls earlier. In each of those the intermediate text holds a value that would otherwise have to be held implicitly, and holding it explicitly is the whole of the mechanism.
Tasks with no intermediate state pay the same bill for nothing. Pulling a fact out of a supplied passage, converting a document into a requested format, sorting a short message into one of a list of labels: the working is generated, charged for and thrown away, latency rises, and the answer is the answer it would have been. The consequence is unglamorous and it belongs in an architecture rather than in a prompt — a cheap step that decides which class of configuration a request is worth costs less than paying the largest budget on every request, which is the reason routing exists as a component at all.
And the working that comes back is not a record of a procedure. Where a deployment returns a shortened account rather than the tokens themselves, what the caller holds is a description written after the fact, and filing it as an audit trail gives it a standing the deployment does not claim for it. Even where the raw segment is returned, it was produced under the same process as the answer, so it can be internally tidy and arrive somewhere the answer does not follow from. Anything that has to hold — a figure, a citation, a schema — is confirmed by checking the answer against the thing it refers to. The working is at best a place to look for where a wrong answer went wrong.
How the Registry classifies a routed multi-step computation
Sending an arithmetic workload to a configuration that emits its intermediate working is filed as data processing in this registry's classification. The classification follows the work rather than the routing: what is submitted is a computation over supplied quantities, and the choice of where to send it is a property of the submission rather than a second task. The routing decision does not enter the derivation at any point — the configuration named on the order does.
The Registry's canonical brief for this entry is filed as:
Route a multi-step arithmetic workload to a configuration that emits intermediate working before its answer.
Submitted for assessment it is
classified as Data processing, and its wording is hashed once — to
3e86e8c11ec19209…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/analysis.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about reasoning model
Whether a longer working segment improves any given result is a measurement, and this registry has taken none: it does not run the workload, does not compare one configuration against another, and publishes no figure for either. The canonical brief above fixes no budget, no routing rule and no threshold for what counts as multi-step. It fixes a wording, and the wording is what is hashed.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about reasoning model
- What is a reasoning model?
- A reasoning model is a configuration trained to emit an extended stretch of intermediate working before its final answer, with the amount of that working exposed as a setting on the call. The working and the answer are produced by the same generation process; the training and the budget are what distinguish the configuration.
- How does it differ from chain-of-thought prompting?
- Chain-of-thought prompting is a request made inside the prompt to a general configuration. Here the working is trained behaviour that appears without being asked for, and its length is a parameter of the call. Both put intermediate text ahead of the answer; they differ in what causes it to be there and in what controls how much of it there is.
- Are reasoning tokens billed?
- The working is generated as output and billed as output, including where the deployment does not return it. It also counts against the output limit of the call, which is why a small limit combined with a long budget can produce a truncated response containing no answer.
- Does an instruction to think step by step still help?
- There is nothing left for it to elicit. The working is produced whether or not the prompt asks for it, and the amount is changed by the budget setting rather than by wording. The instruction is not harmful; it simply occupies context without doing the job it was written to do.
- When is a reasoning configuration the wrong choice?
- Where the task carries no intermediate state that can be got wrong — a lookup from supplied text, a format conversion, a short classification. The working is generated and charged for regardless, so the cost is paid, the latency is paid, and the answer is unchanged. That is the case a routing step exists to catch.
Related entries
Chain-of-thought prompting · Tree of thoughts (ToT) · Context window
Order an assessment for data processing tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.