Reasoning Models: Thinking Before Answering
A reasoning model generates intermediate steps before answering. What changes versus a standard LLM, when its cost and delay pay off, and how to design for it.
What changes compared with a standard LLM?
A classic LLM generates the answer directly, token by token. A reasoning model first produces a chain of intermediate steps. That chain may be visible to the user, partly visible or fully internal, depending on the product. In OpenAI’s API, for example, reasoning tokens are not returned, but they take up space in the context window and are billed as output tokens.
There is an earlier idea worth knowing: chain of thought. In 2022, Wei and colleagues showed that when the prompt includes examples with intermediate steps, a sufficiently large model does better on arithmetic, commonsense and symbolic reasoning problems. Reasoning models build that behavior into their training instead of relying on the prompt to ask for it.
How are they trained? The paper that introduced DeepSeek-R1 describes two paths. DeepSeek-R1-Zero was trained with large-scale reinforcement learning, without supervised fine-tuning as a first step, and developed reasoning behaviors on its own, though with poor readability and language mixing. DeepSeek-R1 adds cold-start data and multi-stage training before reinforcement learning, and reaches performance comparable to OpenAI-o1-1217 on reasoning tasks. What matters for design: these models improve mostly where the answer can be verified, such as math and programming.
Why does this matter to a designer?
Because reasoning has a visible cost in the experience:
- Latency. Generating more text takes more time. An answer that takes 20 seconds needs a different interface pattern from one that appears in a second. See LLM latency and progress for long tasks.
- Cost. Reasoning tokens are billed as output, even if the user never sees them. More reasoning means more cost per answer. See cost per token.
- Transparency. Showing the steps can build trust, but it can also expose intermediate mistakes that confuse people. Decide what is shown and in what form.
- Modes. Many products offer a choice between a fast answer and a reasoned one. That control is part of the design.
How do you control how much a model reasons?
Providers expose different controls, and they are worth knowing because they are design levers:
| Provider | Control | What it does |
|---|---|---|
| OpenAI | Reasoning effort level (for example low, medium, high) | Higher effort usually means more reasoning and more billed tokens |
| Anthropic | Thinking budget (budget_tokens) | Minimum of 1,024 tokens and always below max_tokens; it is a target, not a strict cap |
Names and values change across models and versions, so check the documentation for the model you use. Two practical consequences: the output token limit includes reasoning tokens, and OpenAI recommends leaving generous headroom (at least 25,000 tokens when you start experimenting) so the model does not run out of space before it answers. If the limit is too low, the visible answer can come back empty or cut off.
When NOT to use it?
For simple tasks, short writing, classification or autocomplete. There, reasoning adds waiting and cost without an improvement the user notices. It is also a weak fit when the task cannot be verified: long reasoning does not guarantee a correct conclusion, only a text that looks more worked out.
There is an additional risk: more reasoning is also an attack surface. The OverThink research showed that decoy puzzles can be hidden in content the model reads (a web page, a document) to force it to reason more, with slowdowns of up to 18 times on one test set and 46 on another, without changing the final answer. That is why you should set token and time limits.
How to decide
Before turning reasoning on by default, check three things:
- Does the task have steps, rules or a way to verify? If not, it probably does not need it.
- Can the user wait? If the answer is expected instantly in the interface, reasoning has to justify the delay.
- What does the answer cost? Multiply by expected volume before choosing it for the whole app.
A practical rule: start with the lowest effort, measure whether quality is enough with an evaluation of your own cases, and move up a level only if needed.
Example
Illustrative example: an internal tool checks whether a component specification meets accessibility rules made of several chained criteria. With a standard model, it answers quickly but sometimes skips a criterion. With reasoning, it takes longer and catches the skipped one. The team uses reasoning only when someone presses “Full review”, and shows a progress indicator listing the criteria being checked. The user understands the wait, and the result is more reliable.
Common mistakes
- Turning reasoning on for everything without measuring cost or latency.
- Trusting that long reasoning equals a correct answer.
- Showing the full reasoning to users who only need the conclusion.
- Leaving the interface without a progress indication during a long wait.
- Setting a very low output token limit and getting empty answers because reasoning used up all the space.
- Comparing models on math benchmarks when your case is writing. See how to read benchmarks.