Prompting Reasoning Models: Why Old Prompt Tricks Now Backfire

What you need to know

For five years, prompt engineering was the art of compensating for models that could not plan. You said "think step by step" because otherwise they would not. You wrote numbered procedures because the model would not decompose the problem itself. You stacked few-shot examples to teach a format, and added "be concise" because verbosity was the default failure mode. Every trick was a workaround for a missing capability — and as of July 2026, the capability is no longer missing. Anthropic's Claude models ship with extended thinking (and, on the newest models, adaptive thinking that decides for itself when to deliberate); OpenAI's GPT-5-family reasoning models, descendants of the o-series, expose a reasoning_effort dial; Google's Gemini models think dynamically by default, with a parallel-reasoning Deep Think mode at the top of the range; and the open-weight DeepSeek R1 lineage brought visible reasoning traces to anyone with GPUs.

The uncomfortable consequence: a large share of the prompt patterns your team accumulated between 2021 and 2024 now range from redundant to actively harmful. The model already deliberates before answering; instructing it to deliberate again wastes the most expensive tokens on the price list. It already builds its own plan; handing it yours constrains it to yours. Here is what changed, how each provider's thinking controls work, and the patterns that replace the old ones.

• Reasoning models allocate their own deliberation — a thinking phase runs before the answer, sized by a parameter, not by your prompt.
• Manual chain-of-thought is now officially discouraged by both OpenAI's and Anthropic's prompting guidance.
• Prescriptive step lists cap the model's plan at the quality of yours — state goals, constraints and success criteria instead.
• Thinking tokens are billed as output tokens on Claude, OpenAI and Gemini alike — budgets are a cost decision, not just a quality one.
• Explicit steps still have a place: compliance workflows and deterministic formats, where the steps are the requirement, not a reasoning aid.

How thinking budgets actually work

Under every provider's branding, the mechanism is the same: before producing the visible answer, the model generates reasoning tokens — a private working-through of the problem — and you control how many it may spend. What differs is the control surface, and in 2026 two generations of it live side by side: explicit token budgets on older models, and effort-style dials on newer ones that let the model size its own deliberation.

Claude. On Claude Opus 4.5, Haiku 4.5 and the Claude 4.x generation, you enable manual extended thinking with thinking: {"type": "enabled", "budget_tokens": N}, where the budget must sit below max_tokens. Anthropic's docs note that larger budgets can improve quality on complex problems, "although Claude may not use the entire budget allocated, especially at ranges above 32k". From Claude Opus 4.6 and Sonnet 4.6 onwards, budget_tokens is deprecated, and on Opus 4.7 and later it returns a 400 error outright: the replacement is adaptive thinking plus the effort parameter (low, medium, high — the default — xhigh and max), where the model decides when and how deeply to think and effort governs total token spend, including tool calls. The migration looks like this:

// Before: manual thinking budget (Claude Opus 4.5 / Claude 4.x era)
{
  "model": "claude-sonnet-4-5",
  "max_tokens": 16000,
  "thinking": {"type": "enabled", "budget_tokens": 10000},
  "messages": [{"role": "user", "content": "..."}]
}

// After: adaptive thinking + effort (current Claude models)
{
  "model": "claude-opus-4-8",
  "max_tokens": 16000,
  "thinking": {"type": "adaptive"},
  "output_config": {"effort": "high"},
  "messages": [{"role": "user", "content": "..."}]
}

OpenAI. The GPT-5-family reasoning models take a reasoning_effort parameter whose full value set is none, minimal, low, medium, high and xhigh — individual models support subsets, and defaults vary by model (GPT-5.5, for instance, defaults to medium). Reasoning tokens are never shown to you via the API, but they occupy context-window space and are billed as output tokens; OpenAI's docs recommend "reserving at least 25,000 tokens for reasoning and outputs" when you start experimenting.

Gemini. The 2.5 generation exposed a literal token budget: thinkingBudget ranges from 128 to 32,768 tokens on 2.5 Pro (which cannot disable thinking), 0 to 24,576 on 2.5 Flash, and 512 to 24,576 on 2.5 Flash-Lite, with -1 selecting dynamic thinking. The Gemini 3 generation replaced the raw number with a thinking_level of minimal, low, medium or high (again, subsets per model), and thinks dynamically by default. Deep Think — Google's parallel-reasoning mode — sits above all of this for the hardest science and maths problems, in the Gemini app for AI Ultra subscribers and via the API for selected partners.

DeepSeek R1. The open-weight outlier has no budget parameter at all: R1 emits its reasoning inside <think> tags and you steer depth through the prompt. DeepSeek's usage recommendations are strikingly specific — temperature between 0.5 and 0.7, no system prompt at all (put every instruction in the user turn), and, if the model skips deliberation, forcing the response to open with <think>\n.

Provider / family	Control parameter	Values or range (July 2026)	Billing note
Claude Opus 4.5, Haiku 4.5, Claude 4.x	thinking.budget_tokens	Below max_tokens; budgets above ~32k often not fully used	Full thinking tokens billed as output, even when summarised
Claude Opus 4.6+ / Sonnet 5 and later	thinking: adaptive + output_config.effort	low / medium / high (default) / xhigh / max	Effort governs all output spend, tool calls included
OpenAI GPT-5.x reasoning models	reasoning_effort	none / minimal / low / medium / high / xhigh (model-dependent)	Reasoning tokens invisible but billed as output
Gemini 2.5 series	thinkingBudget	Pro: 128–32,768 (cannot disable); Flash: 0–24,576; -1 = dynamic	Response priced as output tokens + thinking tokens
Gemini 3.x series	thinking_level	minimal / low / medium / high (subset per model)	Dynamic thinking by default
DeepSeek R1 (open weight)	None — prompt-steered	Reasoning in <think> tags; temperature 0.5–0.7 advised	Self-hosted cost is GPU time, not tokens

On sizing: dynamic and default settings are the right starting point for most workloads. Where you do pin a manual budget, Anthropic's documentation examples use around 10,000 tokens for hard single-pass analysis, and the note that budgets above 32k frequently go unused marks where diminishing returns begin. The tens of thousands of tokens that genuinely hard, multi-step problems consume belong behind an explicit routing decision, not in your default request template.

Why "think step by step" now backfires

Chain-of-thought prompting earned its place honestly. The original research — Wei et al., 2022 — showed that asking a large model to produce intermediate reasoning steps dramatically improved arithmetic and logic performance. But the trick worked by eliciting a behaviour the model would not otherwise perform. Reasoning models are trained, largely through reinforcement learning, to perform that behaviour by default, in a dedicated thinking phase, before a single answer token appears. Prompting for it again does not add a second layer of insight; it adds a second, redundant layer of tokens.

Both major labs now say this in plain terms. OpenAI's reasoning best-practices guide: "Avoid chain-of-thought prompts: Since these models perform reasoning internally, prompting them to 'think step by step' or 'explain your reasoning' is unnecessary." Anthropic's prompting best practices go further, targeting the prescriptive step list specifically: "Prefer general instructions over prescriptive steps. A prompt like 'think thoroughly' often produces better reasoning than a hand-written step-by-step plan. Claude's reasoning frequently exceeds what a human would prescribe." That last sentence is the crux. A hand-written plan is a ceiling: the model will follow your four steps even when the problem needed six, or needed a decomposition you did not anticipate. You are no longer scaffolding a weak reasoner — you are constraining a strong one.

The evidence extends beyond vendor guidance. The DeepSeek-R1 paper (arXiv:2501.12948) reports that R1 "is sensitive to prompts" and that few-shot prompting — worked examples with reasoning spelled out, the classic CoT scaffold — "consistently degrades its performance"; the authors recommend describing the problem zero-shot and specifying only the output format. Example reasoning chains in the prompt anchor the model to the shape of your examples rather than the shape of the actual problem.

One caveat keeps this honest: the rule is provider- and model-specific, not universal. DeepSeek's own usage notes still recommend a directive like "Please reason step by step, and put your final answer within \boxed{}" for mathematical problems on R1 — a phrase that triggers the trained reasoning format rather than overriding it. The 2026 rule of thumb is not "never say step by step"; it is "stop assuming the model needs your steps, and check what the model card actually asks for".

The 2026 playbook: six patterns that work

So what should you actually do? Six patterns, each replacing an older habit, with prompt text to copy.

1. State the goal and constraints, not the procedure

The single biggest rewrite. Delete the numbered method; keep the objective, the hard constraints, and the context the model cannot infer. OpenAI's guidance to keep prompts "simple and direct" and to use delimiters for distinct input sections points the same way: your job is to specify the problem unambiguously, not to solve it in outline.

## Old habit (constrains the model's plan)
Analyze this contract step by step:
1. First, list every clause.
2. Then check each clause against our procurement policy.
3. Then rank issues by severity.
4. Then write a summary. Think carefully at each step.

## 2026 pattern (goal + constraints)
Goal: identify every clause in the attached contract that conflicts
with our procurement policy (attached), ranked by commercial risk.

Constraints:
- Cite clause numbers exactly as they appear in the contract.
- Flag ambiguous clauses as "needs legal review" rather than guessing.
- The contract is governed by the laws of England and Wales; do not
  assume Indian or US conventions.

2. Give success criteria the model can verify

Reasoning models are unusually good at checking their own work — if you tell them what "correct" means. Anthropic's guidance explicitly recommends appending a self-check ("Before you finish, verify your answer against [test criteria]") because it catches errors reliably in coding and maths. Success criteria are the highest-value lines in a 2026 prompt: they redirect thinking tokens from re-deriving the task towards validating the answer.

Success criteria:
- The refactored module compiles with `tsc --strict`, zero errors.
- All existing tests pass unchanged; no test files are edited.
- No new runtime dependencies.

Before you finish, verify the result against each criterion and fix
anything that fails.

3. Nudge depth with words; set budgets with parameters

Adaptive and dynamic thinking are promptable. Phrases like "think thoroughly" or "consider multiple approaches before answering" legitimately elicit deeper reasoning on Claude's adaptive thinking — Anthropic documents the triggering behaviour as steerable in both directions, including sample wording to suppress overthinking ("extended thinking adds latency and should only be used when it will meaningfully improve answer quality... when in doubt, respond directly"). But use words for the marginal nudge and parameters for the policy: if a route always needs deep reasoning, raise effort or reasoning_effort there. The nudge is a hint; the parameter is a contract.

4. Move examples into tools and schemas

Most few-shot examples in legacy prompt libraries exist to teach a format, not a judgement. Reasoning models get the format more reliably from a machine-readable contract: a tool definition with typed parameters, or a structured-output schema. OpenAI's advice is to "try zero shot first, then few shot if needed"; the R1 paper's few-shot finding argues for the same default; and Anthropic's nuance — multishot examples still work with thinking if they demonstrate the reasoning pattern inside <thinking> tags — is best read as guidance for the rare cases where you are teaching judgement, not layout. Our guide to structured output prompting patterns covers the schema side in depth.

5. Keep explicit steps where determinism is the point

There is a class of workflow where the numbered list survives, and should: processes where the steps are the requirement, not a reasoning aid. A KYC review at an RBI-regulated fintech in Mumbai, an FCA-mandated suitability check at a London wealth manager, a fixed-format incident report that downstream tooling parses — in all of these, auditability demands the same procedure every time, in order, with each step's outcome recorded. Write those steps as compliance requirements ("complete and record each check below, in order") rather than as thinking instructions, and let the model reason freely within each step.

6. Design system prompts for the cache

Long system prompts and reasoning models interact through your cache, and the failure mode is silent. On Claude, changing thinking parameters — toggling it, or changing the budget — invalidates message-history cache breakpoints, while cached system prompts and tool definitions survive. So: keep thinking settings stable per route rather than per request; concentrate stable instruction mass in the system prompt where the cache protects it; and for long deliberations note Anthropic's 1-hour cache suggestion, since thinking sessions often outlive the 5-minute default. If your system prompts predate the reasoning era, our system prompt design playbook pairs naturally with this pattern.

Structured output and reasoning models

The pre-reasoning way to get JSON was to police it in the prompt: "respond ONLY with valid JSON", a few worked examples, perhaps a prefilled { to force the opening brace. Reasoning models changed both the problem and the solution. Thinking and answering are now separate phases — the model deliberates in its thinking blocks, then emits the answer — so the old fear that reasoning will leak into the JSON is handled by the architecture, provided you let the phases stay separate. And format enforcement has moved into the API: Anthropic's structured outputs — a JSON output format via output_config.format, plus strict schema validation on tool inputs — are generally available on current Claude models, and Anthropic's migration guidance now points prefill users there, because prefilled assistant turns return a 400 error from the Claude 4.6 generation onwards.

The caveats are about forcing, not formatting. On Claude, tool use alongside thinking supports only tool_choice of auto or none; forcing a specific tool with {"type": "tool", ...} or {"type": "any"} errors out, because a forced first token pre-empts the deliberation phase. The rule that falls out of all this: constrain the answer, never the thinking. Put the schema on the output, keep the prompt about the task, and check your provider's compatibility matrix before combining thinking with any mode that dictates the model's first visible token.

What thinking actually costs

Thinking tokens are billed as output tokens everywhere that matters: Anthropic charges for the full thinking tokens generated (not the summarised text you see — omitting the display saves latency, not money), OpenAI bills its invisible reasoning tokens as output, and Google prices a thinking-enabled response as the sum of output and thinking tokens (thoughtsTokenCount in the usage metadata). Output rates sit at the top of every price list, so a thinking budget multiplies your most expensive line item — and your latency, since deliberation runs before the first answer token streams. For a Bengaluru document pipeline handling a hundred thousand calls a day, or a London firm paying in pounds for a dollar-denominated API, an unexamined "set it high everywhere" default is the difference between a rounding error and the largest line on the invoice.

Task type	Sensible setting (July 2026)	Cost / latency implication
Classification, extraction, routing, simple lookups	Thinking off or minimal — Gemini Flash thinkingBudget: 0, OpenAI none/minimal, Claude effort: low	Near-baseline cost and latency; deliberation adds nothing here
Moderate analysis — summarise-and-reconcile, single-document reasoning	Dynamic/default — Gemini -1, OpenAI medium, Claude adaptive at default effort; ~10k-token budgets on manual-budget models	Modest overhead; the model skips thinking on easy items
Hard multi-step problems — complex maths, gnarly refactors, multi-constraint planning	High effort/level; on manual budgets, tens of thousands of tokens — recalling that Claude budgets above ~32k often go unused	Output-token spend can exceed the visible answer several times over; latency in minutes, not seconds
Long-horizon agent loops	Claude xhigh with a large max_tokens (Anthropic suggests starting near 64k for Opus-class agents); OpenAI: reserve ≥25,000 context tokens for reasoning + output	The dominant cost centre of the whole system — meter it per run, not per call

Two follow-ons. First, budget-by-route beats budget-by-default: classify requests cheaply, then route only the hard ones to high effort — the discipline covered in our LLM cost optimisation guide. Second, reasoning tokens occupy context; on long-horizon agents, earlier turns' thinking traces interact with your context strategy — exactly the territory of our guide to context engineering for long-horizon agents.

Common pitfalls

Four failure modes account for most of the reasoning-model regressions we see in review.

And the quietest one: benchmark-chasing budgets. A lab's headline score at maximum reasoning tells you what the model can do with effectively unlimited deliberation on curated problem sets — and almost nothing about the budget your invoice-triage flow needs. Tune thinking settings against your own evals, task success rate against cost per task, and treat published benchmarks as an existence proof, not a configuration guide.

Prompt the goal, budget the thinking

The shift is easy to summarise: prompting used to be about supplying the reasoning; now it is about specifying the problem and pricing the deliberation. State goals, constraints and success criteria. Let the model plan. Nudge depth with plain language, set policy with parameters, keep examples in schemas, keep procedures only where auditors need them, and watch the thinking line on your bill the way you watch your database spend. Everything here traces back to the providers' own documentation — and since models now change quarterly, re-read the primary sources before your prompt library fossilises again.

If you have run this migration in production — retired a CoT-era prompt library, cut thinking spend without losing accuracy, built the eval harness that proved it — that is exactly the concrete, verifiable work a Verified Builder profile exists to showcase. The people hiring for AI roles in Bengaluru and London read work like this; make yours findable.

Documentation and research cited: Anthropic, "Building with extended thinking", "Effort", "Prompting best practices" and "Structured outputs"; OpenAI, "Reasoning models" and "Reasoning best practices"; Google, "Gemini thinking" and "Gemini thinking (2.5 API)"; Google DeepMind, "Gemini Deep Think"; DeepSeek-AI, "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning" (arXiv:2501.12948) and the DeepSeek-R1 usage recommendations; Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" (arXiv:2201.11903).