The phrase “think step by step” has become one of the most famous shortcuts in prompt engineering. In 2022, Chain of Thought studies showed that inducing large models to produce intermediate steps could improve arithmetic, logic, and symbolic reasoning tasks. The effect was so striking that the expression ended up being treated as a kind of universal intelligence button.
In 2026, this habit needs to be reviewed. The main providers now offer models that already perform internal reasoning before responding and, in many cases, also expose their own controls to decide how much computational effort to use. The practical consequence is important: writing a detailed “thought” script at the prompt is no longer the best starting point for many tasks.
This does not mean that decomposition, verification or explanation have lost value. It means they now need to be used for the right reason. The prompt should clearly state what needs to be resolved, what constraints matter, what evidence is needed, and how the answer should be presented. The amount of reasoning, when the API allows it, becomes a separate control.
“Think step by step” is not dead; changed role
The classic Chain of Thought was born in a different generation of models than today. The work of Jason Wei and coauthors showed that examples with intermediate steps could improve the performance of large models on problems that required multiple inferences. Shortly afterwards, Takeshi Kojima and co-authors popularized Zero-shot-CoT by observing gains in several benchmarks simply by adding an instruction equivalent to “let's think step by step”.
These results were real within the conditions studied, but they did not create a permanent law of prompting. They showed how certain models of that time could be induced to better use their latent capacity. Today, part of this behavior has been incorporated into the process of inferring reasoning models.
So the useful question in 2026 is not “Does CoT work or not?” The question is: “Which part of the
problem should stay in the prompt, which part should be in the API reasoning/thinking control and which part needs to appear to the user?”.
What has changed in reasoning models
A practical way to think about current prompting is to separate three layers that used to be mixed together.
The first layer is the task specification. It includes objective, context, constraints, available data, success criteria, and output format. This layer remains the responsibility of the prompt. The more ambiguous the task, the more important it is to make it explicit.
The second layer is allocation reasoning. In several current APIs, this can be controlled by parameters such as reasoning effort, effort or thinking level. This control determines how much internal work the model can dedicate before or during producing the response. It replaces, in part, the old impulse to try to “force” depth by repeating instructions like “think more”, “reflect” or “revise several times”.
The third layer is the visible explanation. A good explanation does not need to be a transcription of internal reasoning. For most products, it is most useful to ask for a verifiable justification: assumptions used, essential calculation, evidence, limitations, decision criteria, and conclusion. This produces auditable output without relying on a complete internal chain.
This separation resolves a recurring confusion. “I want the model to reason better” and “I want the user to understand why the answer makes sense” are different goals. The first can be handled by the model and the API; the second needs to be specified in the output.
Practical matrix: OpenAI, Claude and Gemini
All three ecosystems have moved in the same general direction - more internal reasoning and more inference controls - but they do not use the same interface. Copying the same prompt and parameters between providers is a fragile strategy.
OpenAI: objective and criteria in prompt, effort in API
OpenAI's official guidance for reasoning models is straightforward: simple, clear prompts tend to work best, and instructions to “think step by step” or “explain your reasoning” are unnecessary for this family. The documentation also recommends specifically defining the end goal and constraints that characterize a successful response.
In current models in the GPT-5.6 family, the API offers reasoning.effort with levels that can include none, low, medium, high, xhigh and max, depending on the model. The idea is not to always select the highest value. The practical recommendation is to test the lowest effort that still maintains the quality required in your workload and move up when representative evaluations show real gain.
This changes the function of the prompt. Instead of writing “think hard, consider alternatives, check everything and only then respond”, it is more efficient to say what needs to be delivered: “identify the risks that could cause data loss, estimate impact and probability, propose mitigation and prioritize the five most important ones”. The model is given a verifiable target; the reasoning effort is in the appropriate parameter.
When it is necessary to show the user how the conclusion was supported, ask for an objective explanation, relevant evidence, or a summary of the available reasoning. Do not treat the complete internal chain as a product requirement.
Claude: adaptive thinking and effort replace old scaffolds
In today's Claude, the change is equally clear. Claude Sonnet 5 operates with adaptive thinking by default, and the effort parameter controls the balance between intelligence, tokens, cost and latency. In recent models, Anthropic recommends increasing effort when a complex task is receiving superficial reasoning, rather than trying to compensate with a large script of instructions.
Anthropic's own prompting documentation suggests preferring general guidance over overly prescriptive steps. A prompt like “think carefully about the problem” can be more helpful than a rigid six- or ten-step human plan, because the model can come up with a better strategy than the sequence written by the prompter.
This does not make process instructions useless. They remain important when the process is part of the task. If there is an operational order that needs to be respected, approval before an action, a source that must be consulted or a validation checkpoint, describe these steps. What has lost value is using a pseudo-algorithm for reasoning just to try to make the model “smarter”.
There is still a version difference that deserves attention. Old Claude setups used thinking with budget_tokens in some models. In recent models, Anthropic has migrated to adaptive thinking and effort. Prompts and code from 2024 or 2025 may therefore carry a technique or parameter that no longer represents current best practice.
Gemini: thinking level is the main control for series 3
In Gemini, series 3 and 2.5 models use process thinking, but controls vary by generation. In the Gemini 3 series, the thinking_level parameter controls the relative maximum depth of reasoning. Available levels depend on the model and may include minimal, low, medium and high. The documentation also advises using less thinking on simple tasks and increasing the level on complex programming, mathematics or multi-step planning problems.
The Gemini 3 series guide is especially explicit about prompting: direct, concise instructions tend to work best, while very verbose or complex prompt engineering techniques inherited from older models can induce excessive analysis. For migrations, Google recommends trying simplified prompts and using thought tracking rather than relying on textual Chain of Thought.
In the Gemini 2.5 series, thinking_budget still appears as a control mechanism in certain models. Therefore, “Gemini” should not be treated as a uniform API. Before reusing a prompt, confirm whether the model works with budget, level or dynamic behavior and which values it actually supports.
Gemini also separates internal thinking from presentation. The API can provide thought summaries when configured to do so, while the final response remains a distinct artifact. Again, the useful rule is to ask the model for a user-friendly explanation, not to assume that the complete internal chain is the best form of justification.
Four old prompts rewritten for 2026
The classic “think step by step”
Old prompt: "Solve this problem. Think step by step and only then give the answer."
Current version: "Solve this problem. Consider all given constraints, verify that the conclusion is consistent with the data, and deliver the final answer with a short, verifiable justification."
The new version does not attempt to describe how the model should think. It describes what an acceptable response means. In a reasoning model, this is usually a better sign.
“Show all your reasoning”
Old prompt: “Show all your internal reasoning, without skipping any steps.”
Current version: “Give the conclusion and explain the elements necessary to verify it: relevant premises, essential calculation, evidence used and any uncertainty that could change the decision.”
This exchange improves the exit contract. The reader receives material to check the answer, without transforming the model's internal process into a requirement.
“Review, rethink and triple check”
Old prompt: “Do the analysis, review everything, rethink the solution and triple check before responding.”
Current version: “Success criteria: do not omit dependencies, detect inconsistencies between data, flag insufficient information and do not state a conclusion that cannot be supported.”
In models that already perform self-evaluation or internal verification, repeating review commands can only increase cost and latency. Objective criteria allow you to measure whether the response passed or failed.
A strict ten-step roadmap
Old prompt: “First identify the problem, then list hypotheses, then generate three options, then critique each option, then choose one…”
Current version: "Objective: choose the most appropriate alternative. Consider cost, risk, reversibility and impact. Compare relevant options, discard those that violate restrictions and deliver the recommendation with the criteria that determined the choice."
The detailed roadmap still makes sense if each step produces an artifact that another part of the system needs to consume. If there is no such requirement, let the model choose the internal strategy and describe only the decision criteria.
When decomposing is still the right technique
The demise of explicit CoT as a universal trick does not reduce the value of workflow decomposition. In fact, this distinction has become more important.
Dividing a task into separate calls remains useful when one step needs to be inspected before the next, when different tools are called at different times, when there is human approval, when the intermediate result needs to be stored, or when a failure must be isolated without redoing the entire process.
It also makes sense to decompose when the system needs to apply different models to different parts of the job. One model might extract data, another evaluate evidence, and a third write the final output. Here, the chain exists in the architecture of the application, not as an attempt to make the internal reasoning of a single call visible.
The common mistake is to confuse these two things. “Do these three steps because my pipeline depends on them” is a legitimate operational instruction. “Do these ten steps because I imagine this is the best way to think” is a prompting hypothesis that needs to be tested, not assumed.
How to choose reasoning effort or thinking level
The safest rule is to treat effort as a performance parameter, not as a seal of quality. More thinking can improve difficult tasks, but it also increases tokens, cost, and time to response. On simple tasks, a high level may waste resources without measurable gain.
Start with an intermediate setting or the default recommended by the model. Then, perform the same battery of tasks at a level below and at a level above. Compare correctness, completeness, adherence to constraints, correct use of tools, latency and cost. The best level is the lowest that consistently meets your quality criteria.
This evaluation must use real examples of the product. A mathematics benchmark does not necessarily predict behavior in customer service, document analysis, structured extraction or automation with tools. The parameter must be calibrated in the workload that actually goes into production.
It is also important to test prompt and effort separately. If you change the prompt text and the thinking level at the same time, it is difficult to know which change caused the gain or the regression. In model migrations, preserve a baseline, change one variable at a time, and record the effect.
Visible explanation is not Chain of Thought
There is an additional reason to abandon the “show all reasoning” requirement: a good interface rarely needs it.
In a financial analysis, the user wants to know which numbers were used, which formula was applied and which hypotheses change the result. In a code review, you want the problematic line, the impact, and the suggested fix. In a purchasing decision, you want criteria, trade-offs and limits. In research, you want sources, method and degree of confidence.
These elements are verifiable and actionable. They can be explicitly requested in the prompt and evaluated by tests. An extended transcript of reasoning, on the other hand, can be long, difficult to audit, and is not always the best interface to justify a conclusion.
Therefore, the recommended pattern is to specify the evidence that should appear. Ask “cite the data used”, “show the essential calculation”, “explain the two criteria that weighed most”, “point out the dominant uncertainty” or “say what would make the conclusion change”. This produces useful transparency without turning internal reasoning into a product.
What's still worth learning from the classic Chain of Thought
The old CoT continues to teach two important ideas. The first is that complex tasks benefit from structure. The second is that models can respond better when they receive clear signals that a conclusion requires multiple relations and not just superficial retrieval.
What has changed is the way of applying these ideas. In models without modern reasoning features, in smaller models or in specific tasks, examples with intermediate reasoning can still help and should be evaluated empirically. In current reasoning models, however, the most robust starting point is a result-oriented prompt, combined with the effort control that the API offers.
If a task fails, avoid automatically adding more phrases like “think better”, “be very careful” or “do it step by step”. First ask what information was missing from the contract. Was the objective clear? Were the restrictions explicit? Did the model know what success meant? Did the output format allow checking the result? Was the effort adequate to the complexity? Was there a step that should really be separated in the workflow?
This diagnostic sequence often produces prompts that are more portable across providers and easier to maintain across model changes.
The rule of thumb for 2026
For reasoning models, treat “think step by step” as a useful historical technique, not as an obligatory phrase. Start with the objective, context, constraints, success criteria and output format. Use reasoning effort, effort or thinking level when the provider offers this control. Prescribe steps only when they are part of the process that needs to be performed or audited.
And when the answer needs to be explained, ask for a verifiable justification rather than a complete internal chain. Prompt engineering in 2026 is less concerned with teaching the model to think as you imagined and more concerned with defining precisely what it needs to solve, how much effort it should expend, and what evidence needs to appear in the answer.
