Reasoning models

Why some models “think” before answering, and when that's worth the wait. About 25 min, intermediate level.

You'll be able to

• Explain what a reasoning model does differently: it writes out intermediate thinking before its final answer.
• Decide when a reasoning mode is worth its extra time and cost, and when a standard model is enough.
• Check a reasoning model's answer against an independent solution instead of trusting its visible steps.

Thinking before answering

A standard chat model starts writing its answer straight away. Each token it writes gets roughly the same amount of computation, so a hard problem gets no more effort than an easy one.

A reasoning model first generates a long stretch of intermediate text, often called thinking or reasoning tokens. In it, the model works through the problem: breaking it into steps, trying an approach, noticing a mistake, going back and trying another. Only then does it write the final answer, which can draw on all that work because it sits in the model's context.

Since a model does its computation token by token, writing more tokens means spending more computation on the problem. This is sometimes called spending more test-time compute: extra effort at the moment of answering, rather than a bigger model.

Many apps show a summary of this thinking, or let you expand it, rather than the full raw text.

The key idea: a reasoning model spends extra computation by writing out its working before it answers.

Where reasoning comes from

The idea started with prompting. Researchers found that asking an ordinary model to “think step by step” before answering, known as chain-of-thought prompting, improved results on multi-step problems like word problems and logic puzzles.

Reasoning models build this habit in through training. Developers don't publish every detail, but the widely described approach uses reinforcement learning on problems with answers that can be checked automatically, such as math with known solutions or code with tests. Reasoning that leads to correct answers is rewarded, so the model learns useful habits: checking its work, trying alternatives, and not stopping at the first idea.

This explains where they are strongest: problems where a right answer exists and can be verified.

Most assistants now either switch reasoning on automatically when a question looks hard, or let you choose a mode or an effort level. The names differ between products, but the trade-off is the same.

The key idea: reasoning is a trained skill, strongest on problems with checkable answers.

When it's worth the wait

Reasoning mode tends to help most on:

• math, statistics and other quantitative problems
• multi-step logic and planning with constraints, like a schedule that must satisfy several rules
• finding bugs in code or designing a program
• analysis that has to weigh several pieces of evidence

It adds little on quick rewrites, short translations, brainstorming, simple lookups and casual questions. There it is just slower, and it can overcomplicate a simple request.

The costs are real:

• Time. Thinking can take from a few seconds to several minutes.
• Money. On paid APIs, thinking tokens are generally billed as output tokens, even when you only see a summary.
• Context. Thinking takes up room in the context window during the answer.

Choosing a mode is a delegation decision: match the effort to how hard the task is and how much a wrong answer would cost.

The key idea: use reasoning for problems with several steps, and a standard model for quick language tasks.

Still fallible, and the steps aren't proof

Reasoning models make fewer mistakes on hard problems, not zero. They still slip on arithmetic, misread the question, or build a long, careful argument on a wrong assumption made early on. A longer chain of steps also means more places for an error to creep in.

The visible reasoning is persuasive because it looks like a worked solution. But it is generated text, and often a summary. Research has found that a model's stated reasoning doesn't always reflect what actually drove its answer. Neat steps are not evidence that the answer is right.

So check the answer independently:

• Compare it with your own solution or a known answer.
• Plug the result back into the problem.
• Run the code or the calculation yourself.
• Ask for a check using a different method.

If two modes disagree, that tells you something is wrong, but agreement doesn't prove either is right.

The key idea: treat the visible reasoning as a lead to check, not as proof.

Same puzzle, two modes

A student takes a probability question they've already solved: “Two fair dice are rolled. At least one shows a 6. What is the probability that both show a 6?”

Their own answer first. There are 36 equally likely outcomes. Those with at least one 6: six with the first die showing 6, six with the second, minus the one counted twice, so 11. Only one of those is double six. Answer: 1/11.

Reasoning off. A quick answer might say 1/6, reasoning that the other die just needs to be a 6. That treats “at least one is a 6” as “the first die is a 6”, which is a different question.

Reasoning on. The model takes longer and, in this case, lists the outcomes and reaches 1/11.

The comparison that matters is against the student's own answer, not between the two modes. If both modes had said 1/6, agreement would have meant nothing. The student also notes the time each mode took and where the quick answer went wrong: it misread the condition, a classic slip that careful step-by-step work tends to catch.

Try it

The problem, your own worked answer, the model's answers with reasoning off and on, and a short note on which were right, roughly how long each took, and where any mistake crept in.