# Reasoning models

Reasoning models think step by step before answering, spending more computation at inference time to solve harder problems. Learn how they work and when to use them.

## Overview

A reasoning model is a large language model that writes out a long chain of intermediate thinking before it gives its final answer. Ordinary chat models also produce text one token at a time, but they usually go straight to the answer. A reasoning model is trained to slow down first. It breaks a problem into parts, tries an approach, checks it, and sometimes backtracks, all before it commits to a reply.

The key idea is that extra computation at answer time, often called test-time compute, can buy accuracy. A model that is allowed to "think" for a thousand tokens can solve maths, coding and planning problems that the same model would get wrong if it answered at once. The cost is more latency and more tokens billed. So reasoning models are a tool for hard problems, not a default for every request.

An everyday analogy helps. Ask a friend "what is 7 times 8?" and they answer instantly. Ask them to plan a week of meals for a family with three different diets on a fixed budget, and they reach for a pen and paper. They write lists, cross things out and check totals. A reasoning model is a language model that has learned when and how to reach for the pen and paper.

## What it is

A reasoning model is not a new architecture. Most are ordinary decoder-only transformers, as described in [GPT architecture](/tools/gpt-architecture). What changes is the training and the way the output is structured.

| Part | What it does |
|---|---|
| Base model | A pre-trained language model that already knows language, facts and code |
| Reasoning trace | The intermediate "thinking" tokens produced before the answer |
| Final answer | The short, user-facing response written after the trace |
| Reinforcement learning stage | Training that rewards correct final answers, which shapes useful reasoning habits |
| Reward signal | A checker, test suite or reward model that scores outputs |
| Thinking budget | A limit on how many reasoning tokens the model may spend |

The reasoning trace may be shown to the user, summarised, or hidden, depending on the provider. Either way it consumes tokens and time. Many current models are "hybrid": the same model can answer quickly or think at length, controlled by a setting or a token budget.

## Where it came from

The roots lie in prompting research. In 2022 researchers at Google showed that asking a model to write out its steps, called chain-of-thought prompting, improved results on arithmetic and logic tasks. The same year, another paper showed that simply adding "Let's think step by step" to a prompt helped. Self-consistency, also from 2022, sampled several chains and took a majority vote over the final answers. These methods proved that models could reason better when given room to write.

The next step was to train for it. In 2023 OpenAI researchers published work on process supervision, rewarding each correct step in a maths solution rather than only the final answer. In September 2024 OpenAI announced o1, a model trained with large-scale reinforcement learning to think before answering, and reported that accuracy rose both with more training compute and with more thinking time at inference. This made test-time compute a second scaling axis next to model size.

In January 2025 DeepSeek released DeepSeek-R1 with open weights under the MIT licence, together with a paper describing its training. The paper showed that reinforcement learning with automatically checkable rewards, using a method called Group Relative Policy Optimisation (GRPO), could make long reasoning emerge. Since then most major labs have shipped reasoning or hybrid models, and "thinking" modes are now a standard feature of frontier systems. For one open family see [DeepSeek V4.1](/tools/deepseek-v4-1).

## How it works

### Step 1: Start from a strong base model

Reasoning training does not create knowledge from nothing. It starts with a model that has already been pre-trained and usually instruction-tuned with [supervised fine-tuning](/tools/sft).

### Step 2: Collect problems with checkable answers

Training needs tasks where correctness can be verified automatically. Maths problems with known numeric answers and coding problems with unit tests are the classic cases. A verifier can mark each attempt right or wrong without a human.

### Step 3: Let the model attempt and reward success

The model generates many attempts per problem, each with a reasoning trace and an answer. Correct answers earn reward, wrong ones earn little or none. A reinforcement learning algorithm, related to the methods in [RLHF](/tools/rlhf) and [PPO](/tools/ppo), pushes the model towards the kinds of traces that led to correct answers. Over many rounds, habits such as checking work, trying alternatives and noticing contradictions become more common.

### Step 4: Shape format and readability

Pure reinforcement learning can produce traces that mix languages or are hard to read. Practical recipes add a small amount of curated reasoning data, format rewards, and a final round of general preference tuning so the model stays helpful outside maths and code.

### Step 5: Spend compute at inference

At answer time the model writes its trace, then its answer. More thinking tokens generally help on hard problems, up to a point. Providers expose this as a budget, an effort level, or an on and off switch. Some systems add further test-time methods, such as sampling several traces and voting, or using a separate verifier.

### Step 6: Distil into smaller models

Long traces from a large reasoning model can be used as training data for smaller models. This is a form of [knowledge distillation](/tools/knowledge-distillation), and it is how many compact reasoning models are produced.

## Key concepts and terms

| Term | Meaning |
|---|---|
| Test-time compute | Computation spent while answering, rather than during training |
| Chain of thought | Written intermediate steps that lead to an answer |
| Thinking budget | A cap on reasoning tokens for one request |
| Verifiable reward | A score that can be computed automatically, such as passing tests |
| Process supervision | Rewarding individual reasoning steps rather than only the result |
| Outcome supervision | Rewarding only whether the final answer is correct |
| GRPO | A reinforcement learning method that compares a group of sampled answers to estimate advantage |
| Self-consistency | Sampling several reasoning paths and choosing the most common answer |
| Hybrid model | One model that can answer quickly or think at length on request |
| Overthinking | Spending many tokens on an easy problem with no gain |

## A worked example

Imagine a small analytics team that uses a language model to answer questions about a sales spreadsheet. This scenario is illustrative.

A user asks: "If we raise the price of plan B by 8 per cent and lose 5 per cent of its 1,200 customers, does monthly revenue go up? Plan B costs 50 a month."

A fast model without reasoning might reply "Yes, revenue rises" based on a vague sense that small churn is fine. It might be right or wrong.

A reasoning model writes a trace like this, internally:

1. Current revenue: 1,200 customers times 50 equals 60,000.
2. New price: 50 times 1.08 equals 54.
3. Customers kept: 1,200 times 0.95 equals 1,140.
4. New revenue: 1,140 times 54 equals 61,560.
5. Difference: 61,560 minus 60,000 equals 1,560 more.
6. Check: break-even churn is about 7.4 per cent, so 5 per cent is below it.

The final answer is short: "Yes, by about 1,560 a month, as long as churn stays under roughly 7.4 per cent." The trace used perhaps 300 tokens. For this team, the extra second of latency is worth the correct, checkable answer. For a question such as "what does MRR stand for?", the same team sets the thinking budget to zero.

## Strengths and limitations

**Strengths:**

- Much better accuracy on maths, logic, coding and multi-step planning.
- Accuracy can be traded for cost per request through a budget.
- Traces, when visible, help humans inspect how an answer was reached.
- Strong at self-correction within a single response.
- Works well as the planner inside agent loops such as [plan-and-execute](/tools/plan-and-execute).

**Limitations:**

- Higher latency and token cost, sometimes many times a normal reply.
- Little or no gain on simple lookups, chit-chat or short rewrites.
- A visible trace is not guaranteed to be a faithful record of the computation that produced the answer.
- Can still be confidently wrong, especially when facts are missing.
- Long traces fill the context window and the [KV cache](/tools/kv-cache), raising serving cost.

## How it compares with alternatives

| Approach | How it adds reasoning | Cost | Best for |
|---|---|---|---|
| Reasoning model | Trained to think before answering | High per request | Hard maths, code, analysis |
| Chain-of-thought prompting on a normal model | Prompt asks for steps | Moderate | Medium difficulty tasks with cheap models |
| [Tree of thoughts](/tools/tree-of-thoughts) | Explores several branches with search | Very high | Puzzles and planning with clear evaluation |
| [Reflection](/tools/reflection) loops | Model critiques and revises its output | Moderate to high | Writing and code review |
| Tool use, for example a calculator or code runner | Offloads exact steps to tools | Low to moderate | Arithmetic and data work where precision matters |

These are not exclusive. A strong pattern is a reasoning model that also calls tools, so it plans in language and computes exactly in code.

## Practical guidance and best practices

1. Route by difficulty. Send easy requests to a fast model and hard ones to a reasoning model or a high thinking budget.
2. Set an explicit budget and measure the accuracy gain at each level on your own tasks with evals.
3. Keep prompts simple. Reasoning models often do better with a clear goal and constraints than with long, scripted step-by-step instructions.
4. Ask for a clean final answer format, for example JSON, separate from the reasoning.
5. Give the model tools for exact work, such as code execution, rather than expecting perfect mental arithmetic.
6. Watch latency and cost budgets per request; see cost and latency budgets.
7. Do not treat the visible trace as proof. Verify important answers with tests or independent checks.
8. Cache stable prompt prefixes to reduce cost when many requests share the same instructions.

## Common mistakes

- Using a reasoning model for every request, including trivial ones, and paying for wasted thinking.
- Copying old chain-of-thought prompt templates that micro-manage steps the model already handles.
- Parsing the reasoning trace in code, when the provider may change or hide it.
- Assuming more thinking always helps; beyond a point accuracy flattens or drops.
- Ignoring timeouts, so long traces break user-facing latency targets.
- Evaluating only on easy examples, which hides the real benefit and cost.

## Frequently asked questions

### Is a reasoning model a different architecture?

Usually not. Most reasoning models use the same transformer design as other language models. The difference is training, especially reinforcement learning on problems with checkable answers, and the habit of producing a long trace before answering.

### Does the model really "think"?

It produces text that looks like step-by-step thinking, and that text measurably improves its answers. Whether it resembles human thought is a separate question. In practice, treat the trace as a useful working area, not as a guaranteed explanation.

### Should I hide or show the reasoning to users?

That depends on the provider and the product. Some APIs return only a summary. Showing reasoning can build trust for expert users but can confuse others. Many products show the final answer with an optional "view reasoning" link.

### How do I choose a thinking budget?

Run your evaluation set at several budgets, plot accuracy against cost and latency, and pick the smallest budget that meets your accuracy target. Different task types often need different budgets.

### Can small models reason?

Yes, to a degree. Distillation from larger reasoning models has produced compact models that do well on maths and code. They still fall behind larger models on broad knowledge and very long problems. See small language models.

### Do reasoning models reduce hallucination?

They reduce some errors, especially in calculation and logic. They do not supply missing facts. For factual questions, retrieval or tools are still needed.

## Glossary

- Inference: running a trained model to produce an output.
- Token: a small unit of text, roughly a word piece, that models read and write.
- Reinforcement learning: training by trial and reward rather than by copying examples.
- Verifier: a program or model that checks whether an answer is correct.
- Majority vote: picking the answer that appears most often across samples.
- Distillation: training a smaller model to imitate a larger one.
- Effort level: a provider setting that controls how long a model may think.
- Latency: the time between sending a request and receiving the answer.

## Summary

Reasoning models are language models trained to write out intermediate thinking before they answer, so that extra computation at inference time turns into better accuracy on hard problems. The approach grew from chain-of-thought prompting in 2022 into reinforcement learning on verifiable tasks, with OpenAI's o1 in 2024 and the open DeepSeek-R1 in 2025 as key milestones. They shine on maths, code and planning, cost more in tokens and time, and should be used selectively, with a measured thinking budget, tools for exact work and independent checks on important answers.