What are reasoning models?
More compute before the answer.

The model uses more computation after it receives the prompt.

A language model ordinarily builds an answer by repeatedly predicting the next token. A reasoning model is designed to spend additional inference-time computation before it returns its user-facing answer. Depending on the system, that can involve generating more internal tokens, considering alternatives, or running a separate search or verification procedure.

“Reasoning model” is a product label, not one universal architecture. Providers expose different controls and internal methods. Some models produce hidden reasoning tokens; others may use sampling, search, or tool calls as part of a wider system. For example, OpenAI documents reasoning tokens interleaved with visible output and tool calls for some models; that provider-specific behavior is not a definition of every reasoning system. A longer response alone does not tell you which method was used. See the API description ↗

For the broader computation that turns a trained model into an output, see how AI inference works ↗.

Training shapes what a model can do. Inference gives it room to work.

Extra computation at answer time is only part of the story. Training and post-training shape the model’s learned behavior; the serving system then decides how much computation, context, and time to allocate to a particular request. A reasoning setting cannot make up for missing knowledge, weak training, or an unsuitable tool.

DeepSeek-R1 is one documented example, not a template for every model. Its paper describes reinforcement learning and a multi-stage training process; the authors evaluate the resulting models on specified reasoning benchmarks. Those methods and reported scores describe their models and experiments, not a general guarantee about systems carrying a “reasoning” label.

For context on token generation and serving, continue with what tokens are ↗ and how to measure the full cost of AI work ↗.

Systems can spend more compute in several different ways.

These approaches are not interchangeable. A 2026 preprint groups test-time scaling methods by whether they extend one trajectory, compare completed candidates, or search across partial ones. Its point is practical: an accuracy number is hard to interpret without the inference procedure and compute budget that produced it.

A tool result or verifier can catch some errors, but it can also be wrong or incomplete. Check what was actually run and whether the check measures the task you care about.

Extra effort matters most when the task is hard and the result is checkable.

Longer or broader search can help on complex math, code, planning, or analysis when the system has a useful way to compare candidate work. It may add little to a routine lookup or a simple classification. Even within one task set, the best way to allocate compute can vary with problem difficulty.

In one 2024 study, Snell and colleagues found that a compute-allocation strategy improved efficiency by more than four times over a best-of-N baseline in their experiments. This is a result for that paper’s models, tasks, and evaluation—not a general multiplier for today’s products. The authors’ core finding is that the benefit of extra inference compute depends on the question and the method used to spend it.

For a model comparison grounded in your own work, start with how to choose an AI model for a real task ↗.

Response time, token budget, and review effort all count.

Additional generation can increase latency and use more of the model’s output budget. In OpenAI’s API, reasoning tokens are not shown as ordinary answer text, but they occupy the context window and are counted as output tokens. Other providers expose different usage and billing details, so check the documentation for the system you use.

The useful comparison is not simply “which answer cost less?” Measure the cost of a correct, accepted result: retries, tool calls, time to completion, human review, and corrections can matter as much as the model’s listed price. A slower attempt that reliably avoids costly rework may be worthwhile; extra tokens that produce no measurable improvement are wasted capacity.

For a deeper view of latency, energy, memory, and review, read the cost of intelligence ↗ and AI energy and infrastructure ↗.

Compare the simplest setting with the harder one.

Build a small evaluation from the tasks people actually need. Use the same inputs, tools, and success criteria, then compare different reasoning settings on the outcomes that matter:

• Did the result meet the task’s acceptance criteria, including difficult and incomplete cases?
• How often did a check catch an error—and how often did the check itself fail?
• What were the total latency and cost per accepted result, including retries and tools?
• How much time did a person spend reviewing or correcting the result?
• Did the system stay inside its permissions and stop when evidence was missing?

OpenAI exposes reasoning.effort as a model-dependent control for how much reasoning a task receives; the parameter does not replace an evaluation. Compare settings on the same representative examples and measure whether accepted outcomes improve enough to justify their cost. For a repeatable plan, read how to evaluate AI agents ↗ and how to read AI benchmarks ↗.

Judge the result by what can be checked.

An internal reasoning trace can be useful context, but it is not an audited transcript of every factor behind an answer. In a study of Claude 3.7 and DeepSeek R1, Anthropic tested cases where hints changed model answers; the models often failed to mention those hints in their written reasoning. The experiment used constructed tasks and does not establish a rate for every model, but it shows why a trace is not a substitute for checking the result. Read the study and its limitations ↗

Some interfaces and APIs do not expose internal reasoning tokens at all. Ask for the result, relevant sources, assumptions, or a check a person can inspect; verify important claims against the underlying evidence.

OpenAI’s current prompting guidance also advises against assuming that “think step by step” improves every reasoning model. State the goal, constraints, and output you need, then test the workflow. If the system can act on files or services, keep permissions in the application and verify the final state.

Continue with a clear prompt and output contract ↗, why fluency is not evidence ↗, and where agent permissions belong ↗. For a different kind of explanation—one that tests a model’s features and outputs—read the guide to explainable AI ↗.