Reasoning model

A reasoning model does extra work before it returns an answer, which can help when the job needs difficult planning, checking, or judgment. It also costs more and takes longer, so I would give it work where the measured improvement can reduce review or rework, and keep routine jobs on the fastest model that meets the standard.

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 for complex work, with more delay and a benefit that eventually shrinks.

And more thinking doesn’t give you a reliable record of why the model decided something. In a 2025 Anthropic study covering six kinds of hidden hints, the reasoning traces often disclosed an influential hint in fewer than 20% of the cases where the model used it.

What makes a reasoning model different from a normal LLM?

The main difference is training. A general language model learns to predict useful text, while a reasoning model gets extra training that rewards successful problem-solving and can then spend more time on a hard request before answering.

OpenAI’s September 12, 2024 reasoning research 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. 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.

You may never see the extra work, because the application usually receives the final answer and, in some products, only a short summary of the reasoning. The model still did that work, so count it in the cost and time the task takes.

When should a business 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.

A fast model or fixed rule fits stable fields and repeated formats, where the job is to extract, sort, or route information and the check is an exact match or a simple standard. That’s especially useful when there are many requests and people need a quick answer.

A reasoning model is more useful when the material conflicts, is incomplete, or is unfamiliar, and the job involves planning, reconciling facts, diagnosis, or difficult review. The checks may depend on several things at once, so a better result can be worth a few extra seconds.

Suppose an operations team needs the due date, owner, and project code from a client report. A fast model can extract those fields and the workflow can compare them with the source, so 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. A reasoning model can compare that evidence, identify the conflict, and propose a decision, but a person still owns any commitment to the client.

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 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 lets you make the same choice through a token budget. Its extended-thinking documentation sets a 1,024-token minimum for manual thinking and suggests 16,000 tokens or more as a starting point for complex tasks.

It also says to adjust that budget against time and quality, because the benefit depends on the job and eventually gets smaller.

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 the whole cost of one piece of work that passes your standard, including the model bill, time taken, human review, retries, and rework after it reaches the next step. This is the same problem as the AI employee’s rate card, choosing the model and effort setting that meet 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 in its 2025 paper Reasoning Models Don’t Always Say What They Think, placing 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, rules, approvals, and a record of how the job ended. Ask the model to cite its sources and test the conclusion with a written eval, so your audit record comes from work you can inspect rather than an explanation you have to trust.

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 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, including ordinary cases, known exceptions, missing information, conflicting inputs, and cases where the right result is to stop and ask someone. Write down what counts as acceptable before testing models.

Run the same set through a fast baseline and the reasoning option. OpenAI’s current model guidance 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 passes and send the cases it misses to the stronger model. Rerun the set whenever you change the prompt, model, effort, tools, or source material, because an upgrade changes the system people rely on 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, then decide which model handles each part. A reasoning model may draft a difficult recommendation while a person approves what reaches the client.

Have the person responsible review which tasks go to each model on a schedule. Look for routine cases reaching the expensive model, hard cases staying on the cheap one, or people spending longer in review, and compare that with the cost of work that actually passes.

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

A reasoning model belongs at Stage 2, Augmented, on the Delivery Model Ladder when a defined workflow sends it a difficult task, supplies the right sources, checks the result, and sends exceptions to a person. The model handles a limited judgment step, while your firm owns the standard and decides what can be released.

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. 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.