Reasoning Modes: Cost and Benefit

Most providers now offer a mode where the model produces extended intermediate work before its answer. It is slower, it costs more, and it is a substantial improvement on a specific class of problem.

What changes

The model generates a long chain of intermediate text — exploring approaches, checking steps, sometimes backtracking — before producing the final response. Some products show this; some hide it and bill for it.

The mechanism is the same. It is still next-token prediction. What changes is that the model constrains itself with its own intermediate output, which improves accuracy where the answer depends on multiple dependent steps.

Where it genuinely helps

Multi-step arithmetic and quantitative problems. The largest and most consistent improvement.

Code that requires holding several constraints at once. Debugging, algorithm design, refactoring across dependencies.

Logic puzzles and constraint problems.

Long chains of dependent inference, where an early error propagates.

Careful analysis of a complex document where the conclusion depends on reconciling several parts.

Planning tasks with ordering constraints.

Where it does not

Factual recall. Thinking longer does not supply information the model never learned. A fabricated citation is fabricated just as readily with extended reasoning.

Anything the model already does well. Summarising, rewriting, translating, drafting, explaining familiar concepts. These are single-pass tasks and extended reasoning adds latency and cost for no gain.

Creative work. Frequently worse, producing laboured output.

Simple lookups and transformations.

Subjective questions. More words, same judgement.

The cost

Time. Seconds to minutes rather than immediate.

Money. Intermediate tokens are generated and usually billed. A reasoning answer can cost many times a standard one.

Quota. On consumer plans, reasoning requests generally count against a smaller allowance.

Context. Reasoning consumes the window.

The trap: the visible reasoning is not an audit trail

Products that display the chain make it tempting to read it as an explanation of how the answer was produced.

It is not necessarily that. The displayed reasoning is generated text, and research has repeatedly found cases where the stated reasoning does not correspond to the factors actually driving the answer. A model can produce a correct-looking chain that ends in a wrong answer, and a wrong-looking chain that ends in a right one.

Read it for useful intermediate results, which it often contains. Do not treat it as verification.

Choosing between modes

Use reasoning when: the problem has multiple dependent steps, correctness matters and is checkable, the task is quantitative or logical, or you have tried the standard mode and it failed in a way that suggests a missed step.

Use standard when: the task is writing, summarising, rewriting, translating, explaining, or anything conversational. Also when you will iterate, since speed matters more than a marginal gain per turn.

A practical default: standard first. If the answer is wrong in a way that looks like a skipped step rather than a missing fact, retry with reasoning. If it is wrong because the model did not know something, reasoning will not help and retrieval might.

The benchmark caveat

Reasoning models post dramatically better scores on mathematics and coding benchmarks, and those benchmarks are what the marketing quotes.

Those benchmarks measure exactly the category where reasoning helps most. They say very little about drafting an email, summarising a report or explaining a concept — which is most of what most people do.

A headline improvement on a mathematics benchmark does not predict any improvement in your daily work unless your daily work is mathematics.

The honest summary

Reasoning modes are a real capability improvement on a real class of problems, oversold as a general improvement. For quantitative and multi-step technical work they are worth the wait and the cost. For everything else they are a slower, more expensive way to get a similar answer.

Reading the visible chain usefully

Where a product shows its intermediate work, there is value in it that is not verification.

Useful intermediate results. The chain frequently contains a calculation, a decomposition or an observation worth keeping even when the final answer needs correcting.

The point where it went wrong. For a wrong answer, scanning the chain usually locates the bad step quickly, which tells you how to reframe the question.

Assumptions it made. Chains expose unstated premises that a bare answer conceals. This is the most common useful finding — the model assumed something about your situation that is not true, and you can see exactly where.

What it considered and rejected. Sometimes the rejected option was the right one.

What it is not: a record of the computation. Treat it as a plausible narrative written alongside the answer rather than as an audit trail, and use it to locate problems rather than to confirm correctness.