A reasoning model is a large language model trained to produce an extended sequence of intermediate reasoning tokens before it gives its final answer, so that it can plan, calculate, check and revise its work on multi-step problems. Among language models, reasoning models form a distinct class because they spend additional computation at inference time in exchange for higher accuracy on mathematics, coding, logic and complex analysis.
The category became prominent from 2024 onward with model families such as OpenAI o1 and DeepSeek-R1, and many general-purpose LLMs now offer a switchable thinking mode. The defining shift is that answer quality depends not only on model size and training data but also on how many tokens the model is allowed to think with.
How a reasoning model produces an answer
A reasoning model generates its output in two phases. First it writes a reasoning trace, sometimes hidden from the user, in which it breaks the task into steps, tries approaches, notices mistakes and backtracks. Then it writes a concise final answer conditioned on that trace. Both phases are ordinary next-token prediction; the difference lies in how the model was trained to use the first phase.
The behavior is learned mainly through reinforcement learning with verifiable rewards. The model attempts problems whose answers can be checked automatically, such as math results or code that must pass unit tests, and is rewarded for correct outcomes. Over many iterations it discovers that longer, self-checking reasoning earns more reward, and behaviors such as verification and backtracking emerge without being scripted.
The table below summarizes the training stages commonly used to build a reasoning model.
| Stage | Data or signal | Purpose |
|---|---|---|
| Pretraining | Large text and code corpora | General language and world knowledge |
| Supervised fine-tuning on traces | Curated step-by-step solutions | Teaches the format of explicit reasoning |
| Reinforcement learning | Rewards from checkers or reward models | Strengthens reasoning that leads to correct answers |
| Distillation | Traces generated by a larger reasoning model | Transfers reasoning skill to smaller models |
Test-time compute and reasoning effort
The central idea behind reasoning models is test-time compute scaling: accuracy on hard problems tends to rise as the model is allowed to generate more reasoning tokens, up to a point. Providers expose this as a reasoning effort or thinking budget setting, which caps how many tokens the model may spend before answering.
The following table shows how the main settings trade quality against cost and speed.
| Setting | Typical reasoning length | Trade-off |
|---|---|---|
| Thinking disabled | None | Fastest and cheapest, weaker on multi-step tasks |
| Low effort | Hundreds of tokens | Modest gains with small added latency |
| Medium effort | Around a few thousand tokens | Balanced default for most hard tasks |
| High effort | Tens of thousands of tokens | Best accuracy on difficult problems, slow and costly |
Reasoning tokens are billed as output tokens and occupy the context window, so a long trace raises both cost and latency. Gains also flatten beyond a task-dependent budget, and excessive thinking on easy questions can even introduce errors, a behavior often described as overthinking.
Reasoning models compared with chain-of-thought prompting
A reasoning model is often confused with chain-of-thought prompting, the technique of asking a standard model to think step by step. The two are related, but the reasoning model has the behavior built in through training rather than elicited by the prompt.
| Approach | Where reasoning comes from | Practical consequence |
|---|---|---|
| Standard LLM | Implicit in a single forward pass per token | Fast, weaker on long multi-step problems |
| Chain-of-thought prompting | Instruction or few-shot examples in the prompt | Helps, but quality depends on the prompt |
| Reasoning model | Trained policy for long internal reasoning | Robust gains without special prompting |
| Agentic loop with tools | External planning and tool calls | Adds actions, search and code execution |
Because reasoning is already trained in, elaborate prompt engineering is less necessary and sometimes counterproductive. Clear goals, constraints and success criteria usually help more than step-by-step instructions or many few-shot examples.
When to choose a reasoning model
A reasoning model is worth its cost when a task requires several dependent steps and an error in one step invalidates the result. For short factual questions, classification or simple rewriting, a standard model is usually faster, cheaper and equally accurate.
| Task | Recommended model | Reason |
|---|---|---|
| Competition-style mathematics | Reasoning model, high effort | Long derivations benefit from self-checking |
| Debugging complex code | Reasoning model, medium effort | Needs hypotheses, tracing and verification |
| Customer chat replies | Standard model | Latency matters more than deep analysis |
| Data extraction from documents | Standard model or low effort | Mostly pattern matching, little planning |
| Multi-constraint planning | Reasoning model | Must satisfy many conditions at once |
Limitations and misconceptions
A visible reasoning trace looks convincing, but it is not a guaranteed account of how the answer was produced. Studies of faithfulness show that traces can omit factors that influenced the answer, so they should be treated as useful evidence rather than proof.
- Hallucination persists: longer reasoning does not add missing facts, and confident errors still occur.
- Cost grows quickly: reasoning tokens can exceed the length of the final answer many times over.
- Latency rises: responses may take from several seconds to minutes at high effort.
- Gains are uneven: verifiable domains improve most, while open-ended writing improves far less.
- Hidden traces limit auditing: some providers return only a summary of the reasoning.
The idea in brief
A regular language model answers like someone who replies immediately. A reasoning model answers like someone who first works the problem out on scrap paper, checks the steps and only then gives an answer.
This takes longer and costs more, but it pays off on hard problems such as math puzzles or tricky code. For simple questions, the quick reply is usually just as good.
A practical scenario
A software team uses a language model to triage failing tests in a large codebase. With a standard model, suggested fixes often address the symptom in one file while breaking behavior elsewhere. The team switches the triage step to a reasoning model at medium effort and provides the failing test, the stack trace and the relevant modules.
The model now traces the call path, proposes two hypotheses and rejects one after checking a configuration file before writing its fix. The share of suggestions that pass the full test suite on the first attempt rises noticeably, while each request takes about half a minute instead of a few seconds. The team therefore keeps the standard model for routine code review comments and reserves the reasoning model for failures that a quick model cannot resolve.