reasoning_extraction is a refusal category on Claude Sonnet 5.5 and Claude Opus 5.5. Both models run safety classifiers that check each request; when one matches, the API returns a refusal instead of an answer. This category fires when a request asks the model to reproduce its internal reasoning in the response text. The decline arrives as a normal HTTP 200 response with stop_reason: "refusal" and stop_details.category: "reasoning_extraction" - a refusal as an API contract, not an error.
What triggers it
Prompts written for setups with thinking off, where the only way to get reasoning was to ask for it in the output: “include your reasoning in the response”, or a required reasoning section standing in for thinking. The Opus 5.5 guide lists reasoning_extraction among its safeguard categories, so a prompt that worked on an older model can be refused now - and since September 2026 a reasoning_extraction refusal before any output is billed.
Why it hurts more than other refusals
Some refusals get retried for you. With server-side fallback (a beta API option), the API re-runs a declined request on another model. On Sonnet 5.5 that covers cyber declines (requests that could enable cyber harm) and frontier_llm declines (requests that could help develop competing AI models). It does not cover reasoning_extraction on either model - the refusal comes straight back to your code.
Fix
- Remove the instruction from the prompt.
- Read the reasoning from the response’s thinking blocks instead. Thinking blocks are separate content blocks that carry the model’s reasoning;
adaptivethinking lets the model decide how much to think, anddisplay: "summarized"returns a readable summary of it:
{ "thinking": { "type": "adaptive", "display": "summarized" } }In context: Claude 5.5 prompt audit: the bad lines weren’t there.