Models that think before answering

What they actually do

A reasoning model generates a long internal working-out before producing its answer. You are usually shown a summary of that working, or nothing at all, and you pay for the hidden tokens. Some products expose a control (effort, thinking budget, extended thinking) that trades money and latency for more internal work.

This is not a different architecture doing something mysterious. It is the same next-token machinery, trained so that producing a long chain of intermediate reasoning before answering improves the answer, and given room to do it.

Where they are worth it

Genuinely better on multi-step problems: mathematics, logic puzzles, competitive programming, debugging, planning under several constraints, and picking apart an argument. On these the difference is not marginal.

Not better, and often worse value, on: recall, summarising, writing, tone work, translation, or anything where the answer is retrieved rather than derived. You pay several times the cost and wait several times as long for a paragraph you could have had immediately, sometimes with a stiffer register.

The practical rule: if the task would have benefited from you asking for steps, use a reasoning model. If it would not, do not.

How prompting changes

Three things are different, and the first surprises people.

Stop telling it to think step by step. It already is. The instruction is redundant, and providers of these models say so explicitly. In some cases an elaborate reasoning scaffold in the prompt interferes with the model’s own process and makes things worse.

Give the goal and the constraints, not the method. With an ordinary model you often specify the route: first do this, then that. With a reasoning model, state the destination clearly, state what a good answer must satisfy, and let it find the route. Over-specifying the method is the most common way people get less out of these models than they should.

Be complete about the requirements. Reasoning models exploit constraints. A well-stated constraint gives the internal process something to check against; a missing one is a degree of freedom that produces a confident wrong answer more elaborately than before.

The honest part about the visible reasoning

You will often see a summary of the thinking. It is tempting to read it as a log of what happened. It is not.

The displayed trace is a summary, sometimes produced by a separate model, and providers have been fairly open that it is not a faithful transcript of the internal process. More uncomfortably, research on chain-of-thought faithfulness (including work published by model developers themselves) has found that models often fail to mention information they demonstrably used, such as a hint planted in the prompt that changed the answer.

So the same rule as before holds, with more force: shown reasoning is material to check, not proof of how the answer was reached. A trace that looks careful is not evidence that the answer is right, and a trace containing an error under a correct answer means both need looking at.

Cost and latency, concretely

A reasoning model on a hard problem can generate thousands of hidden tokens before its first visible word. That means:

• You wait. Ten seconds to several minutes, depending on the model and the effort setting.
• You pay for tokens you never see. On metered APIs this dominates the bill.
• Batch jobs multiply it. A reasoning model over 500 documents is a different budget from a fast model over 500 documents.

For a personal chat this is irrelevant. For anything running repeatedly, it decides your architecture, and the sensible pattern is a fast model for the routine cases and a reasoning model for the ones flagged as hard.

Overthinking is real

On easy questions, more thinking is not better and sometimes measurably worse: the model reconsiders a correct answer into a wrong one. If your effort setting is adjustable, low or medium handles most work. Reserve high for problems you could not solve quickly yourself.

What to do this week

Take three tasks you do often. Run each on a fast model and a reasoning model, twice each, and look at the difference against the time you waited.

You will usually find one task where the reasoning model is transformative and two where it is a slower way to get the same paragraph. That is the entire decision, and it is specific to your work rather than to anybody’s benchmark.