Extended thinking vs chain of thought
Asking a model to show its working and configuring a reasoning budget are different mechanisms with different costs. One is a prompting technique that has largely been superseded; the other is a parameter.
Short answer
Prompted chain of thought asks the model, in words, to write its reasoning into the answer. Extended thinking is a configured budget for reasoning that happens in its own blocks before the answer. On current models reasoning depth is set through the thinking parameter and an effort level, so instructions like think step by step are at best redundant. Prompting still decides what the model should weigh and how the answer should be structured. It no longer decides whether the model reasons at all.
For a long time the only lever anyone had was the prompt, so getting a model to reason meant asking it to. Think step by step, show your working, list the considerations before concluding. The technique worked, it was widely taught, and it left a large population of practitioners for whom reasoning is something you request in words.
That is no longer where the lever is. Reasoning depth is now configured rather than asked for, and the reasoning happens in dedicated thinking blocks that are separate from the response. The change is not cosmetic. It moves reasoning out of the answer, so your parsers stop seeing an essay in front of the JSON. It makes the cost explicit and boundable rather than an emergent property of how you phrased the request. And it introduces a handling requirement that did not exist before, because those thinking blocks have to be preserved when a conversation continues through a tool loop.
The distinction matters in production for the same reason it matters in an exam. A prompt full of reasoning incantations on a model with adaptive thinking is spending tokens on an instruction the model has already acted on, and it hides where the real control is.
Prompted chain of thought vs Extended thinking, side by side
| Prompted chain of thought | Extended thinking | |
|---|---|---|
| Where the reasoning lives | In the response text, where your users and your parser both see it | In separate thinking blocks, distinct from the answer |
| How you control it | By wording, which is indirect and hard to hold steady | By configuration: a thinking parameter and an effort level |
| Cost | Reasoning tokens are answer tokens, so the bill grows with verbosity | Reasoning tokens are billed and bounded by the budget you set |
| Effect on output shape | Your structured output now has prose in front of it | The answer stays the answer |
| Multi-turn tool use | Nothing special to preserve | Thinking blocks must be returned unmodified when the loop continues |
| What it is still good for | Telling the model what to weigh, and asking it to quote evidence before concluding | Giving hard analysis genuine room without polluting the response |
Two things wearing one name
Chain of thought describes a behaviour: reasoning expressed as text on the way to an answer. Extended thinking describes a mechanism: a configured allowance for reasoning that the model performs in blocks of its own before responding.
Conflating them produces two specific errors. The first is believing that a prompt can substitute for the parameter, which leads to prompts stuffed with reasoning instructions on models where depth is already configured. The second is believing that the parameter makes prompting irrelevant, which leads to prompts that state a goal and leave out the criteria, the constraints and the evidence the model should be reasoning over. Both mistakes come from treating the pair as competing versions of the same idea rather than as a technique and a setting.
Reasoning is configured, not requested
On current models the depth of reasoning is set through the thinking parameter and an effort level rather than through the wording of the request. That is what makes the old incantations redundant: the model is not waiting to be told to think, it is operating within a budget you have already set.
The practical consequence is where you go when the answer is underdone. The first question is no longer how to phrase the instruction more emphatically. It is whether the budget is right for the task, and whether the model was given the material the reasoning needs. Emphatic phrasing is worse than neutral here anyway, because current models follow instructions more literally and escalating language tends to overtrigger.
More thinking is not more correct
Thinking tokens are real tokens: they are billed, they take time, and they consume part of the same window everything else lives in. Raising the budget on a task that does not need it buys latency and cost with no improvement, which is why it is a poor default rather than a safe one.
More importantly, thinking cannot supply information the model does not have. If an answer is wrong because a document was not attached, because the retrieved passage was the wrong one, or because the source is out of date, a larger reasoning budget produces a better argued version of the same wrong answer. Diagnose whether the failure is one of reasoning or of inputs before turning the dial, because only one of the two responds to it.
What prompting is still for
Configuration decides how much reasoning happens. The prompt still decides what it is about, and that is not a small residue.
Stating the criteria that matter, naming the constraints that are not obvious from the request, and giving the reason behind an instruction all steer reasoning toward the right considerations. Asking the model to quote the relevant passages before reasoning over them is still one of the highest-value instructions available on long-document tasks, because it grounds the conclusion and makes it auditable. And the shape of the answer, including what to return when the evidence does not support a conclusion, is entirely a prompting concern.
Thinking blocks have to survive the tool loop
This is the operational detail most likely to appear as a defect rather than as a design question. When extended thinking is in use and the conversation continues through a tool-use loop, the thinking blocks from earlier turns must be passed back unmodified along with the rest of the assistant's content.
Code that rebuilds the message history by extracting only the text, or that strips anything it does not recognise while trimming for token budget, will drop them. The symptom is a loop that degrades or errors partway through rather than failing immediately, which makes it awkward to trace. Treat the assistant's content as an opaque list to be appended and returned, not as a structure to be filtered.
How to choose
Reach for prompted chain of thought when
- You want the reasoning visible to a human reader as part of the answer
- You need the model to weigh specific named criteria, which is a prompting job
- You want conclusions grounded in quoted evidence from a supplied document
- You are working with a model or surface where a thinking budget is not available
Reach for extended thinking when
- The task is genuinely hard analysis and the material is already present
- Downstream code parses the response and must not receive reasoning prose
- You need the cost of reasoning to be bounded and visible rather than emergent
- The difficulty is in the working out, not in what the model was given
Where candidates go wrong
Trap 1: add think step by step and the model reasons harder
On models with adaptive thinking this is at best a no-op, and it is often mildly harmful because it spends tokens and adds an instruction competing with the ones that matter. Reasoning depth is configured; the phrase does not reach the control. The distractor is attractive because the technique genuinely worked and is still repeated widely. Options that respond to a reasoning shortfall by rewording the request, when the scenario mentions a thinking budget or an effort level, are testing whether you know where the lever moved to.
Trap 2: raise the thinking budget whenever accuracy matters
This treats the budget as a general quality dial. It is not one. It buys room to work through a problem, and it does that for problems whose difficulty is in the working out. When an answer is wrong because the information was stale, missing or never retrieved, more reasoning produces a more confident version of the same error. The correct move is to fix the inputs: attach the document, check what retrieval returned, confirm the source is current. A scenario that mentions out of date information and offers a larger reasoning budget as a remedy is offering the wrong remedy.
Trap 3: strip the thinking blocks before the next turn
It looks like reasonable hygiene. The blocks are verbose, they are not the answer, and trimming them appears to save tokens on the next call. When a conversation continues through a tool loop with extended thinking in use, they must be returned unmodified. This usually arrives as a bug rather than a decision: a helper that rebuilds history from text content only, or a trimming routine that discards unrecognised block types. Append the assistant's content as it came back, and do any token management somewhere that does not rewrite the current turn.
Trap 4: show the thinking to the user as the explanation
Thinking blocks are working notes, not an audit trail, and they are not written for an audience. They can explore paths the final answer abandons, and they are not a faithful account of how the answer was produced, so presenting them as a justification is misleading in both directions. If users need an explanation, ask for one in the response, where you can specify its form and hold it to a standard. If you need traceability, ask the model to cite or quote the evidence it relied on. Both are prompting problems with prompting answers, and neither is solved by surfacing the reasoning stream.
How the exam tests it
Prompt and Context Engineering is 11.0% of the CCDV-F blueprint, roughly 6 of the 53 scored questions, with Prompt Engineering at 4.6% of the whole exam. This distinction is where experienced practitioners lose marks, because the superseded technique is the one most widely taught and the questions are often built from a scenario in which the old answer is still on the list.
Common questions
Is think step by step still worth putting in a prompt?
Rarely, on models with adaptive thinking. Reasoning depth is configured through the thinking parameter and an effort level, so the instruction does not reach the control it appears to. Prompting is still the right lever for what the model should weigh, and for asking it to ground conclusions in quoted evidence.
What is the actual difference between the two?
Prompted chain of thought is a technique that puts reasoning into the response text. Extended thinking is a mechanism that gives the model a configured budget to reason in separate blocks before the response. One is wording, the other is a setting, and only the setting bounds the cost.
Does a larger thinking budget make answers more accurate?
Only when the difficulty is in the working out. Thinking fetches nothing, so an answer that is wrong because a document was missing, stale or badly retrieved does not improve with more of it. Check the inputs before raising the budget, and remember that thinking tokens are billed and consume window.
Do I need to send thinking blocks back during a tool loop?
Yes. When extended thinking is in use and the conversation continues through tool results, earlier thinking blocks must be returned unmodified with the rest of the assistant's content. Code that rebuilds history from text alone, or that strips unrecognised block types while trimming, will break the loop in ways that are awkward to trace.
Should I show the thinking to end users?
Generally no. Thinking blocks are working notes rather than an explanation written for a reader, and they may explore paths the answer abandons, so they are not a reliable justification for it. If users need an explanation or a citation, ask for it in the response where you can hold it to a standard.
Practise this
Prompt and Context Engineering is 11% of the CCDV-F blueprint, and the bank is weighted to match. Every option carries a written explanation, not just the correct one, so a distinction like this one is explained where you get it wrong.
See CCDV-FOther CCDV-F distinctions
Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.