Thinking modes, and what you pay for them

What the switch actually turns on

Most serious models now offer a mode with a name like thinking, reasoning, extended thinking, deep think or a separate model line entirely. Whatever the label, the mechanism is the same: before writing its answer, the model generates a long stretch of intermediate text working the problem out, and that text is either hidden from you or shown in a collapsed panel.

Two facts follow from the mechanism, and both matter to your wallet and your patience.

You are billed for the hidden part. Those intermediate tokens are output tokens. A question that produces 200 words of answer might have produced 3,000 words of thinking first, and on the API you pay for all of it at the output rate, which is typically three to five times the input rate. A thinking-mode answer can cost ten times what the same model charges without it.

You wait for it. Normal replies start streaming in under two seconds. A thinking reply commonly takes 15 to 60 seconds before the first visible word, and the heaviest settings run for several minutes. In a conversation that is a different experience, not a slightly slower one.

Where it earns its cost

The gains are real and they are concentrated. Thinking modes help most when the task has a checkable internal structure: where a wrong step produces a contradiction the model can notice.

• Multi-step arithmetic and anything with units
• Debugging: reading code, forming a hypothesis, testing it against the rest of the file
• Constraint problems: rotas, seating, timetables, packing
• Planning a piece of work into ordered steps with dependencies
• Careful comparison of two long documents for inconsistency
• Questions where the obvious answer is a trap

On these, the difference is not subtle. A model that gets a multi-constraint scheduling question wrong every time without thinking will often get it right with it.

Where it does nothing, or hurts

Recall. If the model does not know a fact, thinking longer does not fetch it. It produces a more elaborate and more convincing wrong answer. This is worth sitting with: extended reasoning raises your confidence in an answer more reliably than it raises the answer’s accuracy on knowledge questions.

Style and tone. Rewriting an email does not improve with 3,000 tokens of deliberation.

Summarising and extraction. The answer is in the input. There is nothing to reason about.

Simple questions. There is a documented pattern of models talking themselves out of a correct first instinct. Ask a thinking model something easy and you sometimes watch it consider four wrong interpretations before returning to the obvious one, and occasionally it stops at one of the four.

Controlling it

Products expose this differently, and the vocabulary is worth knowing because it is how you turn the cost down:

• A toggle in the chat interface: on or off, no middle.
• A budget in tokens on the API: give it 2,000 thinking tokens instead of 30,000 and most of the benefit on ordinary problems survives.
• An effort setting (low, medium, high) which is the same idea with the numbers hidden.
• A separate model name in the reasoning line, which you select instead of setting.

If you have a budget or an effort dial, the useful discovery is that the curve flattens early. Going from none to a little is where nearly all the improvement lives. Going from a lot to the maximum usually buys a few per cent for several times the cost.

Testing it honestly on your own work

Take five prompts from the work you actually do. Run each one twice, thinking on and thinking off, and score the pairs yourself without looking at which was which. Most people are surprised twice: on two prompts the difference is decisive, and on the other three it is invisible.

Then do the arithmetic. If thinking mode is on by default in your product and only two of your five tasks need it, you are waiting forty seconds and paying several times over for three tasks a day that would have been fine.

The visible-thinking caveat

Some products show you a summary of the reasoning. It is useful for spotting where an answer went wrong. It is not a transcript of the computation; it is text the model produced, sometimes a paraphrase generated separately, and a model can reach the right answer through steps its visible reasoning does not describe, or produce plausible reasoning for an answer it got another way. Read it as a helpful sketch, never as proof of how the conclusion was reached.