Adaptive thinking is the recommended way to use extended thinking with Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, and Claude Sonnet 4.6. On Claude Fable 5 and Claude Mythos 5, thinking is always enabled and cannot be disabled; adaptive thinking is the only thinking mode. On Claude Mythos Preview, adaptive thinking is the default mode and auto-applies whenever thinking is unset. Instead of manually setting a thinking token budget, adaptive thinking lets Claude dynamically determine when and how much to use extended thinking based on the complexity of each request. On Claude Opus 4.8 and Claude Opus 4.7, adaptive thinking is the only supported thinking mode; manual thinking: {type: "enabled", budget_tokens: N} is no longer accepted.

Supported models

Adaptive thinking is supported on the following models:

• Claude Fable 5 (claude-fable-5) and Claude Mythos 5 (claude-mythos-5), adaptive thinking is always on; thinking: {type: "disabled"} is not supported
• Claude Mythos Preview (claude-mythos-preview), adaptive thinking is the default; thinking: {type: "disabled"} is not supported
• Claude Opus 4.8 (claude-opus-4-8), adaptive thinking is the only supported thinking mode. Thinking is off unless you explicitly set thinking: {type: "adaptive"} in your request; manual thinking: {type: "enabled"} is rejected with a 400 error.
• Claude Opus 4.7 (claude-opus-4-7), adaptive thinking is the only supported thinking mode. Thinking is off unless you explicitly set thinking: {type: "adaptive"} in your request; manual thinking: {type: "enabled"} is rejected with a 400 error.
• Claude Opus 4.6 (claude-opus-4-6)
• Claude Sonnet 4.6 (claude-sonnet-4-6)

How adaptive thinking works

In adaptive mode, thinking is optional for the model. Claude evaluates the complexity of each request and determines whether and how much to use extended thinking. At the default effort level (high), Claude almost always thinks. At lower effort levels, Claude may skip thinking for simpler problems.

Adaptive thinking also automatically enables interleaved thinking. This means Claude can think between tool calls, making it especially effective for agentic workflows.

How to use adaptive thinking

Set thinking.type to "adaptive" in your API request:

Adaptive thinking with the effort parameter

You can combine adaptive thinking with the effort parameter to guide how much thinking Claude does. The effort level acts as soft guidance for Claude's thinking allocation:

Streaming with adaptive thinking

Adaptive thinking works seamlessly with streaming. Thinking blocks are streamed via thinking_delta events just like manual thinking mode:

Adaptive vs manual vs disabled thinking

Important considerations

Validation changes

When using adaptive thinking, previous assistant turns don't need to start with thinking blocks. This is more flexible than manual mode, where the API enforces that thinking-enabled turns begin with a thinking block.

Prompt caching

Consecutive requests using adaptive thinking preserve prompt cache breakpoints. However, switching between adaptive and enabled/disabled thinking modes breaks cache breakpoints for messages. System prompts and tool definitions remain cached regardless of mode changes.

Tuning thinking behavior

Adaptive thinking's triggering behavior is promptable. If Claude is thinking more or less often than you'd like, you can add guidance to your system prompt:

Extended thinking adds latency and should only be used when it
will meaningfully improve answer quality — typically for problems
that require multi-step reasoning. When in doubt, respond directly.

To encourage thinking instead, use a phrase like:

This task involves multi-step reasoning. Think carefully before responding.

Steering effectiveness can be sensitive to exact wording — if one phrasing doesn't produce the behavior you want, try a more direct variant.

You can also steer thinking on a per-message basis from the user turn. Appending "Please think hard before responding." to a user message encourages Claude to think on that turn; "Answer directly without deliberating." suppresses it. This works independently of the system prompt and is useful when only some requests in a conversation warrant extended reasoning.

Cost control

Use max_tokens as a hard limit on total output (thinking + response text). The effort parameter provides additional soft guidance on how much thinking Claude allocates. Together, these give you effective control over cost.

At high and max effort levels, Claude may think more extensively and can be more likely to exhaust the max_tokens budget. If you observe stop_reason: "max_tokens" in responses, consider increasing max_tokens to give the model more room, or lowering the effort level.

Working with thinking blocks

The following concepts apply to all models that support extended thinking, regardless of whether you use adaptive or manual mode.

Summarized thinking

With extended thinking enabled, the Messages API for Claude 4 models returns a summary of Claude's full thinking process. Summarized thinking provides the full intelligence benefits of extended thinking, while preventing misuse. This is the default behavior on Claude 4 models when the display field on the thinking configuration is unset or set to "summarized". On Claude Fable 5, Claude Mythos 5, Claude Opus 4.8, Claude Opus 4.7, and Claude Mythos Preview, display defaults to "omitted" instead, so you must set display: "summarized" explicitly to receive summarized thinking.

Here are some important considerations for summarized thinking:

• You're charged for the full thinking tokens generated by the original request, not the summary tokens.
• The billed output token count will not match the count of tokens you see in the response.
• On Claude 4 models, the first few lines of thinking output are more verbose, providing detailed reasoning that's particularly helpful for prompt engineering purposes. Claude Mythos Preview summarizes from the first token, so its thinking blocks do not show this verbose preamble.
• As Anthropic seeks to improve the extended thinking feature, summarization behavior is subject to change.
• Summarization preserves the key ideas of Claude's thinking process with minimal added latency, enabling a streamable user experience.
• Summarization is processed by a different model than the one you target in your requests. The thinking model does not see the summarized output.

Controlling thinking display

The display field on the thinking configuration controls how thinking content is returned in API responses. It accepts two values:

• "summarized": Thinking blocks contain summarized thinking text. See Summarized thinking for details. This is the default on Claude Opus 4.6, Claude Sonnet 4.6, and earlier Claude 4 models.
• "omitted": Thinking blocks are returned with an empty thinking field. The signature field still carries the encrypted full thinking for multi-turn continuity (see Thinking encryption). This is the default on Claude Fable 5, Claude Mythos 5, Claude Opus 4.8, Claude Opus 4.7, and Claude Mythos Preview.

Setting display: "omitted" is useful when your application doesn't surface thinking content to users. The primary benefit is faster time-to-first-text-token when streaming: The server skips streaming thinking tokens entirely and delivers only the signature, so the final text response begins streaming sooner.

Here are some important considerations for omitted thinking:

• You're still charged for the full thinking tokens. Omitting reduces latency, not cost.
• If you pass thinking blocks back in multi-turn conversations, pass them unchanged. The server decrypts the signature to reconstruct the original thinking for prompt construction (see Preserving thinking blocks). Any text you place in the thinking field of a round-tripped omitted block is ignored.
• display is invalid with thinking.type: "disabled" (there is nothing to display).
• When using thinking.type: "adaptive" and the model skips thinking for a simple request, no thinking block is produced regardless of display.

thinking = {
 "type": "adaptive",
 "display": "summarized",
}

For code examples and streaming behavior with display: "omitted", see Controlling thinking display on the extended thinking page. The examples there use type: "enabled"; with adaptive thinking, use:

thinking = {"type": "adaptive", "display": "omitted"}

Thinking encryption

Full thinking content is encrypted and returned in the signature field. This field is used to verify that thinking blocks were generated by Claude when passed back to the API.

Here are some important considerations on thinking encryption:

• When streaming responses, the signature is added via a signature_delta inside a content_block_delta event just before the content_block_stop event.
• signature values are significantly longer in Claude 4 models than in previous models.
• The signature field is an opaque field and should not be interpreted or parsed.
• signature values are compatible across platforms (Claude APIs, Amazon Bedrock, and Vertex AI). Values generated on one platform will be compatible with another.

Thinking output on Claude Fable 5 and Claude Mythos 5

On Claude Fable 5 and Claude Mythos 5, the raw chain of thought is never returned. The thinking blocks you receive are regular thinking blocks, not redacted_thinking. The thinking.display setting works the same as on other models:

• "summarized" returns a readable summary of the reasoning.
• "omitted" (the default on these models) still includes thinking blocks in responses, but their thinking field is an empty string.

For the response shape of thinking blocks, see the Messages API reference.

When continuing a conversation on the same model, pass each thinking block back to the API exactly as received, including blocks whose thinking field is empty. Don't edit or reconstruct them. Reading the summary text for display is fine: the API rejects blocks whose content has been modified, not blocks you have read.

When you switch models, for example after a classifier refusal fallback, strip thinking and redacted_thinking blocks from prior assistant turns. Thinking blocks are tied to the model that produced them. Other models silently ignore them rather than rejecting the request, but ignored blocks still add input tokens.

Two exceptions, covered in Fallback credit:

• Fallback-credit retries must echo the refused request body unchanged.
• fallback blocks from a mid-output fallback stay where they appeared.

To get visibility into the model's reasoning, read the thinking blocks described in this section rather than prompting for reasoning in the response text. On Claude Fable 5, a request that attempts to elicit the model's internal reasoning as part of the response text can be refused with stop_details.category: "reasoning_extraction". See Refusal categories for the field reference and handling guidance.

Pricing

For complete pricing information including base rates, cache writes, cache hits, and output tokens, see the pricing page.

The thinking process incurs charges for:

• Tokens used during thinking (output tokens)
• Thinking blocks from prior assistant turns kept in context: only the last turn on earlier Opus/Sonnet models and all Haiku models; all turns by default on Opus 4.5+ and Sonnet 4.6+ (input tokens)
• Standard text output tokens

When using summarized thinking:

• Input tokens: Tokens in your original request (excludes thinking tokens from previous turns)
• Output tokens (billed): The original thinking tokens that Claude generated internally
• Output tokens (visible): The summarized thinking tokens you see in the response
• No charge: Tokens used to generate the summary

When using display: "omitted":

• Input tokens: Tokens in your original request (same as summarized)
• Output tokens (billed): The original thinking tokens that Claude generated internally (same as summarized)
• Output tokens (visible): Zero thinking tokens (the thinking field is empty)

To see how many billed output tokens were spent on internal reasoning, read usage.output_tokens_details.thinking_tokens in the response. This value reflects the raw reasoning the model generated (not the summarized text returned in the body) and is always less than or equal to output_tokens. Subtract it from output_tokens to approximate the non-reasoning portion of the output.

{
 "usage": {
 "input_tokens": 25,
 "output_tokens": 348,
 "output_tokens_details": {
 "thinking_tokens": 312
 }
 }
}

output_tokens remains the inclusive, authoritative total used for billing. output_tokens_details is a read-only breakdown for observability.

Additional topics

The extended thinking page covers several topics in more detail with mode-specific code examples:

• Tool use with thinking: The same rules apply for adaptive thinking: preserve thinking blocks between tool calls and be aware of tool_choice limitations when thinking is active.
• Prompt caching: With adaptive thinking, consecutive requests using the same thinking mode preserve cache breakpoints. Switching between adaptive and enabled/disabled modes breaks cache breakpoints for messages (system prompts and tool definitions remain cached).
• Context windows: How thinking tokens interact with max_tokens and context window limits.

Next steps