Glossary
Reasoning model
A reasoning model is one trained to work a problem through in steps before it answers, which makes it much better at maths, logic and planning, and much slower and dearer to run than an ordinary one.
In plain terms
It is the difference between a colleague who answers the moment you stop speaking and one who says give me a minute and thinks it through. On a hard question the second is right far more often. On an easy one they have taken a minute to tell you something the first said instantly, and you have paid for the minute.
Why it matters
Most products now put both kinds in front of you and the default is rarely the right one for what you are doing. Sending everything to the deliberate option is a straightforward way to multiply your costs and your waiting for no gain on the majority of requests. Sending nothing to it means quietly accepting wrong answers on the small number of tasks where the working is what produces the right one. The judgement is per task rather than per organisation, which is more annoying than a policy and considerably cheaper.
How it works
The difference is in training rather than in a setting. The model is trained so that generating intermediate working before its final answer is the default behaviour, and crucially it is rewarded for working that arrives at correct answers rather than for working that reads convincingly. That second detail is what separates this from simply asking an ordinary model to think step by step.
The working is generated the same way as any other output, so it consumes the same budget and the same time. A considered answer can take many times longer and cost several times more than a direct one, even where the visible reply is a single sentence. You are paying for text you may never see, which is the part that surprises people reading their first bill.
What a product shows you is not necessarily a transcript. Some display the working in full, some show a summary prepared for readability, and some hide it entirely. A displayed summary is a rendering rather than a record, so it is useful for spotting where an answer went astray and unreliable as evidence of exactly what the model did.
The benefit is concentrated on a specific shape of task. Multi-step arithmetic, logic with constraints, planning where each step depends on the last, code that has to satisfy several conditions at once, and checking its own earlier work all improve. Recall, tone, summarising and drafting generally do not, and can come back worse, because deliberation applied to a task with nothing to deliberate about mostly adds length and delay.
Effort is increasingly a dial rather than a category. Products expose settings for how much working to allow, so one model can behave like a quick one on routine requests and a deliberate one when a problem warrants it. That is the right granularity, and it moves the decision onto whoever configures the tool, which is usually you.
How much is there to actually work through?
Seen in the wild
Put the same multi-step problem to an assistant twice, once through its quick option and once through its considered one, and compare the answers as well as the waits.
ChatGPTGive an assistant a scheduling or planning problem containing one constraint that makes the obvious answer wrong, and read what its working does with that constraint.
ClaudeSend one problem to a deliberate model and a fast one through the same routing interface, where the cost of each is shown alongside the answer.
OpenRouter
Common misconceptions
People assume
It is simply a better model, so it should be the default.
In fact
On tasks with no steps to take it adds cost and delay and returns nothing for them. Rewriting a paragraph in a warmer tone does not become more accurate for having been deliberated over. Making it the default is one of the quickest ways to multiply a bill without improving any output anyone will notice.
People assume
The working it shows me is what it actually did.
In fact
Often it is a summary prepared for display rather than a transcript of the process. That still makes it useful, because a visibly wrong step tells you where the answer went astray, but it will not support an argument about exactly how the model reached a conclusion.
People assume
Working through steps means it cannot be confidently wrong.
In fact
It reduces some errors and creates a new failure of its own. A wrong assumption in the first step gets elaborated carefully through every step after it, and the result reads more convincingly than a quick wrong answer would. Careful working towards the wrong conclusion is harder to catch, not easier.
Telling them apart
Reasoning model vs Chain-of-thought
Reasoning model
A kind of model, chosen when you pick what to run. Produces working by default because it was trained to, and trained towards working that reaches correct answers.
The intermediate steps themselves. You can get them out of an ordinary model just by asking, and often usefully.
One is a purchasing decision, the other a prompting one. Asking any model to show its steps is free and sometimes enough; a model trained for it is a different and more expensive thing.
Questions
- When is the extra wait worth it?
- When the task genuinely has steps and a wrong early step ruins the answer: multi-step arithmetic, constraint problems, planning, code with several conditions to satisfy at once. If you cannot describe what the intermediate steps would be, there probably are none, and the deliberate option is buying you delay.
- Why does it cost more when the answer is the same length?
- Because you are billed for the working as well as the reply, and the working can be many times longer than what you see. That is the classic first-invoice surprise. Where a product exposes an effort setting, it is the most direct control you have over that number.
- Can I rely on the working it shows me?
- Treat it as a useful signal rather than a record. What is displayed is frequently a summary produced for readability, so a visibly wrong step is worth acting on while the absence of one proves little. It is a good place to look when an answer is wrong and a poor basis for claiming how it was reached.
- Does it make things up less often?
- On problems with a checkable structure, generally yes. But it introduces a failure of its own, which is careful elaboration of a wrong first assumption, and that reads far more convincingly than a hasty wrong answer. Verification is no less necessary, and arguably more, because the output is more persuasive.
Key takeaways
- A reasoning model is trained to produce working before its answer, not merely asked to.
- The working is billed and timed like any other output, even where you never see it.
- It helps on tasks with dependent steps and adds cost for nothing on tasks without them.
- Displayed working is often a summary prepared for you rather than a transcript.
- A wrong first step gets elaborated convincingly, so careful working is not the same as a right answer.
Tools that use this
- ChatGPT
Quick and considered options side by side, so the trade-off is easy to feel.
- Claude
Constraint and planning problems, which is where the working earns its wait.
- OpenRouter
Cost shown next to the answer, which makes the price of deliberation concrete.
Last checked July 2026