Anthropic 正式推出 Claude Opus 5.5。對開發者而言，今次升級最值得留意的並不只是模型能力再提升，而是 Agentic Coding 成本明顯下降，同時 API 行為出現數項 Breaking Changes。如果現有系統正使用 Claude Opus 5，並非單純更換 Model ID 就一定完成遷移。
1M Context 不變 價錢再減
Claude Opus 5.5 的 Claude API Model ID 為：
claude-opus-5-5
它維持 1M tokens Context Window 及最高 128K output tokens，但 API 價格由 Opus 5 的 US$5 / US$25，下調至每 100 萬 tokens：
| 項目 | Opus 5.5 | Opus 5 |
|---|---|---|
| Input | US$4 | US$5 |
| Output | US$20 | US$25 |
| Cache Read | US$0.20 | US$0.50 |
| Cache Write（5 分鐘） | US$5 | US$6.25 |
Batch API 更降至 US$2 / US$10。Anthropic 表示，由於新模型完成同一工作所需 tokens 亦減少，典型 workload 整體成本可較 Opus 5 低約 40%；輸出速度則快超過 30%。
這點對長時間運行的 Coding Agent 特別重要，因為 Agent 成本很多時並非來自最初 prompt，而是不斷重讀 context、tool call 及反覆修改。今代 Cache Read 價格由 US$0.50 大幅降至 US$0.20 / MTok，實際影響可能比單純 Input Token 減價更大。
Coding 提升有多大？
Anthropic 公布的最高設定測試中，Opus 5.5 在 Terminal-Bench 4.0 達 66.4%，Opus 5 為 52.3%；FrontierCode v1.1 為 54.4% vs 48.0%；CursorBench 4.0 則為 57.8% vs 46.6%。
但要注意 Opus 5.5 在預設 medium effort 下的成本效益。在 FrontierCode v1.1，Opus 5.5 已達 54.6%，略高於 GPT-6 Astra 最高設定的 53.3%，官方估算每項工作的成本約只有後者五分之一；Terminal-Bench 4.0 則以約 40% 成本取得相若表現。在 CursorBench 4.0，Opus 5.5 預設設定亦高於 GPT-5.6 Sol 的最高成績約 11 個百分點，而每項工作成本約為三分之一。
這些仍屬不同模型、供應商及測試 harness 下的 benchmark，不能直接等同所有 production workload。Anthropic 不只追求最高 reasoning score，而是希望開發者在日常設定下，以較少 tokens、tool calls 及成本完成同一工作。官方同時指出，Opus 5.5 的輸出速度較 Opus 5 快超過 30%。
官方亦特別將 Opus 5.5 定位在 長時間 Agentic Coding、跨 repository 修改、codebase migration、audit 及 knowledge work。Anthropic 最新模型選擇文件甚至建議大部分 workload 先由 Opus 5.5 開始，只有更高難度 reasoning 或長週期 Agent 任務，在 Opus 5.5 高 effort 仍不足時才考慮 Fable 5.1。
升級前必看：4 個 Breaking Changes
如果你目前使用 Opus 5，以下四項最容易令 production code 直接報錯：
- Thinking 不能再關掉：
thinking: {"type":"disabled"}會直接回傳 HTTP 400；舊有budget_tokens手動控制亦不再支援。Opus 5.5 改為 Adaptive Thinking 常駐，以output_config.effort控制 low、medium、high 等推理力度。 - 不能再 Forced Tool Use：
tool_choice: {"type":"tool"}及"any"均會報錯，只支援auto或none。需要強制 JSON Schema 時，應改用strict: true或 Structured Outputs。 - Thinking Block 綁定 conversation：如果把之前 Claude 回傳的 thinking block 傳回 API，便不要中途修改之前的
system、tools或舊 messages。新帳戶可能直接收到 400。最穩妥做法是將 conversation 設計成 append-only。 - 舊 Computer Use API 要改：Claude API 及 Google Cloud 不再接受
computer_20251124，要轉用computer_toolset_20260801；Amazon Bedrock 暫時例外，舊版本仍可使用。
Thinking 最大改變：不要再自己指定 Budget
以前不少開發者會用：
thinking={"type": "disabled"}
或者自行設定 budget_tokens。
Opus 5.5 應改為：
client.messages.create(
model="claude-opus-5-5",
max_tokens=16000,
output_config={"effort": "low"},
messages=[
{"role": "user", "content": "..."}
],
)
請注意 Opus 5.5 預設 effort 已由 Opus 5 的 high 改為 medium。Anthropic 同時指出，新模型在相同 effort 下通常會使用更多 thinking tokens，因此不應直接照搬 Opus 5 的 effort 設定，最好重新跑自己的 eval，找出 latency、成本與準確度的平衡點。
換句話說，今後控制 Claude 成本的關鍵，不再是「開不開 Thinking」，而是 Thinking 開着，但給多少 effort。
Agent 開發另一個坑：不要亂改 History
Opus 5.5 加入 Preserved Thinking 保護。每個 thinking block 都會與原本 conversation prefix 綁定。
假如第一輪 request 使用了一套 system prompt、tools 和 messages，第二輪卻把舊 system prompt 改掉、刪除之前 tool result、重新整理 history，或者更改工具 definition，再把舊 thinking block 傳回去，新帳戶預設可能收到：
400 invalid_request_error
Anthropic 建議的模式很簡單：system 及 tools 在 session 內保持穩定，messages 只 append，不回頭重寫。
這亦意味着自行開發 Agent Framework、Router、Memory Compaction 或 multi-model orchestration 的團隊，升級 Opus 5.5 前尤其要測試 history management。Claude Code、Claude Agent SDK 及 Managed Agents 已處理相關機制。
Fast Mode：2.5 倍速度，但價錢亦翻倍
Opus 5.5 同樣提供 Fast Mode，最高約 2.5 倍速度：
Input：US$8 / MTok
Output：US$40 / MTok
現階段 Fast Mode 屬 Research Preview，而且 只供 Claude API；Amazon Bedrock、Claude Platform on AWS、Google Cloud 及 Microsoft Foundry 暫不支援。
因此對 IDE autocomplete 或 latency-sensitive Agent 可以考慮 Fast Mode；若是 background coding agent、migration 或 overnight task，普通模式的 cost-performance 反而可能更合理。
Claude Code 訂閱用戶：五小時用量同步提高
今次更新不只涉及 API 價格。Anthropic 同時提高 Pro、Max 及 Team 訂閱方案的五小時使用上限，並向訂閱用戶提供一次 rate limit reset；這次重設額度可以先保留，到需要時才使用。
這項改動與 API Rate Limit 是兩回事，主要影響透過 Claude 訂閱方案使用 Claude Code 的開發者。對需要連續進行大型 codebase migration、audit 或長時間 Agent 任務的用戶而言，可用運算額度增加亦是今次 Opus 5.5 實際體驗的一部分。
Claude Code 用戶最快升級方法
如果項目本身已使用 Claude API，Anthropic 今次甚至準備了 migration skill。在 Claude Code 輸入：
/claude-api migrate this project to claude-opus-5-5
Claude Code 會檢查 Model ID、Thinking、Tool Choice、平台差異及其他 Breaking Changes，再修改相關程式碼，最後列出仍需人工確認的項目。
如果只是最簡單、沒有 Forced Tool Use 或特殊 Thinking 設定的 Messages API app，基本變更則只是：
# Before
model = "claude-opus-5"
# After
model = "claude-opus-5-5"
長 Session 更容易跟進
Anthropic 今次亦特別提到 Opus 5.5 的溝通方式。官方表示，新模型針對 Opus 5 收到的常見意見作出調整，會更優先交代重要資訊，亦更能依照使用者指定的寫作規則輸出，令長時間工作 Session 較容易跟進。
這對 Coding Agent 並非純粹「文筆變好」。當 Agent 要連續處理數十個步驟、修改大量檔案，回報是否簡潔、能否維持指定輸出格式，以及是否清楚交代已完成與待處理事項，都會影響工程師檢查結果的時間。Anthropic 引述早期測試者亦指出，Opus 5.5 的 code comments 較 Opus 5 短而實用。
開發者應怎樣理解 Opus 5.5？
Anthropic 不只是追求「模型答對更多題」，而是試圖降低 每完成一項 Agent 任務的實際成本。
對 Coding Agent 而言，真正計成本的單位從來不是每百萬 token，而是「完成一次 migration、debug、code review 或 multi-step workflow 要多少 tool calls、多少 rounds、多少 cache reads，以及最後是否要工程師重做」。
Opus 5.5 的 Input / Output 單價只比 Opus 5 低 20%，但 Anthropic聲稱典型 workload 成本可下降約 40%，原因正是模型需要較少步驟及 tokens 完成工作。這亦可能是今次升級對開發者真正最值得測試的地方。
