How much explicit chain-of-thought prompting is redundant on reasoning models?

## What changed For several years the default advice was to make the model reason explicitly, because it would otherwise jump straight to an answer. By mid-2026 the frontier models in wide use deliberate internally before responding, and the amount of that deliberation is typically controlled as a provider-side budget or effort setting rather than through prompt phrasing. That inverts part of the old playbook: the technique that used to be the main lever is now partly built in, and prompts written against the old assumption are carrying dead weight. This is contested ground, and an honest answer says so. There is no consensus that explicit structure is *always* useless on reasoning models — several teams still find gains from domain checklists and from constraining the shape of the deliberation. What is well supported is that the generic trigger has lost most of its value and that stacking a long scaffold on top of internal deliberation is not additive. ## Redundant versus still valuable A useful split: **Redundant (elicit).** "Think step by step." "Take your time." "Before answering, reason carefully." "Write at least ten sentences of analysis." These try to *cause* reasoning the model already does, and the length mandates in particular substitute volume for direction. Length instructions can be actively harmful: they force generation past the point of usefulness and can conflict with an internal budget. **Still valuable (direct).** "Check the effective date before the rate." "Verify each referenced clause exists in the supplied document." "List the assumptions you had to make." "Confirm the units match before comparing." These carry information the model does not have — your domain's failure modes, the order in which checks matter, what counts as done. No amount of internal deliberation supplies that. The test to apply to each line of a legacy prompt: **does this tell the model to reason, or does it tell the model what to reason about?** Delete the first kind; keep and sharpen the second. ## The double-payment problem When a scaffolded prompt runs on a model that deliberates internally, both happen. The model thinks, and then it also writes the scripted scratchpad the prompt demanded. You pay for both, latency grows with both, and the scripted section can cut across conclusions the internal reasoning already reached — producing output that is more confident, longer, and no more accurate. The failure is quiet: nothing errors, the response looks richer, and the cost line moves. ## How to find out for your workload The only evidence that transfers is a direct comparison on your own tasks: run the prompt with the reasoning block and without it, on the same fixed set of cases, and compare accuracy, cost and latency. Release notes describe capability, not the interaction between your specific instruction and your specific task. And the model cannot tell you — asking it whether its own prompt still needs the block returns generated text, not evidence. Because the answer changes per model, this is not a one-time cleanup. It is a check to repeat whenever you move to a new model version, alongside the rest of your prompt suite. ## What a lead owns here - **An abstraction boundary.** Keep the reasoning-eliciting layer separable from the task content, so that switching it off, on, or over to a provider-side effort setting is a configuration change rather than an edit across dozens of prompts. - **A re-tuning budget on upgrades.** A model upgrade is not free even when the API is unchanged; assume prompt work and re-measurement, and plan for it rather than discovering it in a regression. - **Portability expectations.** A prompt tuned hard against one model's reasoning behaviour is a lock-in cost. If multi-provider flexibility matters, prefer directing content — which transfers — over eliciting scaffolds, which do not. - **The auditability question, kept separate.** If a compliance or product requirement calls for a written rationale beside each decision, that is a deliverable, not a quality technique. Producing a rationale for the user does not make the decision better, and internal deliberation is often exposed only as a summary rather than as a verbatim trace. Design the rationale as its own output, with its own review and retention rules, and do not conflate delivering it with improving accuracy. ## What good looks like A strong answer refuses the binary. It does not say "prompt engineering is dead", and it does not defend keeping every legacy block. It separates eliciting from directing, names the double-payment cost, insists on a per-model comparison as the only real evidence, and treats visible rationale as a separate product requirement. It also concedes what is genuinely unsettled — that on some tasks explicit structure still helps and nobody has a clean rule for which.