Reasoning Models
Deep thinking means writing a long draft before answering, and the draft is billed as output. One test decides: does this task need multi-step reasoning?
Deep thinking is not a smarter model; it is a model that writes a long draft before it answers — and that draft is billed as output. So the question is not whether it is stronger. The question is whether this task is worth the money.
After reading, you should be able to answer:
- Why does making a model think before answering actually improve accuracy?
- Which kinds of tasks waste money when deep thinking is on?
- Why can you not hand the "thinking process" to users as evidence?
It is not smarter, it wrote a draft first
First recall how it normally works: it predicts one token at a time and strings them together. No separate phase exists in which it can work things out quietly before speaking. Its thinking is the text it writes.
A reasoning model is a change layered onto that mechanism: before it gives the final answer, it is made to produce a long stretch of derivation — breaking the problem apart, listing the intermediate steps, going back over its own assumptions. That material is usually invisible to users, either hidden or tucked into a "thinking" panel. The core finding of the chain-of-thought paper lines up with this: once the intermediate steps are written out explicitly, each later prediction can read the reasoning that precedes it, and the error rate falls. chain-of-thought
Why does that help? In this mechanism, writing more amounts to computing more. Hand it a problem that takes several steps to work through and demand the answer outright, and you are asking it to leap straight to the end; have it write the intermediate steps and you have left it several chances to change its mind along the way. The mechanism behind that was covered separately in Writing the Intermediate Steps Paves the Way; what is new here is that it became the default behaviour — later reasoning models used reinforcement learning to train that "derive first, answer after" habit directly into the weights, with clear gains on math and code. deepseek-r1
The draft is billed as output
The most important product fact: the draft is billed at output rates, and output rates are often several times the input rate.
So a reasoning model is expensive mostly because of how much more it emits, not because its unit price is set higher. The user sees a short answer while ten times as much derivation may have been generated behind it — and you pay for that derivation too.
Budgeting for it brings two knock-on effects. It is slow: the derivation has to be emitted one token at a time, and the user simply waits. And latency becomes unpredictable: hard questions take long, easy ones do not, so response time for the same feature swings around — a headache for loading-state design.
So when you estimate cost, account for that stretch separately: measure what a reasoning model actually emits rather than substituting the length of the answer.
Switching it on globally is the common waste
The usual mistake is not failing to enable it when needed. It is the reverse: switching it on globally and calling it done. That pays three prices at once — cost scaled by output volume, longer waits, and unpredictable response times — while most requests never needed it.
The workable setup is tiering: most requests go to a regular model, and only the slice identified as complex is routed to a reasoning model. Route on the shape of the task, not on which toggle a user happened to pick: does it span multiple steps, is there an intermediate result you can check, and how costly is it to take back a wrong answer? How to build that tiering, and how to fall back when the primary model is unavailable, is the subject of Choosing and Degrading Models.
Tiering has a second benefit that is easy to miss: it makes cost attributable. With deep thinking on for everything, a rising bill tells you nothing about which class of task ate it. With tiers, you can see which one is expensive — and whether it is worth it.
The dividing line is intermediate steps
Sorting a request into a tier takes no list of tasks. Ask one question: does this task have intermediate steps worth writing down? If it does, that is where the model earns its keep; if it does not, the money and the wait buy nothing.
- With intermediate steps. A calculation that only lands after several layers of derivation, a fault that only clears once several constraints hold at the same time, a choice between options whose costs have to be compared line by line. The derivation is itself a useful product here — every step written out gives the next judgment a chance to catch an error.
- Without intermediate steps. Sorting a stretch of free text into a category, copying fields into a structured record — the answer settles in one step, so more thinking only restates the same call in different words. Converting one format into another has no separable reasoning inside it. And wherever a user is waiting on screen, the delay costs the experience far more than the accuracy is worth.
If unsure, run a controlled comparison: take a batch of real samples, run them with the setting on and off, and put the accuracy gain and the cost gain side by side. If accuracy barely moves, reasoning depth was never the bottleneck for that task.
The thinking process is not evidence
The last trap is costly. The "thinking process" shown in the interface is not the computation actually running inside it. It is generated text as well, merely content that looks like reasoning, produced by the same prediction machinery. Derivation that reads perfectly while the conclusion is wrong is common; so is the reverse, derivation with an obvious hole that still lands on the right answer. Whether the derivation is right and whether the conclusion is right are two independent things.
So two things are off the table: do not treat that process as auditable evidence for users or in compliance material, and do not relax your checks on the conclusion just because the derivation looked rigorous. Verify as usual — a reasoning model lowers the odds of fabrication without changing the mechanism, and fabrication remains its default behavior.
Whether to turn deep thinking on comes back to one question: what does this extra output buy? To answer that, you have to see how output is priced and how it grows with length — that is Tokens and Billing Units.
