Reasoning models — OpenAI's o-series and Claude's extended-thinking mode — spend extra compute "thinking" before they answer, producing internal reasoning that is trained rather than prompted. On hard problems this is a step change in capability. But that thinking costs tokens and seconds, so treating a reasoning model as your default is a good way to make everything slower and more expensive for no benefit on the easy 80% of calls.
When to reach for one
Reasoning models earn their cost on problems where getting the answer requires genuine multi-step work:
- Complex math, logic, and constraint problems.
- Multi-step planning and agentic decomposition of a hard goal.
- Deep code reasoning — tricky debugging, non-trivial algorithm design.
- Analysis that must weigh several interacting factors before concluding.
For classification, extraction, summarisation, routine chat, and formatting, a standard model is faster, cheaper, and just as good. A common, effective architecture is a router: a cheap model handles the routine calls and hands only the genuinely hard ones to a reasoning model.
Prompt them differently
The instinct carried over from standard models — spell out every reasoning step, add elaborate chain-of-thought scaffolding — is counterproductive here. Reasoning models do that internally, and over-instructing can fight their trained process. State the problem and the goal clearly, give the constraints and the success criteria, and let the model allocate its own thinking. Where the API exposes a thinking budget, size it to the problem's difficulty rather than maxing it out by default.
Design around the latency
A reasoning model can take noticeably longer to respond, which reshapes the UX. For interactive use, set expectations — show that deeper analysis is underway — or push the call into an asynchronous flow where the user is not staring at a spinner. For batch and background work, the latency is usually irrelevant and the capability is pure upside.
The most cost-effective pattern is a two-tier setup: a fast standard model for the bulk of traffic and a reasoning model reserved for the calls that are actually hard. Sending every request through a reasoning model burns latency and budget on problems that never needed it.
Reasoning models are a genuine capability upgrade for hard problems and a poor default for easy ones. Use them where the difficulty justifies the cost, prompt them by stating the problem rather than scripting the steps, and route the routine majority of your traffic elsewhere.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.