思考

一個一次性作答的模型必須在第一次嘗試時就把所有事情做對：沒有草稿、沒有檢查、沒有中途改變方向。對於證明、棘手的錯誤或長時間的代理任務，第一個方法往往不是最好的。

思考消除了這個限制。當思考啟用時，Claude 會在回答之前用自己的話逐步解決問題：它會重述被問到的內容、嘗試各種方法、檢查中間結果，並放棄站不住腳的路徑。這些推理會以 thinking 內容區塊的形式出現在回應之前，Claude 會利用它們來產生最終答案。這就是為什麼思考能提升複雜任務的表現，例如數學、程式編寫、分析和長時間執行的代理工作，在這些任務中，答案的品質取決於中間工作，否則這些工作會被壓縮到回應本身中或被跳過。

思考是有成本的：Claude 用於推理的 token 會以 output tokens 計費，即使思考文字沒有回傳給您，而且它們與回應文字一起計入 max_tokens。本頁涵蓋思考在整個 API 介面上的行為：開啟思考、讀取其輸出，以及管理它與工具、串流、快取和上下文視窗的互動。



思考如何運作

Claude 是否會對特定請求進行思考，以及思考的深度，取決於您的思考配置和請求的複雜度。

以下是思考在回應中的樣子：一個或多個 thinking 內容區塊會出現在 text 區塊之前。thinking 區塊仍然是生成的內容，就像它後面的 text 區塊一樣，但它與正式回應是分開的。每個 thinking 區塊還帶有一個 signature 欄位，這是完整推理的加密副本，您在多輪對話和工具使用對話中需要原封不動地傳回（請參閱思考加密）：

{
  "content": [
    {
      "type": "thinking",
      "thinking": "Let me break this down. The question has two parts, so I'll start with the simpler one and use its result to constrain the second...",
      "signature": "WaUjzkypQ2mUEVM36O2Txu...."
    },
    {
      "type": "text",
      "text": "Based on my analysis..."
    }
  ]
}

您不一定總是能看到這些文字，而且您看到的永遠不是原始的思維鏈：thinking 區塊中的文字是 Claude 推理的摘要。思考配置上的 display 欄位控制是否回傳該摘要："summarized" 會回傳它，而 "omitted"（最新模型的預設值）會回傳 thinking 欄位為空的 thinking 區塊。無論哪種方式，該區塊的計費方式相同，在多輪對話中的傳回方式也相同；請參閱控制思考顯示以了解各模型的預設值和詳細資訊。

如果 Claude 使用工具，思考也可能出現在工具呼叫之間；請參閱思考與工具使用。有關完整的回應格式，請參閱 Messages API 參考文件。



配置思考

在目前的模型上，思考預設為開啟，或只需一個參數即可開啟。每個模型接受哪種配置以及其預設值，都列在疑難排解頁面的各模型配置表中。

在 Claude Opus 5、Claude Sonnet 5、Claude Fable 5、Claude Mythos 5 和 Claude Mythos Preview 上，思考已經開啟：無需配置。在這些模型上，大多數開發者首先需要的是看到思考文字，因為 display 在這些模型上預設為 "omitted"。使用 thinking: {"type": "adaptive", "display": "summarized"} 來選擇啟用，這正是以下請求，只需替換模型字串即可。

在 Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6 和 Claude Sonnet 4.6 上，思考是關閉的，直到您在請求中設定 thinking: {type: "adaptive"}。以下範例會這樣做，並設定 display: "summarized" 使思考文字可見，同時使用寬裕的 max_tokens：

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
)

for block in response.content:
    if block.type == "thinking":
        print(f"\nThinking: {block.thinking}")
    elif block.type == "text":
        print(f"\nResponse: {block.text}")

執行此範例會先印出摘要的思考內容，然後是答案：

Thinking: Use Euclidean algorithm.
1071 = 2*462 + 147
462 = 3*147 + 21
147 = 7*21 + 0
GCD = 21

Response: ## Finding GCD of 1071 and 462

I'll use the **Euclidean algorithm**, repeatedly dividing and taking remainders...

思考 token 會計入 max_tokens，因此請將其設定得足夠高，為思考和回應文字都留出空間。請參閱調整頁面上的成本控制以及思考與上下文視窗。



關閉思考

在 Claude Sonnet 5 上，思考預設為開啟，您可以將其關閉：

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    thinking={"type": "disabled"},
    messages=[{"role": "user", "content": "Summarize this article in one sentence."}],
)

Claude Opus 5 也預設開啟思考，並在 effort 為 high 或更低時接受 thinking: {type: "disabled"}。在 xhigh 或 max effort 下，思考無法關閉：將 thinking: {type: "disabled"} 與這些 effort 等級結合的請求會回傳 400 錯誤。此限制適用於 Claude Opus 5 及更新的模型，並在每個請求上強制執行。在停用思考的情況下，Claude Opus 5 偶爾可能會以純文字形式發出工具呼叫，或在其可見輸出中包含內部 XML 標籤；請參閱在停用思考的情況下執行以了解提示緩解措施。

Claude Fable 5、Claude Mythos 5 和 Claude Mythos Preview 會拒絕 thinking: {type: "disabled"}：這些模型無法關閉思考。

如果您的模型僅支援擴展思考（請參閱各模型配置表），請改用 type: "enabled" 和 budget_tokens 值來配置；擴展思考頁面涵蓋了該配置。如果任何思考配置回傳 400 錯誤，思考疑難排解會將每個錯誤訊息對應到其修正方法。



讀取思考輸出



控制思考顯示

思考配置上的 display 欄位控制思考內容在 API 回應中的回傳方式。display 在兩種模式下都有效：可與 type: "adaptive" 或 type: "enabled" 一起設定。它接受兩個值：

• "summarized"：thinking 區塊包含摘要思考文字，即 Claude 推理的可讀摘要。這是 Claude Opus 4.6、Claude Sonnet 4.6 及更早模型的預設值。
• "omitted"：thinking 區塊回傳時 thinking 欄位為空。signature 欄位仍然攜帶加密的完整思考內容，以維持多輪對話的連續性（請參閱思考加密）。這是 Claude Fable 5、Claude Mythos 5、Claude Opus 5、Claude Sonnet 5、Claude Opus 4.8、Claude Opus 4.7 和 Claude Mythos Preview 的預設值。

當您的應用程式不向使用者顯示思考內容時，請設定 display: "omitted"。主要好處是串流時更快的首個文字 token 時間：伺服器完全跳過串流思考 token，只傳送 signature，因此最終的文字回應會更早開始串流。

使用 display: "omitted" 時，回應包含 thinking 欄位為空的 thinking 區塊：

{
  "content": [
    {
      "type": "thinking",
      "thinking": "",
      "signature": "EosnCkYICxIMMb3LzNrMu..."
    },
    {
      "type": "text",
      "text": "The answer is 12,231."
    }
  ]
}

使用省略思考時，請記住以下幾點：

• 您仍然需要為完整的思考 token 付費。省略可以減少延遲，但不會降低成本。
• 如果您在多輪對話中傳回 thinking 區塊，請原封不動地傳回。伺服器會解密 signature 以重建原始思考內容用於提示建構（請參閱保留 thinking 區塊）。您放在往返的省略區塊的 thinking 欄位中的任何文字都會被忽略。
• display 與 thinking.type: "disabled" 一起使用是無效的（沒有可顯示的內容）。
• 使用 thinking.type: "adaptive" 且模型對簡單請求跳過思考時，無論 display 為何，都不會產生 thinking 區塊。
• 使用 display: "omitted" 進行串流時，不會發出 thinking_delta 事件；請參閱串流思考以了解事件順序。

在 Ruby SDK 中，請將此欄位設定為 display_:（帶有尾隨底線），以避免遮蔽 Ruby 的 Kernel#display；傳輸欄位仍然是 display。



摘要思考

當 display 為 "summarized" 時，您收到的思考文字是 Claude 完整思考過程的摘要，而不是原始的思維鏈。摘要思考提供思考的全部智慧優勢，同時防止濫用。沒有任何 display 設定會回傳原始的思維鏈。

使用摘要思考時，請記住以下幾點：

• 您需要為原始請求生成的完整思考 token 付費，而不是摘要 token。計費的 output token 數量與您在回應中看到的 token 數量不相符。
• 在 Claude Opus 4.6、Claude Sonnet 4.6 及更早的模型上，思考輸出的前幾行會更詳細，提供詳細的推理，這對提示工程特別有幫助。Claude Mythos Preview 從第一個 token 開始就進行摘要，因此其 thinking 區塊不會顯示這種詳細的開頭。
• 摘要保留了 Claude 思考過程的關鍵想法，且增加的延遲極小，可實現可串流的使用者體驗。
• 摘要由與您在請求中指定的模型不同的模型處理。思考模型不會看到摘要輸出。
• 隨著 Anthropic 尋求改進思考功能，摘要行為可能會發生變化。



串流思考

思考可與串流搭配使用。thinking 區塊以 content_block_delta 事件內的 thinking_delta 事件形式串流，接著在該區塊的 content_block_stop 之前有一個單一的 signature_delta 事件。text 區塊隨後照常串流。

以下範例使用自適應思考串流回應，在 thinking 和 text delta 到達時印出它們：

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
) as stream:
    for event in stream:
        if event.type == "content_block_start":
            print(f"\nStarting {event.content_block.type} block...")
        elif event.type == "content_block_delta":
            if event.delta.type == "thinking_delta":
                print(event.delta.thinking, end="", flush=True)
            elif event.delta.type == "text_delta":
                print(event.delta.text, end="", flush=True)

當設定 display: "omitted" 時，thinking 區塊開啟，一個單一的 signature_delta 到達，然後該區塊關閉，沒有任何 thinking_delta 事件。文字串流隨即開始：

event: content_block_start
data: {"type":"content_block_start","index":0,"content_block":{"type":"thinking","thinking":"","signature":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":0,"delta":{"type":"signature_delta","signature":"EosnCkYICxIMMb3LzNrMu..."}}

event: content_block_stop
data: {"type":"content_block_stop","index":0}

event: content_block_start
data: {"type":"content_block_start","index":1,"content_block":{"type":"text","text":""}}

有關一般串流機制，請參閱串流訊息。



思考與 effort

thinking 參數控制 Claude 是否在回答前於思考區塊中進行思考；effort 參數控制 Claude 在整個回應中投入多少工作量，在 adaptive 模式下，這包括思考的頻率和深度。請勿將 adaptive 作為 effort 的值傳入：adaptive 是一種思考模式，而不是一個工作量等級。

有關每個 effort 等級對思考行為的影響，請參閱調整思考頁面上的各等級思考行為表；Effort 頁面記錄了該參數本身，包括每個模型支援哪些等級。在 Claude Opus 4.5（唯一支援 effort 的僅限擴展思考模型）上，effort 與 budget_tokens 組合使用；請參閱預算規則與調整。

透過這種方式將兩個控制項分開，請選擇符合您目標的那一個：

• **降低啟用思考的工作負載的成本或延遲：**先降低 effort。它會縮減整個回應，包括思考。
• **Claude 思考得太少或太淺：**提高 effort，或參閱調整頁面上的調整 Claude 思考的頻率。
• **您需要完全關閉思考：**在允許的模型上使用 thinking: {type: "disabled"}（請參閱各模型配置表）。
• **您需要嚴格的支出上限：**使用 max_tokens。Effort 是軟性指引；max_tokens 是嚴格的限制。



思考與工具使用

思考可與工具使用搭配運作，讓 Claude 能夠推理工具選擇並處理工具結果。有兩個限制：

1. 工具選擇限制（手動模式）：使用手動擴展思考（thinking: {type: "enabled"}）的工具使用僅支援 tool_choice: {"type": "auto"}（預設值）或 tool_choice: {"type": "none"}。使用 tool_choice: {"type": "any"} 或 tool_choice: {"type": "tool", "name": "..."} 會導致錯誤，因為這些選項會強制使用工具，這與手動擴展思考不相容。自適應思考（包括在預設開啟思考的模型上）支援強制工具使用。
2. 保留 thinking 區塊：當您回傳工具結果時，必須將 assistant 訊息中的 thinking 區塊完整且未經修改地傳回 API。請參閱保留 thinking 區塊。

**一個工具使用迴圈是一個 assistant 輪次。**從模型的角度來看，assistant 輪次在 Claude 完成其完整回應之前不會結束，這可能包括多個工具呼叫和結果。整個序列是一個單一的 assistant 輪次：

User: "What's the weather in Paris?"
Assistant: [thinking] + [tool_use: get_weather]
User: [tool_result: "20°C, sunny"]
Assistant: [text: "The weather in Paris is 20°C and sunny"]

整個輪次在單一思考模式下執行：您無法在輪次中途切換思考，包括在工具使用迴圈期間。在擴展（手動）模式下，API 還會強制要求啟用思考的請求的最後一個 assistant 輪次以 thinking 區塊開頭。自適應模式放寬了這一點：沒有任何 assistant 輪次需要以 thinking 區塊開頭。

**輪次中途的衝突會優雅地降級。**如果您在輪次中途切換思考（例如，在發送工具呼叫和回傳其結果之間），API 不會報錯。相反，它會靜默地為該請求停用思考。為了保持模型品質，API 可能會移除會造成無效輪次結構的 thinking 區塊，或在對話歷史與啟用思考不相容時停用思考。要確認思考是否處於啟用狀態，請檢查回應中是否存在 thinking 區塊。

**在輪次之間切換，而不是在輪次內切換。**在每個輪次開始時規劃您的思考策略。完成 assistant 輪次，然後為下一個輪次變更思考配置：

User: "What's the weather?"
Assistant: [tool_use] (thinking disabled)
User: [tool_result]
Assistant: [text: "It's sunny"]
User: "What about tomorrow?"
Assistant: [thinking] + [text: "..."] (thinking enabled - new turn)

請注意，切換思考模式也會使提示快取失效；請參閱思考與提示快取。



保留 thinking 區塊

當 Claude 呼叫工具時，它會暫停建構其回應以等待外部資訊。當您回傳工具結果時，Claude 會繼續建構同一個回應，因此其先前的推理必須仍然存在。請將每個 thinking 區塊完整且未經修改地傳回 API，連同它所伴隨的 tool_use 區塊。這很重要，原因有二：

1. 推理連續性：thinking 區塊捕捉了導致工具請求的逐步推理。包含它們可讓 Claude 從中斷的地方繼續推理。
2. 上下文維護：工具結果在 API 結構中以 user 訊息的形式出現，但它們是一個連續推理流程的一部分。保留 thinking 區塊可在 API 呼叫之間維持該流程。

簡而言之：

• **必要：**在工具使用輪次內，傳回 thinking 區塊。
• **建議：**跨輪次，傳回所有內容。
• **允許：**在工具使用之外，省略先前輪次的思考。

您不需要自己修剪舊的思考內容。在多輪對話中傳回所有 thinking 區塊，API 會自動過濾它們，保留維持模型推理所需的區塊，並僅對實際顯示給 Claude 的區塊計費 input tokens。保留哪些先前輪次的區塊因模型而異；請參閱各模型的 thinking 區塊保留。要覆寫預設值，請使用 clear_thinking_20251015 上下文編輯策略。

在最新的 assistant 訊息中，連續 thinking 區塊的順序必須與模型在原始請求中生成的內容相符：您不能重新排列、編輯或部分刪除它們。這包括 redacted_thinking 區塊。

有關包含每個 SDK 程式碼的完整兩輪演練，請參閱工具和多輪工作流程中的思考。它定義了一個工具，接收思考加工具使用的回應，並將 assistant 輪次與工具結果一起回傳。



交錯思考

交錯思考讓 Claude 能夠在工具呼叫之間進行思考，在對每個工具結果採取行動之前先對其進行推理。透過交錯思考，Claude 可以：

• 在決定下一步做什麼之前，對工具呼叫的結果進行推理
• 將多個工具呼叫與中間的推理步驟串連起來
• 根據中間結果做出更細緻的決策

使用自適應思考時，交錯思考在每個支援自適應思考的模型上都是自動的；不需要 beta 標頭。在 Claude Fable 5、Claude Mythos 5、Claude Mythos Preview、Claude Opus 5、Claude Opus 4.8 和 Claude Opus 4.7 上，工具呼叫之間的推理總是出現在 thinking 區塊中。Claude Haiku 4.5 不支援交錯思考。在使用手動擴展思考的模型上，交錯需要 beta 標頭，並且會改變思考預算的計算方式；手動模式下的交錯思考涵蓋了各模型的規則和平台特定的標頭行為。

使用交錯思考時，思考配額可以跨越整個 assistant 輪次，而不是單一回應。交錯思考僅支援透過 Messages API 使用的工具。

有關展示交錯思考在雙工具工作流程中改變了什麼的實際比較，請參閱交錯思考如何改變流程。



各模型的 thinking 區塊保留

先前 assistant 輪次的 thinking 區塊是否預設保留在上下文中，取決於模型：

• **保留所有先前輪次：**Claude Opus 4.5 及更新的 Opus 模型、Claude Sonnet 4.6 及更新的 Sonnet 模型、Claude Fable 5、Claude Mythos 5 和 Claude Mythos Preview。
• **僅保留最後一個輪次：**較早的 Opus 和 Sonnet 模型，以及到 Claude Haiku 4.5 為止的所有 Haiku 模型。當您傳回較舊的 thinking 區塊時，API 會自動移除它們；您不需要自己移除。

保留帶來兩個好處：

• 快取最佳化：保留的 thinking 區塊可在工具使用期間實現快取命中，因為它們會與工具結果一起傳回，並在整個 assistant 輪次中逐步快取，從而在多步驟工作流程中節省 token。
• 不影響智慧：保留 thinking 區塊對模型效能沒有負面影響。

代價是上下文使用量：在保留所有輪次的模型上，長對話會消耗更多上下文空間，因為保留的 thinking 區塊與任何其他對話歷史一樣計為輸入（請參閱思考與上下文視窗）。這兩種機制下的行為都是自動的；不需要程式碼變更或 beta 標頭，您應該繼續按照保留 thinking 區塊中的描述傳回完整、未經修改的 thinking 區塊。要在任一方向覆寫預設值，請使用 thinking 區塊清除。

**在對話中途切換模型。**當您在任意兩個模型之間切換時，例如在分類器拒絕後備之後，請從先前的 assistant 輪次中移除 thinking 和 redacted_thinking 區塊。thinking 區塊與產生它們的模型綁定。其他模型會靜默地忽略它們而不是拒絕請求，但被忽略的區塊仍然會增加 input tokens。



思考與提示快取

提示快取與思考以幾種特定方式互動。以下規則適用於兩種思考模式。

**配置變更會使快取失效。**思考配置和解析後的 effort 等級會被渲染到提示本身中，因此變更其中任何一項都會開始一個新的快取前綴。在 adaptive、enabled 和 disabled 之間切換、變更 budget_tokens 以及變更 effort 值都會使快取斷點失效：訊息層級的斷點總是會未命中，而工具和系統提示斷點也可能未命中，取決於模型在何處渲染配置。請將任何思考或 effort 變更視為重新開始快取。保持相同配置的連續請求會保留快取，而將參數明確設定為其預設值等同於省略它。調整思考頁面上有一個帶有使用量輸出的實際示範。

**thinking 區塊會與工具結果一起快取。**在工具使用迴圈期間，當您發出包含工具結果的後續請求時，就會發生快取。此時，先前的對話歷史（包括其 thinking 區塊）可以被快取，而這些快取的 thinking 區塊在從快取讀取時會在您的使用量指標中計為 input tokens。這是自動發生的，即使沒有明確的 cache_control 標記，並且對於一般思考和交錯思考的行為相同。代價是：您在回應中再也看不到的 thinking 區塊，在從快取讀取時仍然會計入 input token 使用量。

先前的區塊是否在上下文中完全取決於模型。保留預設值決定了這一點。在保留所有輪次的模型上，先前輪次的 thinking 區塊會保留在快取和上下文中。在僅保留最後一個輪次的模型上，一旦您發送的 user 訊息不是工具結果，所有先前的 thinking 區塊都會從上下文中移除。在這些模型上，像這樣的對話：

User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]

會被當作 thinking 區塊從未存在過一樣處理：

User: ["What's the weather in Paris?"],
Assistant: [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [text block 2],
User: [Text response, cache=True]

在保留所有輪次的模型上，相同的請求會將 thinking_block_1 和 thinking_block_2 保留在上下文和快取中。

**降級會從可快取的歷史中移除思考。**如果思考在輪次中途被停用，而您在目前的工具使用輪次中傳遞了思考內容，則思考內容會被移除，且該請求的思考保持停用狀態（請參閱優雅降級）。交錯思考會放大快取失效的影響，因為 thinking 區塊可能出現在多個工具呼叫之間。



思考與上下文視窗

max_tokens（包括 Claude 在目前輪次中生成的所有思考）被強制執行為嚴格的限制。在 Claude 4.5 及更新的模型上，如果 input tokens 加上 max_tokens 超過上下文視窗大小，API 會接受該請求；如果生成隨後達到上下文視窗限制，它會以 stop_reason: "model_context_window_exceeded" 停止，而不是回傳錯誤。在較早的模型上，API 會改為回傳驗證錯誤。請參閱處理停止原因。

思考如何計入視窗取決於它是何時生成的：

• 目前輪次的思考總是計入 max_tokens，以 output tokens 計費，並在生成它的輪次中佔用上下文視窗空間。
• 先前輪次的思考取決於保留預設值。在保留所有先前輪次的模型上，先前的 thinking 區塊會保留在上下文中，計入視窗，並像對話歷史的其餘部分一樣以 input tokens 計費。在僅保留最後一個輪次的模型上，當您傳回較舊的 thinking 區塊時，API 會自動移除它們，因此它們不會消耗視窗空間或 input tokens。

實務上：

• 在保留所有輪次的模型上，請將思考視為一般對話歷史來規劃您的上下文視窗，因為它確實如此。長時間的代理工作階段會在上下文中累積思考；如果您需要回收空間，請使用 thinking 區塊清除。
• 在僅保留最後一個輪次的模型上，思考只是每輪次的成本：每個輪次的思考計入該輪次的 max_tokens，然後從視窗中移除。

以下圖表說明了僅保留最後一個輪次（移除）的機制。第一個圖表顯示了多輪對話：每個輪次的 thinking 區塊在輸出中生成，但不會帶入後續輪次的輸入。

第二個圖表顯示了相同機制下的工具使用：思考在 assistant 輪次期間與其工具結果一起保留在上下文中，然後在下一個 user 輪次時移除。

使用 token 計數 API 來取得您特定使用案例的準確計數，尤其是包含思考的多輪對話。



思考加密

完整的思考內容會被加密並在每個 thinking 區塊的 signature 欄位中回傳。當您傳回 thinking 區塊時，API 會使用 signature 來驗證它們是由 Claude 生成的。

使用 signature 時，請記住以下幾點：

• 只有在將工具與思考搭配使用時，才嚴格需要傳回 thinking 區塊。否則，您可以省略先前輪次的 thinking 區塊。如果您確實傳回它們，API 是保留還是移除它們取決於模型（請參閱各模型的 thinking 區塊保留）；使用上下文編輯來配置此行為。
• 傳回 thinking 區塊時，請完全按照您收到的內容傳回所有內容，以保持一致性並避免潛在問題。
• 串流回應時，signature 會在 content_block_stop 事件之前，以 content_block_delta 事件內的 signature_delta 形式到達。
• signature 值在 Claude 4 及更新的模型中比先前的模型長得多。
• signature 欄位是不透明的：請勿解讀或解析它。
• signature 值在各平台之間相容（Claude API、Amazon Bedrock 和 Google Cloud）。在一個平台上生成的值可以在另一個平台上使用。



編修的 thinking 區塊

除了一般的 thinking 區塊外，當 Claude 的部分推理因安全原因被編修時，API 可能會回傳 redacted_thinking 區塊。redacted_thinking 區塊在 data 欄位中包含加密的思考內容，沒有可讀的文字：

{
  "type": "redacted_thinking",
  "data": "..."
}

data 欄位是不透明且加密的。與一般 thinking 區塊上的 signature 欄位一樣，在使用工具繼續多輪對話時，請將 redacted_thinking 區塊原封不動地傳回 API。



Claude Fable 5 和 Claude Mythos 5 上的思考輸出

在 Claude Fable 5 和 Claude Mythos 5 上，永遠不會回傳原始的思維鏈；您收到的區塊是一般的 thinking 區塊，而不是 redacted_thinking，並且 display 設定的運作方式與其他模型相同（摘要文字，或在省略時為空的 thinking 欄位，這是此處的預設值）。有關 thinking 區塊的回應格式，請參閱 Messages API 參考文件。

在同一模型上繼續對話時，請完全按照收到的內容將每個 thinking 區塊傳回 API，包括 thinking 欄位為空的區塊。請勿編輯或重建它們。讀取摘要文字以供顯示是可以的：API 拒絕的是回傳內容已被修改的區塊，而不是您已讀取的區塊。放在空的省略 thinking 欄位中的文字會被忽略而不是被拒絕。

有關在對話中途切換模型時 thinking 區塊會發生什麼，請參閱各模型的 thinking 區塊保留。

有兩個例外，在後備額度中有說明：

• 後備額度重試必須原封不動地回傳被拒絕的請求主體。
• 來自輸出中途後備的 fallback 區塊保留在它們出現的位置。

要了解模型的推理，請閱讀本頁描述的 thinking 區塊，而不是在回應文字中提示要求推理。在 Claude Fable 5 上，試圖將模型的內部推理作為回應文字的一部分引出的請求可能會被拒絕，並帶有 stop_details.category: "reasoning_extraction"。請參閱拒絕類別以了解欄位參考和處理指引。



限制與功能相容性

取樣參數。 在 Claude Fable 5、Claude Mythos 5、Claude Mythos Preview、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7 和 Claude Sonnet 5 上，非預設的 temperature、top_p 或 top_k 值會在每個請求上回傳 400 錯誤，無論是否使用思考功能。在較舊的模型上，此限制僅在思考功能開啟時適用：temperature 和 top_k 與思考功能不相容，而 top_p 允許使用 0.95 到 1 之間的值。

回應預填與強制工具使用。 當思考功能開啟時，您無法預填助手回應。強制工具使用（tool_choice: {"type": "any"} 或 {"type": "tool", ...}）與手動擴展思考不相容，但可與自適應思考搭配使用；請參閱思考與工具使用。

輸出限制。 Claude Fable 5、Claude Mythos 5、Claude Mythos Preview、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Sonnet 5、Claude Opus 4.6 和 Claude Sonnet 4.6 每個請求最多支援 128k 輸出 token。Claude Haiku 4.5、Claude Sonnet 4.5 和 Claude Opus 4.5 最多支援 64k。在 Message Batches API 上，output-300k-2026-03-24 beta 標頭可將 Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Sonnet 5、Claude Opus 4.6 和 Claude Sonnet 4.6 的限制提高到 300k。請參閱模型概覽以了解舊版模型的限制。

長時間請求。 當 max_tokens 大於 21,333 時，SDK 要求使用串流（streaming），以避免長時間執行的請求發生 HTTP 逾時。這是客戶端驗證，而非 API 限制。如果您不需要逐步處理事件，請使用 .stream() 搭配 .get_final_message()（Python）或 .finalMessage()（TypeScript）來取得完整的 Message 物件，而無需處理個別事件；請參閱串流訊息。當思考功能啟用時，預期回應時間會更長，因為生成思考區塊會增加處理時間。對於每個請求的思考量超過約 32k token 的工作負載，請使用批次處理以避免網路問題：此類請求可能執行時間過長，以致觸發系統逾時和開放連線限制。



後續步驟