Claude Opus 5.5 API 指南：模型 ID、四項破壞性變更，以及沉默的第五項

將模型字串從 claude-opus-5 改成 claude-opus-5-5，你的程式碼依然能編譯、依然能通過型別檢查，也依然能通過任何勉強稱得上是測試套件的東西。然後它在正式環境裡回傳 400。Claude Opus 5 原本接受的五種請求形態中，有四種會被 Claude Opus 5.5直接拒絕，而第五項變更完全不會弄壞任何東西——這正是它注定會成為那個送到你使用者手上的變更的原因。這是該模型的整合參考文件：識別碼、提供該模型的各種介面、請求合約、那四個錯誤、沉默的第五項，以及 effort 參數現在的運作方式。若行為與 Claude Fable 5.1相符，表示已經遷移到該模型的團隊已經完成了一部分工作，因此以下每一項變更都會說明它是否同樣適用於該模型。

此處所有內容均取自 Anthropic 自家的 Claude 文件，擷取日期為 2026-09-24，也就是該模型推出兩天後。廠商說法一律標示為廠商說法，獨立數據則標示為獨立數據，兩者絕不會在相同的 effort 設定下並列呈現，彷彿彼此可以相提並論。

模型 ID，以及其服務位置

這個識別碼是 claude-opus-5-5——一個不含日期尾綴的固定模型 ID，與 claude-opus-5 採用相同的命名方式。沒有另外的固定快照形式可供採用，也沒有任何會解析成其他內容的別名。

Anthropic 的模型概覽列出五個介面，並包含以下確切字串：

• Claude API — claude-opus-5-5，所有客戶皆可使用。

• Amazon Bedrock — anthropic.claude-opus-5-5（唯一會在名稱前加上供應商的介面）。

• AWS 上的 Claude 平台 — claude-opus-5-5，使用 Claude API 的 ID，而非 Bedrock 風格的 ID。

• Google Cloud — claude-opus-5-5。

• Microsoft Foundry — claude-opus-5-5；你傳送的是部署名稱，而 Foundry 會遵循 Claude API 的生命週期時程。

那五個之中，有兩個比本節其餘內容更為重要。Amazon Bedrock 與 Google Cloud 各自訂定自己的生命週期與退役日期，而且——正如下方的重大變更所示——Bedrock 也是唯一一個舊版 computer-use 工具仍可運作的平台。如果你用的是 Bedrock，你的遷移之路就和別人不一樣。

現在每個請求都必須滿足的條件

Anthropic 的遷移指南以清單形式陳述這份契約，而這份清單短到足以讓你拿自己的用戶端逐項核對。無論你原本使用的是哪個模型，對 claude-opus-5-5 提出的請求都必須：

• 可以不傳送thinking 欄位，或傳送 thinking: {"type": "adaptive"}——兩者效果相同，因為 adaptive thinking 一律啟用。

• 使用 effort 控制思考深度，它是唯一能做到這一點的請求參數；五個等級皆支援，預設為 medium。

• 使用 tool_choice，設為 {"type": "auto"}（預設值）或 {"type": "none"}。強制指定工具會被拒絕。

• 省略 temperature、top_p 和 top_k，或將它們保留為預設值。任何其他值都會被拒絕；在此模型上如此，從 Claude Opus 4.7 起的所有模型亦然。

• 不要以預填的助理回合來結束訊息；這在 Opus 4.6 及後續版本中已被否決。

• 將電腦操作宣告為computer_toolset_20260801 工具組，於 Claude API 與 Google Cloud 上。

• 不要傳送上下文視窗 beta 標頭。1M 上下文視窗是預設值，而為較舊模型撰寫的標頭不會有任何作用。

凡是指南指出某項設定會被拒絕之處，API 就會回傳 HTTP 400。這就是改用這個模型的全部失敗模式：不是輸出品質變差，也不是日誌裡出現警告——而是一個根本不會執行的請求。

四項重大變更

1. 無法停用思考

自適應思考永遠開啟。 thinking: {"type": "disabled"}會傳回 400，手動設定預算也一樣—— thinking: {"type": "enabled", "budget_tokens": N}。錯誤文字會指出你傳送的類型，然後指出替代類型：

• 此模型不支援「thinking.type.disabled」。請使用「thinking.type.adaptive」和「output_config.effort」來控制思考行為。

• "thinking.type.enabled" 不支援此模型。請使用 "thinking.type.adaptive" 和 "output_config.effort" 來控制思考行為。

實際的後果不是那個錯誤本身，而是你修正它之後會發生什麼事。在 Claude Opus 4.8 及更早版本上，沒有 thinking 欄位的要求會在沒有思考的情況下執行。在 Claude Opus 5.5 上，每個要求都會思考，而 max_tokens 仍然是涵蓋思考加上回應文字的硬性上限。即使思考文字從未回傳給你，思考詞元仍會以輸出詞元計費。因此，一個原本以無思考模式運作的端點，在「修正」之後，每次要求可能產生比之前更多的輸出詞元。Anthropic 的建議是：在你過去停用思考的地方調低 effort，並且——在 xhigh 或 max effort 之下——從 64k 開始設定 max_tokens，再從那裡調整。

回應的形狀也改變了。回應在第一个文字區塊之前，可能以一個或多個思考區塊開頭，因此依照位置讀取回覆的程式碼——content[0].text，或是把第一个 content_block_start 當成文字的串流處理器——即使請求成功，也會在這些回應上出錯。請改以 type 欄位來選取區塊。

2. 強制使用工具會傳回錯誤

tool_choice 類型 any與 tool會傳回 400，而相同的驗證也適用於權杖計數端點，因此預檢計數會以與實際呼叫相同的方式失敗：

• tool_choice：此模型不支援「tool」與「any」類型。

Auto 與 none 不受影響。文件中記載的替代做法是保留 tool_choice: {"type": "auto"}，將工具標記為 strict: true 以取得符合結構描述的引數，或將結構描述移至結構化輸出——並在提示中說明工具何時適用，因為 auto 不保證會呼叫。嚴格工具使用只接受 JSON Schema 的子集：工具 input_schema 中的每個 object 都必須設定 additionalProperties: false，因此切換旗標前，請檢查每個結構描述。另請注意這留下的缺口：如果你的程式碼依賴的是 強制呼叫，而不只是允許呼叫，auto 恢復的是權限，而非保證。請確認確實有回傳 tool_use 區塊。

3. 思考區塊會繫結至模型與對話

每個思考區塊都會記錄是哪個模型產生的，而每個模型會讀取自己的區塊，以及一組定義好的其他模型區塊。這些規則會雙向運作：

• Claude Opus 5.5 會讀取 Claude Opus 5 以及較早的 Opus、Sonnet 和 Haiku 模型的思考區塊——但不會讀取 Claude Fable 或 Claude Mythos 模型的思考區塊。

• 在 Claude API 上，Claude Fable 5.1 與 Claude Mythos 5.1 會讀取 Claude Opus 5.5 的區塊。其他模型則不會。

• 當對話從 Claude Opus 5.5 轉移到那兩者以外的任何對象時，其後續回合會在沒有先前推理的情況下執行。

使用路由器或備援機制來移動對話，是觸發此情況的明顯方式。更細微的部分在於，該區塊也繫結至對話前綴——系統提示、工具，以及其之前的每一則訊息。Anthropic 在 Claude API 與雲端平台上，預設會為 2026-08-31 00:00 UTC 當天或之後建立的帳戶強制執行前綴檢查：在編輯系統提示、工具清單或較早的訊息後重播區塊，請求會傳回 400。有兩種變通方式。傳送 thinking-binding-controls-2026-08-01 beta 標頭，並將 thinking.block_binding.prefix_mismatch_behavior 設為 "drop_block"，以捨棄受影響的區塊，而不是讓請求失敗。或者讓對話保持僅附加，並改用對話中段的系統訊息來變更指示，而非編輯——這正是 Claude Code、claude.ai、Claude Managed Agents 與 Claude Agent SDK 已經在做的事。

有一個好消息很容易被忽略：當請求帶有目標模型無法讀取的區塊時，API 會在模型看到之前就將其捨棄。請求仍會成功，而且被捨棄的區塊不會計費。

4. 較舊的電腦使用工具在 Claude API 和 Google Cloud 上遭到拒絕

型別為computer_20251124的 tools 項目在 Claude API 與 Google Cloud 上會傳回 400。訊息會指出遭拒絕的型別，然後列出模型確實接受的型別：

• 'claude-opus-5-5' 不支援工具類型：computer_20251124。

取代方案是computer_toolset_20260801 工具集：移除 computer-use-2025-11-24 beta 標頭，並以不帶名稱、不帶顯示尺寸的方式送出 tools 項目。這不僅是請求內容的變更——代理迴圈也會隨之改變。動作會以成員 tool_use 區塊的形式抵達，而非單一的 computer 工具；一回合中可能出現多個；動作是該區塊的 name，而非 input.action；而且每一筆結果都必須回傳 toolset_name。在 Amazon Bedrock 上，computer_20251124 的運作方式與在 Claude Opus 5 上完全相同，不需要任何變更。

這四個之中，哪些也適用於 Claude Fable 5.1？

Anthropic 表示，前三項變更同樣適用於 Claude Fable 5.1——永遠開啟的思考、不得強制選擇工具，以及綁定模型與對話的思考區塊。電腦使用（computer use）方面的變更則不然：那一項是此模型在 Claude API 與 Google Cloud 上專屬的。因此，已經改用 Claude Fable 5.1 的團隊，已汰除了停用思考的程式碼路徑與強制工具選擇，並採用僅能追加的對話模式；剩下的是模型 ID 與電腦使用工具組。至於從Claude Opus 5遷移過來的團隊，則會同時面對全部四項。那才是值得安排時程的遷移，而且視你的起點不同，工作量也不一樣。

第五項變更：不再出現任何錯誤，你的進度動態也沉寂了下來

在 Claude Opus 5 上，模型在工具呼叫之間寫下的簡短註記會以一般文字區塊的形式回傳。在 Claude Opus 5.5 上——如同在 Claude Fable 5.1 上——那段敘述會以進度更新思考區塊的形式回傳，每次工具呼叫前最多一個。而 thinking.display預設為"omitted"，因此那些區塊送達時，除了本身的簽章之外，其 thinking 欄位是空的。

沒有任何請求失敗。沒有記錄任何錯誤。一個會把工具之間的文字串流給使用者當作進度指示的應用程式，就只是不再顯示工具呼叫之間的進度，並開始什麼都不顯示。看得見的徵狀是在使用者最需要安心的那一段工作期間，UI 看起來像凍結了一樣，而這會被回報成效能問題、網路問題或卡住——而不是遷移錯誤。這就是會上到正式環境的那項變更。

修正方法是一個顯示設定，再加上與之相符的讀取：

• 將 thinking.display 設為 "updates" — 測試版，位於 thinking-display-updates-2026-08-18 標頭之後 — 即可恢復進度更新，同時推理內容本身仍保持隱藏。這正是進度摘要所需的設定。

• 或將其設為「summarized」，即可在同一區塊中同時接收進度更新與推理摘要。

• 然後從思考區塊而非文字區塊讀取文字，將每個非空的思考區塊渲染在其所前置的 tool_use 區塊之前，並將這些區塊原樣不變地與助理回合的其餘部分一併傳回。

Anthropic 自己對此的說明，值得在精神上引用：一個會在工具呼叫之間轉譯文字的介面，應該設定顯示值，而不是依賴預設值。如果你的整合目前完全忽略思考區塊，那是唯一可以安全使用預設值的地方。

Effort 就是 API 的介面

在思考功能無法停用的情況下，output_config.effort成為唯一能調控模型推理程度的旋鈕，也因此是特定任務下唯一能調控成本與延遲的旋鈕。在你從舊模型直接複製設定過來之前，有四件事值得先了解。

預設值變了。Claude Opus 5.5 預設為中等 effort，而 Claude Opus 5 及更早的 Opus 模型則預設為高。現在若請求省略 effort，執行時的層級會比切換前低一級。Anthropic 也說明，在給定的 effort 設定下，這個模型每回合傾向思考更多，在 xhigh 與 max 時尤其明顯。這兩種效應方向相反，這正是為什麼供應商指示要在你自己的評估上重新跑一輪 effort 掃描，而不是直接把設定套用過去。

這個尺度分為low / medium / high / xhigh / max，這五個等級在這裡全都支援。那個具名等級本身從一開始就不是固定的詞元預算——Anthropic 將 effort 描述為一種行為訊號，而非嚴格的預算——而且每個等級背後的詞元分配在不同模型之間有所變動，因此 Claude Opus 5.5 上的「high」並不等於 Claude Opus 5 上的「high」。把 effort 設為模型的預設值，等同於完全不設定它。

有兩個操作細節，因為兩者一旦被忽略都會造成金錢損失。首先，在請求之間更改頂層 effort 值會使提示快取失效：在依賴快取命中的對話中，選定一個層級並維持固定，改為在不同工作負載之間調整。其次，此模型支援逐訊息 effort（beta 標頭 mid-conversation-output-config-2026-07-01），可在不重新啟動快取的情況下，於後續回合更改層級。此处的提示快取下限為 512 個 token，低於上一代的 1,024，因此先前因太短而無法快取的提示，現在無需修改程式碼即可建立項目。

輸出上限：同步 128K，Batch 為 300K

同步 Messages API 的輸出上限為 128K 個 token。Message Batches API 則可達 300K 個輸出 token，但須在 output-300k-2026-03-24 beta 標頭之後——也就是這個確切字串。輸入預設為完整的 1M-token 上下文視窗，且不需要任何標頭。

實務上的解讀是：128K 上限與 Claude Opus 5 相比並未改變，因此單就這個軸線而言，同步整合並沒有任何需要重新編列預算之處。真正需要重新編列預算的，是其中的 thinking。由於現在每個請求的 max_tokens 都涵蓋 thinking 加上文字，某個在 Claude Opus 5 上對回應文字而言還算剛好的值，在這裡會更吃緊——而且在 xhigh 或 max effort 下，廠商建議從 64k 開始並逐步調校。如果某個長時間執行的作業原本是依據 128K 同步上限來規劃規模，現在卻遭到截斷，那麼變動的並不是那個上限。

Safeguard 路由是規格的一部分。

這是整合上的事實，而非政策附註：在某些提示詞上，你送出的模型字串並不能描述實際回答的是什麼。

Claude Opus 5.5 內建安全分類器，被拒絕的請求會以 HTTP 200 回傳，並附帶stop_reason: "refusal"以及一個stop_details物件，指出所屬的政策領域。此模型涵蓋的類別比 Claude Opus 5 更多——預期會出現bio、frontier_llm和reasoning_extraction，以及熟悉的cyber。reasoning_extraction的拒絕會直接遭到封鎖，而不會重試：Anthropic 的伺服器端備援機制不會重試它，該拒絕會直接回傳給你。

對於確實會重試的類別，其機制是一個參數。將fallbacks 設為 "default"，並搭配 server-side-fallback-2026-07-01 beta 標頭後，API 便會在單一次呼叫中，以 Anthropic 針對該類別建議的模型重新執行被拒絕的請求，並回傳單一回應。Anthropic 的說明中心直接列出了這個模型的路由方式：被標記的網路安全請求會退回至 Claude Opus 4.8，而其生物學分類器——也就是 Fable-5 風格的那一組——則會使雙用途生命科學工作退回至 Claude Opus 5。另外有一小部分前沿 LLM 開發能力也會路由至 Claude Opus 5。Anthropic 亦指出，這些檢查會審查模型所讀取的一切內容，而不只是你最近的那則訊息，因此記憶、連接器內容、搜尋結果和檔案都可能觸發切換。

對你的整合來說，有三件事隨之而來。請在每個回應上讀取頂層的 model 欄位，因為它會回報實際產生該訊息的模型，而 fallback 內容區塊則標示出每一個交接點。請驗證備援機制本身的速率限制，因為受到速率限制的備援不會被嘗試，而是直接回傳拒絕——備援在高負載下會退化為拒絕。此外，任何在啟用防護措施下發布的基準測試結果，都應視為對整體路由系統的測量，而非僅是 Claude Opus 5.5 本身；這正是 Anthropic 對其下方自家數據所做的說明。

伺服器端備援機制目前為 beta 版，且僅限 Claude API 使用：Message Batches API 不支援此功能，Amazon Bedrock、Google Cloud 或 Microsoft Foundry 上亦無法使用；在這些平台上，SDK 中介軟體才是官方文件記載的做法。在驗證方面，兩類計畫皆设有存取途徑——網路驗證計畫（Cyber Verification Program）與生命科學驗證計畫（Life Sciences Verification Program）——但請留意，截至本文撰寫時，Anthropic 說明中心所記載的不對稱情況：Claude Opus 5.5 目前未列於網路驗證計畫中，而生命科學驗證計畫則被描述為讓已驗證的組織得以使用最強大的模型。

上下文、截止、退役和 Fast 模式

信封的其餘部分，來自模型頁面和棄用表格：

• 上下文視窗 — 1M tokens，預設，無 beta 標頭。

• 知識截止 — 2026 年 6 月，這同時也是訓練資料的截止時間。

• 退役 — 在 Anthropic 營運的平台上，不會早於 2027-09-22，且會提前至少 60 天通知。Amazon Bedrock 與 Google Cloud 各自訂定其日期。Claude Opus 5 至少在 2027-07-24 之前皆為 Active 狀態，因此不會強制切換。

• 費率表 — 每百萬輸入 $4.00、每百萬輸出 $20.00、每百萬次 5 分鐘快取寫入 $5.00、每百萬次 1 小時快取寫入 $8.00、每百萬次快取讀取 $0.20。Batch 雙向皆為半價，分別為 $2.00 / $10.00。

• 快取讀取是值得留意的異類：$0.20 是基礎輸入的 5%，而大多數 Claude 模型為 10%，Claude Fable 5.1 則是 2.5%。快取重複使用率高的混合工作負載，會實實在在感受到這項折扣。

• 快速模式 — 目前仍記載為研究預覽，僅限 Claude API 使用，獨立計價，每百萬輸入權杖 $8.00、輸出權杖 $40.00。可透過 speed: "fast" 及 fast-mode-2026-02-01 beta 標頭啟用。此模式不支援 Bedrock、AWS 上的 Claude Platform、Google Cloud 或 Microsoft Foundry，亦不支援 Batch API 與 Priority Tier 承諾用量。請注意，Claude Opus 5.5 完全不支援 Priority Tier。

基準測試說明了什麼，以及是在哪個設定下

努力設定是廠商表格與獨立表格無法逐列比較的原因，也是下方每個數字都附帶其設定的原因。

由廠商報告，Anthropic 自家的測試框架。 Anthropic 的發布說明指出，除非另有註明，所有 Claude Opus 5.5 的結果都是在 max effort 下使用自適應思考；例外是 Terminal-Bench 4.0，Claude Opus 5.5 以 xhigh 報告，GPT-6 Astra 則以 high 報告，因為那是各模型各自的最高分。在此基礎上，廠商報告 Terminal-Bench 4.0 為 66.4%、FrontierCode v1.1 Main 為 54.4%、CursorBench 4.0 為 57.8%、GDPval-AA v2.1 為 1,846 Elo、AutomationBench 為 40.0%、Humanity's Last Exam with tools 為 67.7%、Terminal-Bench-Science 0.1 為 58.7%、OSWorld 2.0 為 81.8%（部分完成），以及 Chartography with tools 為 89.0%。在該模型的預設 medium effort 下，廠商給出 FrontierCode 為 54.6%、CursorBench 為 52.5%。請注意同一份說明所揭露的內容：這些評估是在生產環境防護措施啟用的情況下執行，而當這些防護措施觸發時，資安任務由 Claude Opus 4.8 完成，生物學與前沿 LLM 開發任務則由 Claude Opus 5 完成；Anthropic 表示這很可能會降低 Claude Opus 5.5 在那些基準測試上的表現。因此，受影響評估所公布的分数並非此模型的純粹測量結果。

獨立，Artificial Analysis。 在 Intelligence Index v4.3.2 上，Claude Opus 5.5 得分 58，在 Artificial Analysis 標示為「Adaptive Reasoning, Max Effort, Default Fallback」的配置下——這是其測得的最高分，且領先數分，並在十項組成評估中領先六項。在同一指數與同一測試框架上，Claude Fable 5.1 得分 53，Claude Opus 5 得分 51。Artificial Analysis 公布了完整的努力程度階梯，這是此處最實用的獨立產物：max 58、xhigh 56、high 54、medium 51、low 42。其自身測量顯示，Claude Opus 5.5 在最大努力下每項指數任務約產生 119,000 個輸出 token，相較之下 Claude Opus 5 約 73,000、Claude Fable 5.1 約 78,000、GPT-6 Astra 約 27,000——這些 token 會以輸出 token 計費——其頁面報告每項指數任務成本為 $5.98。它還測得 Terminal-Bench 4.0 為 59.6%、Humanity's Last Exam 為 61.4%，而供應商在不同測試框架上以最大努力所得為 66.4% 與 67.7%。

把那兩段並讀對照，誠實的結論其實很有限。廠商的 66.4% Terminal-Bench 與獨立的 59.6% 是同一項基準測試，由不同的人在不同設定下執行，而那些設定並不保證一致；兩者也都不能作為你的工作負載的證據。真正可沿用（可轉移）的發現是努力程度階梯：在一個獨立指數上，這個模型自身不同設定之間的差距橫跨十六個百分點，這比它與前代模型之間的差距還要大。選擇努力程度比在這些模型之間做選擇更為重要，而那個標籤裡的「Default Fallback」條款，是上文所述的防護路由，並非基準測試的產物。

廠商回報的效率，並註明來源。 Anthropic 表示，Claude Opus 5.5 在大多數工作上的表現達到 Claude Fable 5.1 的水準，執行成本卻低約 40%；而相較於 Claude Opus 5，典型工作負載的成本約低 40%，但標價僅下調 20%。輸出速度則快 30% 以上。這些都是廠商對其自行挑選之工作負載平均值的描述。發布時客戶的說法也屬於同一類證據：Box 回報 token 用量只有三分之一，回答的冗長程度降低約 40%；Kiro 的 token 約為一半，呼叫次數少約 40%；Factory 的輸出 token 減少 20–25%；GitHub 則名列其測量過的對象中 token 與步驟數最少的幾個之一。Anthropic 也回報了一項內部事實查核測試，在其 18 份報告中有 16 份通過了某項品質門檻，而 Claude Fable 5.1 與 Claude Opus 5 無論怎麼嘗試都未能達標。這些全都是廠商自行回報，且無一經過稽核。其中所揭露的侷限異常坦率，值得記上一筆：Anthropic 表示 Claude Opus 5.5「經常懷疑自己正在被評估」。

最後，同系列的模型：Anthropic 表示 Claude Sonnet 5.5 與 Claude Haiku 5.5 將於「未來幾週內」推出。兩者都尚未出貨、尚未定價，而且今天也還未在任何平台上現身。

在不進行完整切換的情況下測試這四項變更

這裡的遷移風險不是品質——而是你在預備環境中從未執行過的某條程式碼路徑，正是會在正式環境中回傳 400 的那條。這四項破壞性變更全都是請求結構變更，這表示它們會確定且立即失敗，而找出你漏掉的路徑的唯一方法，就是讓真實流量流經它們。

Claude Opus 5.5 已於 OrcaRouter 上提供，型號為 anthropic/claude-opus-5.5，採用 Anthropic 官方定價、0% 加價——直接沿用供應商定價，因此供應商一旦調整價格，這裡當天即同步生效。

這讓你可以把一定比例的正式環境流量導向該模型，其餘流量仍由 Claude Opus 5 處理，同時觀察哪些請求失敗、原因為何，再逐一修正。這四種錯誤本身即說明瞭問題：每一種都會指出它拒絕的參數，而且在四種情況中的三種裡，還會指出替代的參數。自動容錯移轉會在某條路徑仍有問題時補上缺口——當請求對上你尚未完全掌握其特性的模型而失敗時，會改由你已掌握的模型接手，而不是把 400 錯誤直接呈現給使用者。

一個實用的工作順序：先替換模型 ID，並明確設定 effort，因為預設值已改為 medium；接著移除 thinking-disabled 和 forced-tool-choice 路徑；然後修正串流讀取器——依類型進行的區塊選取，以及 thinking.display 設定——因為這是會無聲失敗、而非大聲報錯的那一項；如果你使用 Bedrock，就把 computer-use 工具集的遷移留到最後，因為這是唯一在那裡不適用的項目。其他所有項目——價格、上下文視窗、快取費率，以及 1M token 預設值——都已經維持在你先前設定的狀態。

將一部分即時流量導向新模型，無須完整切換：OrcaRouter 上的 Claude Opus 5.5以 Anthropic 的牌價運行，並自動容錯移轉至你已充分掌握特性的模型。