Reasoning models — the ones marketed as "thinking" before they answer — spend extra compute working through a problem internally before producing a final response. That pass produces better answers on hard problems and wastes money on easy ones. Knowing which is which is the whole game.
What happens under the hood
A standard model generates tokens straight to your response. A reasoning model first generates a private chain of intermediate reasoning, then uses that chain to produce the answer you see. The visible reply is only the last step of a much longer internal process.
The catch: those intermediate tokens are not free. You are billed for them, and producing them adds latency. The reasoning pass can easily dwarf the visible answer in both cost and time.
Where reasoning models earn their keep
They excel where a naive single pass fails:
- Multi-step math and formal derivation.
- Debugging and code that must be correct, not just plausible.
- Planning with constraints — schedules, routes, resource allocation.
- Tasks with an objectively checkable answer.
If your task has a right answer and getting it wrong is expensive, a reasoning model is worth the premium.
Where they are a waste
Most everyday workloads do not need the extra pass:
- Summarization and rewriting.
- Formatting or re-structuring existing text.
- Simple extraction and classification.
- Retrieval-guided Q&A where the answer is in the context.
On these, the reasoning pass adds cost and latency without meaningfully improving output — sometimes it produces worse results by over-thinking a simple instruction.
How reasoning tokens show up in your bill
Depending on the provider, the internal chain is metered as output tokens or as a separate input line. Either way, a single "short" answer can carry a much larger hidden token count. The only reliable way to know what a reasoning model costs on your task is to make a real request and read the usage object — not to extrapolate from the length of the visible reply.
Auditing the reasoning chain
Some models let you request the intermediate reasoning back as a separate field, usually behind a flag. When you can see the chain, use it: it tells you whether the model's answer is grounded in a sound argument or just a confident guess, and it makes debugging a wrong answer far easier than staring at a one-line reply. Expose it during evaluation, then turn it off in production to keep responses lean.
How to prompt reasoning models differently
Reasoning models do more of the work, so your prompt can do less:
- State the goal and constraints, not a step-by-step method.
- Ask for the answer and the reasoning separately only if you need the chain audited.
- Avoid chain-of-thought prompting on top of a model that already reasons internally.
The point is to let the model's internal pass do the planning you would otherwise have to spell out.
How to measure the difference
Do not trust benchmarks for your decision. Run a small head-to-head on your own task:
- Send the same prompt to a fast model and a reasoning model.
- Compare output quality against an objective check, not a vibe.
- Compare the token count and latency of both.
On most engineering teams, the result is that a small slice of tasks justifies reasoning, and everything else should ship on a fast model.
The practical pattern
Right-size per task rather than choosing one model for everything. In Mappace you can route by model name per request, so keep reasoning models for the tasks that earned them, keep a fast model for everything else, and let failover catch the rest. Compare live pricing and names in the model catalog, then read the docs to set up per-task routing.