A new category of model emerged as a distinct product line over the last two years: models built to spend more computation per answer, working through a problem in explicit intermediate steps before committing to a response, rather than producing the fastest plausible completion.
The trade is straightforward to state and easy to misapply: slower and more expensive, in exchange for meaningfully better performance on problems that require actual multi-step reasoning rather than pattern completion. The skill isn't knowing that reasoning models exist. It's knowing which parts of a system actually need one.
What a reasoning model is actually doing differently
A standard model produces its answer in roughly one forward pass, optimized to generate the most likely next tokens given the prompt. A reasoning model is trained and prompted to generate an internal chain of intermediate reasoning first — checking its own logic, considering alternatives, catching contradictions — before producing a final answer.
That process is not free. It costs more tokens, more time, and more money per query, often by a wide margin. On problems that genuinely require multi-step logic — debugging a subtle code issue, working through a contract clause with conditional exceptions, planning a sequence of dependent actions — that cost buys a real accuracy gain. On simple lookups and classifications, it buys almost nothing.
The mistake: using one model for everything
The most common inefficiency we see in agent systems is routing every request through the same model, reasoning-capable or not, regardless of what the step actually requires. A step that classifies an incoming email into one of six categories doesn't need extended reasoning. A step that decides whether a refund request is fraudulent based on conflicting signals often does.
Treating every call the same way means paying reasoning-model prices for classification-tier work, or worse, the reverse — using a fast, shallow model on the one step in the pipeline that actually needed to think, and getting a confidently wrong answer as a result.
How to decide which steps deserve it
A useful test: does the step require holding multiple constraints in mind at once and checking them against each other, or is it closer to recognition — does this input match a known pattern? Recognition tasks (classification, extraction, sentiment, routing) rarely benefit from reasoning-model overhead. Constraint-satisfaction tasks (scheduling, multi-condition eligibility, anything with 'unless' and 'except' in the rules) usually do.
The second test is cost of being wrong. A miscategorized support ticket gets rerouted at near-zero cost. A wrongly approved refund, a wrongly denied insurance claim, or a wrongly scheduled surgical resource has real cost — and that's where the extra latency and spend for a reasoning pass is easy to justify regardless of how simple the task looks on the surface.
Latency is a product decision, not just a technical one
Reasoning models are slower — sometimes by seconds, occasionally longer for genuinely hard problems. In a real-time chat interface, that delay is user-visible and needs to be designed around: a status indicator, a partial response, or an explicit 'thinking' state, rather than a silent hang that reads as broken.
In a background or asynchronous workflow — a nightly reconciliation job, an overnight document review — the same latency is irrelevant. Knowing which category a given agent step falls into changes not just which model you pick, but how the interface around it needs to be built.
Building the routing layer once, not per-project
The systems we build route each step to the cheapest model capable of handling it correctly, with reasoning-tier models reserved for the specific steps that need them — decided once, at design time, not re-litigated per request. That routing logic sits behind a single interface, so upgrading a specific step to a new reasoning model, or downgrading a step that turned out not to need one, is a config change.
That structure is what keeps reasoning-model costs proportionate instead of becoming the dominant line item in an agent's operating budget — which is the failure mode we see most often in systems built without this distinction from the start.
Reasoning models are a tool for the handful of steps in a system that actually require holding several things in mind at once — not a blanket upgrade. Systems that route deliberately outperform, and out-earn, the ones that route everything through the smartest available model by default.