# Reasoning model

A reasoning model is a language model trained to do extra work planning, checking, and revising before it answers a difficult question.

Source: https://rodamora.com/glossary/reasoning-model
Updated: 2026-08-09

---

A reasoning model does extra work before it returns an answer. OpenAI reported in September 2024 that its o1 model improved with more reinforcement learning during training and more time spent thinking during each request. Anthropic's manual thinking budget starts at 1,024 tokens and suggests 16,000 or more as a starting point for complex work, with added latency and diminishing returns. More thought does not create an audit trail. In a 2025 Anthropic study covering six kinds of hidden hints, reasoning traces often disclosed an influential hint in fewer than 20% of the cases where the model used it. Use this model as a higher-cost judgment tier. Give it difficult work when measured quality can reduce review or rework. Keep routine work on the fastest model that clears the firm's standard.

## What makes a reasoning model different from a normal LLM?

Training makes the main difference. A general language model learns to predict useful text. A reasoning model gets extra training that rewards successful problem-solving. It can then spend more time on a hard request before returning its final answer.

OpenAI's September 12, 2024 [reasoning research](https://openai.com/index/learning-to-reason-with-llms/) says reinforcement learning taught o1 to refine its approach, recognize mistakes, break difficult steps into smaller ones, and try another strategy when the first failed. OpenAI also reported two separate ways to improve performance: more reinforcement learning during training and more thinking during a request.

DeepSeek reported a similar pattern in the January 22, 2025 [DeepSeek-R1 paper](https://arxiv.org/abs/2501.12948). Its researchers used reinforcement learning to encourage self-reflection, verification, and changes in strategy on tasks with answers that could be checked. The category therefore covers a training approach, not only one vendor's product name.

Asking an ordinary model to “think step by step” can change its response. It does not change that model's training or the controls used when it runs. A reasoning model was built for the extra work, and current APIs let the implementer set how much effort each request gets.

The user may never see the extra work. The application usually receives the final answer and, in some products, a short summary of the reasoning. The computation still happened. Include it in the task's cost and latency.

## When should a service firm use a reasoning model?

Use one when a simple rule cannot settle the task. Conflicting evidence, several dependent steps, an unfamiliar exception, or a review that must find a subtle inconsistency can justify more model work.

Routine work usually has a cheaper path. Extracting an invoice date from a fixed field, assigning an inbound request to one of five queues, or rewriting a note into a standard format should start with a fast model and a clear check. A deterministic rule may handle some of those tasks without a language model.

| Task shape | Fast model or rule | Reasoning model |
| --- | --- | --- |
| Inputs | Stable fields and repeated formats | Conflicting, incomplete, or unfamiliar material |
| Work | Extraction, classification, routing | Planning, reconciliation, diagnosis, difficult review |
| Check | Exact match or simple rubric | Several criteria that interact |
| Cost of delay | High volume needs quick response | Quality matters more than a few extra seconds |
| Best use | Run the common path | Handle the hard case or validate the result |

Suppose an operations team receives a client report and must pull the due date, owner, and project code. A fast model can extract those fields. The workflow can compare each value with the source. The expensive model adds little.

Now suppose the report conflicts with the signed scope. Two dates disagree, and a late change affects three downstream commitments. The job has become a judgment task. A reasoning model can compare the evidence, identify the conflict, and propose the next decision. A person still owns any client-facing commitment.

Choose the tier from the task. Volume and consequence matter more than how impressive a model looked in a benchmark.

## Why can more reasoning cost more and still save money?

Extra reasoning uses more tokens and takes time. Google's current [thinking documentation](https://ai.google.dev/gemini-api/docs/thinking) exposes low, medium, and high levels on several models. Google says lower settings reduce latency and cost, while higher settings allow more reasoning depth. Its pricing guidance counts thinking tokens as output work.

Anthropic exposes the same tradeoff through a token budget. Its [extended-thinking documentation](https://platform.claude.com/docs/en/build-with-claude/extended-thinking) sets a 1,024-token minimum for manual thinking. It suggests 16,000 tokens or more as a starting point for complex tasks. It also tells implementers to tune against latency and quality because returns depend on the job and eventually diminish.

The model bill is only one part of the cost. A cheap answer that takes a senior manager twenty minutes to repair may cost more than an expensive answer that passes review in two. An answer that arrives after the client deadline failed that step as well.

Measure one accepted unit of work. Count model cost, elapsed time, human review minutes, retries, and rework after the result enters the next step. This is the same operating problem as [the AI employee's rate card](https://rodamora.com/blog/your-ai-employee-has-a-rate-card-you-set-it). Model and effort settings are part of the cost to deliver. The right setting clears the quality bar at the lowest total cost.

A useful pattern is a fast model on the common path and a reasoning model on hard cases. Another is a fast model producing the first pass while a reasoning model checks only the final output. Both reserve the expensive tier for judgment.

## Can you trust a model's reasoning trace?

A reasoning trace can show you where to investigate. Evidence comes from sources and actions the workflow can inspect. A polished explanation can leave out the factor that drove the answer. Some providers return only a summary of the model's internal work.

Anthropic tested this problem in its 2025 paper [Reasoning Models Don't Always Say What They Think](https://assets.anthropic.com/m/71876fabef0f0ed4/original/reasoning_models_paper.pdf). The researchers placed six kinds of hints in prompts, including cues that could help the model choose an answer. When models used a hint, the reasoning trace revealed that influence at least 1% of the time in most tested settings, but the rate was often below 20%.

That study used controlled questions. It cannot predict how often a specific model hides a business-relevant factor in your workflow. It does show why a written chain of thought cannot serve as the firm's audit log.

Keep the source documents, tool calls, returned data, applied rules, approvals, and final state. Ask the model to cite the material behind its conclusion. Test the conclusion against a written [eval](https://rodamora.com/glossary/eval). The observable work forms the audit record.

The same boundary applies to safety. More reasoning may improve a plan. Permission to send a client message, move money, change access, or delete a record comes from the workflow. A [guardrail](https://rodamora.com/glossary/guardrail) blocks the forbidden path before it runs. Approval stays attached to the action's consequence.

## How should a firm route work between models?

Start with twenty to fifty examples of the real task. Include ordinary cases, known exceptions, missing information, conflicting inputs, and examples where the correct result is to stop and ask a person. Write the acceptance rule before testing models.

Run the same set through a fast baseline and the reasoning option. OpenAI's current [model guidance](https://developers.openai.com/api/docs/guides/latest-model) recommends comparing task success, answer completeness, required evidence, total tokens, latency, and cost on representative tasks. Add human review minutes, retries, and downstream rework. Those costs land inside the service firm and stay outside the API report.

Pick the lowest setting that clears the bar. Route the cases it misses to the stronger tier. Re-run the set after changing the prompt, model, effort, tools, or source material. A model upgrade is a production change and needs the same test as the version before it.

A model's ability and its permission to act are separate. The practical questions are whether the firm can check the result and undo a mistake. [Delegate based on the task](https://rodamora.com/blog/delegate-the-inputs-own-the-outputs), then decide which model handles each part. A reasoning model may draft a difficult recommendation while a person approves what reaches the client.

The routing owner should review the mix on a schedule. Look for routine cases reaching the expensive tier, hard cases staying on the cheap one, and review time moving in the wrong direction. Measure accepted work at the resulting cost.

## Where does a reasoning model sit on the Delivery Model Ladder?

A reasoning model belongs at Stage 2, Augmented, on the [Delivery Model Ladder](https://rodamora.com/delivery-model-ladder) when a defined workflow routes a difficult task to it, supplies the right sources, checks the result, and sends exceptions to a person. The model owns a bounded judgment step. The firm owns the standard and the release decision.

At Stage 1, Enhanced, a person selects the model, asks the question, reads the response, and carries the result into the next system. Extra thinking may improve the answer. The delivery process still depends on that person's manual handoff.

Stage 3 depends on the whole operating model. A firm reaches it when AI is built into delivery, the checking layer improves from real feedback, and revenue can grow without headcount matching it step for step. A high reasoning setting leaves that work unchanged.

The home for this term is [the AI employee](https://rodamora.com/blog/what-is-an-ai-employee). A software role may use a fast model for routine work, a reasoning model for difficult judgment, and a person for a decision the system should not make. The role becomes useful when those boundaries are written and tested.

Routine work with a cheap, dependable check stays on the fastest model that meets the standard. Move a task to the reasoning tier only when the measured gain in accepted output is worth the extra cost and delay.