How to Prompt for Step-by-Step Reasoning

TL;DR: "Think step by step" was written for models that didn't reason by default. Reasoning-native models now do it internally, and OpenAI and Google both say adding the instruction can help nothing or actively hurt. Classic chat models still benefit from it. Whether you can see the reasoning is a third, separate setting.

For years, "let's think step by step" was close to a universal upgrade. Add four words, watch a model that guessed wrong suddenly show its work and land on the right answer. That advice was correct, and for a large share of models in production today it still is. What changed is that a newer class of model already spends tokens reasoning before it writes a word you see: OpenAI's reasoning-capable GPT-5.6 line, Anthropic's Opus 5 and Sonnet 5, and Google's Gemini 3. Telling a model to do something it is already doing is not neutral. Sometimes it duplicates effort. Sometimes, per the vendors' own documentation below, it measurably gets in the way.

This is a practical guide, not a history lesson. It walks through three separate questions: whether your model needs the instruction, whether asking could hurt, and whether you actually want to see the reasoning regardless of the first two answers. For the mechanism behind chain-of-thought and when it helps at all, our chain-of-thought prompting guide covers that in depth; this page assumes you already know what step-by-step prompting is and want to know what to do about it in 2026.

Is your model already reasoning before it answers?

The fastest test: does the product or API expose a control for how much the model reasons? If yes, it is reasoning-native, and the step-by-step question changes shape.

• OpenAI: GPT-5.6 and its variants (gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna) accept a reasoning.effort parameter. If you're calling a model with no such parameter, you're on a classic model.
• Anthropic: Claude Opus 5 and Sonnet 5 think by default via an internal adaptive thinking mode; older Claude models without a thinking parameter do not reason internally.
• Google: Gemini 3 models use thinking_level, which defaults to high unless a model documents a different default; Gemini 3 Flash-Lite instead defaults to minimal, and Google's own docs note that minimal "does not guarantee that thinking is off."

If none of that applies (you're on a smaller, faster, or older model, or a product that doesn't expose a reasoning toggle), treat it as a classic model for prompting purposes.

Outside a raw API, the same signal shows up as a visible mode rather than a parameter name. A model picker that separates a fast option from one labeled for harder problems, or an interface that shows a distinct "thinking" state while a response is being generated, is the consumer-facing version of the same switch. If your app shows something like that, you're already on the reasoning side of this guide, whatever wording you type into the box. For the full seven-vendor breakdown of who switches what and how, see our reasoning models vs chat models guide.

Case 1: when should you still ask for the steps?

On a classic, non-reasoning model, explicit step-by-step instructions remain one of the cheapest accuracy gains available. The model has to compress an entire multi-step problem into a single forward pass unless you give it room to work through the steps out loud.

[Your question or task]

Let's think step by step. Show your reasoning, then give the final
answer on its own line starting with "Answer:".

This is unchanged advice: the same instruction that has worked since 2022. It costs a few extra tokens and, on a task that genuinely has steps (arithmetic, multi-criteria decisions, code tracing), it converts a class of wrong answers into right ones. It is also still the right move for persona-driven prompts on a classic model, where asking an expert persona to reason aloud produces more checkable output than asking for a bare verdict.

Two refinements make the technique work harder. Label the final line explicitly, so a script (or you, skimming) can pull the answer out of a longer response without re-reading the reasoning. And on a high-stakes question, run the same prompt a few times and take the majority answer, a technique called self-consistency that cancels out one-off reasoning slips. Both are cheap insurance on a classic model. Neither does much on a reasoning model, which is already sampling one internal reasoning path per request rather than several you can vote across.

Case 2: when does asking for steps backfire?

This is the part of the advice that reversed. Two vendors say so in their own documentation, in almost identical terms.

OpenAI's reasoning best-practices page states it as a rule: 'Since these models perform reasoning internally, prompting them to “think step by step” or “explain your reasoning” is unnecessary.' Earlier on the same page, in prose: 'Some prompt engineering techniques, like instructing the model to “think step by step,” may not enhance performance (and can sometimes hinder it).'

Google gives the identical migration advice for Gemini 3: "If you were previously using complex prompt engineering (like chain of thought) to force Gemini 2.5 to reason, try Gemini 3 with thinking_level: "high" and simplified prompts." The same page adds that Gemini 3 "may over-analyze verbose or overly complex prompt engineering techniques used for older models."

The replacement, per OpenAI's own advice on prompting a reasoning model: "Reasoning-capable GPT-5 models usually work best when you give them a clear goal, strong constraints, and an explicit output contract without prescribing every intermediate step." In practice that means deleting the numbered procedure and writing the definition of done instead:

Find the root cause of this failing test and fix it.

Constraints: don't change the public function signature, don't add a
new dependency, keep the diff under 25 lines.
Output: the patch, one sentence naming the root cause, and the test
that would have caught it.

<failing test output>
[PASTE]
</failing test output>

Every reasoning-capable vendor also exposes a named control for how much the model reasons, which is the correct lever when output feels shallow or slow, not re-adding step-by-step language:

None of the three vocabularies line up, so a value that is valid on one provider can be rejected or silently reinterpreted on another. Treat effort settings as provider-specific, not portable. OpenAI's own reasoning documentation is a useful marker of how different the parameter surface has become: it contains zero mentions of the word "penalty" anywhere on the page, a sign of how little the classic sampling-parameter vocabulary (presence penalty, frequency penalty) applies to this model family at all.

Claude's exception: thinking is promptable on purpose

Anthropic's guidance does not fully match the "stop asking" line above, and it says so directly: "Whether Claude thinks on a given turn is promptable. Effort sets the overall posture, but you can also shape the decision directly with natural-language guidance, either globally in the system prompt or per message from the user turn." Anthropic even publishes the wording to use. To suppress unnecessary thinking:

Extended thinking adds latency and should only be used when it will meaningfully improve answer quality, typically for problems that require multistep reasoning. When in doubt, respond directly.

And to invite it on a specific turn: "Please think hard before responding." This is a real, vendor-documented exception to the "never ask a reasoning model to reason" rule above. On Claude specifically, plain-language steering about whether and how much to think is a supported control, not folklore. It is a different instruction from "think step by step," though: you are steering the decision to reason, not scripting the procedure.

Case 3: do you actually need to see the work?

Whether a model reasons internally, and whether you get to watch it reason, are two different settings, and mixing them up is the most common leftover confusion once the step-by-step question is settled. All three reasoning vendors hide the reasoning by default and let you opt into a summary:

• OpenAI: raw reasoning tokens are never exposed, but "you can view a summary of the model’s reasoning using the summary parameter", and that output "will not be included unless you explicitly opt in" to it.
• Anthropic: thinking blocks are visible by default, but a display parameter can set them to "omitted" for faster streaming, or "summarized".
• Google: thought summaries are opt-in too. Google's own words: "By default, only the final output is returned." A thinking_summaries field turns them on.

Why you'd want it visible has nothing to do with whether the model needed the instruction to reason at all: debugging a wrong answer, satisfying a compliance reviewer, teaching someone the method, or building trust in a recommendation all call for visible reasoning. None of that is free, either way. OpenAI bills reasoning tokens as output tokens whether or not you request the summary, and Anthropic's documentation is explicit that thinking tokens "are billed as output tokens, even when the thinking text isn't returned to you, and they count toward max_tokens alongside the response text." Google tracks the two separately in its usage metadata (thoughtsTokenCount distinct from the response tokens), but its documentation does not state as plainly whether an output-length cap can be exhausted by thinking before any visible text is produced. Treat that specific interaction as unverified rather than assuming it behaves like OpenAI's.

Speaking of caps: OpenAI's guidance is unusually concrete about the failure mode. If reasoning and output together hit your token ceiling, the response comes back with status: "incomplete". OpenAI's own words: "This might occur before any visible output tokens are produced, meaning you could incur costs for input and reasoning tokens without receiving a visible response." That is a real trap for anyone porting a working prompt from a classic model to a reasoning one without raising the ceiling. OpenAI's own advice is to reserve a large buffer, at least 25,000 tokens, while you learn how much a given prompt actually needs.

So, should you ask for step-by-step reasoning?

Three questions, in order, cover it:

1. Does the model already reason internally? If there's no effort or thinking-level control, the answer is no: ask for the steps, it still works.
2. If it does reason, does the vendor say chain-of-thought instructions help or hurt? OpenAI and Google say hurt or do nothing; Anthropic says thinking itself is promptable in plain language, which is a different instruction than scripting the procedure.
3. Do you need to see the reasoning, independent of the first two answers? If yes, opt into the vendor's summary or display setting — it costs the same tokens either way.

The short version

The advice did not disappear, it split. On a classic model, "let's think step by step" is exactly as useful as it was in 2022. On a reasoning-native model, the same words are redundant at best and, per OpenAI's and Google's own documentation, sometimes actively worse than a direct instruction with a goal, constraints, and an output contract. Whether to display the reasoning is a third, independent choice, opt-in on every vendor checked here, and billed the same whether you look at it or not. Get the first question right, whether this model reasons already, and the rest of the decision mostly makes itself. Tools like Prompt Architects restructure a casual prompt into goal-constraints-format shape on request, which is most of the rewrite this page describes, done automatically.