Claude Opus 5.5 對決 Opus 5：答案相同，輸出 token 減半

Claude Opus 5.5 的定價比 Claude Opus 5 低 20%。每百萬個輸入與輸出 token 分別是 $4 與 $20，Opus 5 則是 $5 與 $25。無論模型表現如何，這 20% 都會直接反映在帳單上。真正值得比較的是扣除降價後，模型本身還能省下多少。在 13 個單次任務中，兩個模型都使用各自的預設設定，Opus 5.5 的計費金額低 65%；即使套用相同單價，仍便宜 56%。到了多步工具迴圈，差距就小得多：帳單少 37%，固定單價後則少 22%。

TL;DR

• 在 468 次評分呼叫中，Opus 5.5 每項任務的計費金額為 $0.0072，Opus 5 則為 $0.0204，兩者所有任務都答對。
• 套用相同價格後，Opus 5.5 在這些任務上仍便宜 56%：平均輸出 341 個 token，Opus 5 則是 799 個。
• 在包含四個問題的工具迴圈中，同價差距縮小到 22%，因為成本主要來自輸入 token，而且兩個模型讀取相同檔案。
• 在 max effort 下，Opus 5.5 跑完該迴圈的成本是自身預設值的 3.3x，但沒有多解出任何問題。
• tool_choice 設為 any 或指定工具時，現在會回傳 HTTP 400；Opus 5 兩者都接受。

Anthropic 於 2026-09-22 發布 Opus 5.5，並宣稱在典型工作負載下，「執行成本比 Opus 5 低 40%」。這項說法只有後半段，也就是每項任務使用較少 token，取決於模型實際做了什麼，因此我們針對這部分進行測量。

Claude Opus 5.5 實際改了什麼？

降價只是較小的變更。更大的差異是 thinking 開關消失了。Adaptive thinking 會讓模型自行決定回答前要推理多久。無論 API 是否顯示這些 reasoning token，都會按輸出 token 計費。在 Opus 5.5 上，此模式永遠開啟。唯一可調整的控制項是 effort，這個請求參數從 low 到 max 共分五級，用來限制模型願意投入多少推理資源。

Opus 5 接受 thinking: {"type": "disabled"}。在我們對 Opus 5 的測量中，只有這項設定能讓帳單降到與 Opus 4.8 相同的水準。這個選項現在已不存在。

表格之外還有兩項變更需要注意。預設 effort 從 high 降為 medium，因此未傳送 effort 欄位的請求，不會使用 Opus 5 原本的推理深度。進度更新的變更則不會顯示任何錯誤。模型過去會在工具呼叫之間輸出簡短說明，現在這些內容改以 thinking 區塊傳回。除非明確要求顯示，否則文字會是空的。原本會串流顯示這些說明的使用者介面將直接變得安靜，而且沒有錯誤可攔截。

發布時公布的 benchmark 怎麼說？

Anthropic 發布的表格中，Opus 5.5 在所有程式開發與知識工作 benchmark 上都領先 Fable 5.1，多數項目也高於 GPT-6 Astra。以下數據來自 Anthropic，測試使用 max effort 的 adaptive thinking，Terminal-Bench 項目則使用 xhigh。

Anthropic 對自己的表格附上了一項少見的提醒：到了這個水準，「benchmark 的差距已無法可靠反映實際使用上的差異」，Opus 5.5 與 Fable 5.1 的實際差距比得分看起來更小。引用這些數字前，還需要留意兩項註記。AutomationBench 由 Zapier 執行，且未使用備援模型，因此每次安全防護介入都會計為失敗。整張表也都開啟正式環境的安全防護。分類器介入時，網路安全任務會交給 Opus 4.8，生物學任務則交給 Opus 5。

這些數據都沒有說明完成任務要花多少錢，因此我們另外進行了測量。

單次任務真的比較便宜嗎？

是，而且大部分差距來自實際效率，而非定價。單次任務是指一次請求、一次回答，不使用工具。測試內容包含算術與計數題，例如執行 200 步的迭代規則，或計算含障礙格子的網格路徑數。我們準備了 13 項任務，每項重複 3 次，並在五個 effort 等級與預設設定下，分別測試 Opus 5.5 和 Opus 5，總計 468 次評分呼叫。執行前，所有標準答案都先用 Python 暴力求解。每個 prompt 也加入唯一的隨機字串，避免模型與我們之間的任何一層從重複請求的快取直接回答。每項任務的成本依各次呼叫實際計費的 token 計算，包含 thinking，並套用 Anthropic 定價，而不是直接讀取回應中的成本欄位。

兩個模型在預設設定下的正確率都是 100%，其他每個等級也都至少有 97%。三次錯誤分散在不同任務與等級，沒有集中於較低的 effort。在這組任務中看不到正確率驟降，因此成本是唯一差異。

兩個模型的 effort 階梯表現不同。Opus 5 從 low 到 max 的成本介於 $0.0197 至 $0.0220，差距只有 12%，幾乎持平。Opus 5.5 則相差 4x，從 $0.0060 到 $0.0240。Effort 在 Opus 5.5 上確實能控制成本，但對 Opus 5 幾乎沒有作用。因此，遷移時若直接沿用原設定，結果可能與原本差很多。

在最難的五項任務中，差距進一步擴大。Opus 5.5 使用預設設定時，每項任務成本為 $0.0113，Opus 5 則為 $0.0375；輸出 token 中位數分別是 585 與 1,145。

Agent 帳單會持續累積，工具迴圈的結果如何？

進入迴圈後仍能省錢，但倍數較小。要如實比較 Opus 5.5 與 Opus 5，工具迴圈是更合理的測試。每一輪就是一次請求：模型要求呼叫工具，程式執行工具，再將完整對話記錄送回模型。因此，五輪對話會對逐輪增長的對話記錄計費五次。影響帳單的是輪數，而非每個 token 的單價。我們為兩個模型提供三項工具，包括列出檔案、讀取檔案與搜尋。測試對象是一個小型合成服務，另有四個問題，必須跨越三到四個檔案追蹤呼叫鏈才能回答。兩個模型使用相同介面、工具與 prompt，每個實驗組執行 12 次。

Opus 5.5 使用預設設定時，每次執行成本比預設的 Opus 5 低 37%，輪數少 12%，輸出 token 少 30%。若按成功解出的問題計算，差距會擴大到 43%，因為 Opus 5 有一次未解出。這與供應商宣稱的「執行成本低 40%」相當接近，也是帳單上實際會看到的數字。

在這類工作負載中，大部分節省來自降價，原因值得理解。迴圈每輪都會重新傳送完整對話記錄，兩個模型讀取相同檔案。雖然輸出 token 減少 30%，總 token 卻只減少 19%。工作負載越昂貴，少寫一些內容能省下的比例反而越低。下一節會量化這項差異。

在迴圈中把 Opus 5.5 降到 low 並未省錢。模型平均多要求一輪，重送對話記錄的額外成本吃掉了 token 節省。能在單次任務中直接降低成本的 effort 控制，到了迴圈就失去效果，因為帳單取決於輪數，而非推理深度。

節省金額中有多少只來自降價？

視工作負載形態而定，比例介於七分之一到五分之二。下表中間欄將 Opus 5.5 實測使用的 token 改按 Opus 5 費率計價，因此可以看出在定價相同時，Opus 5.5 相較於 Opus 5 能靠減少輸出省下多少。

單次任務確實反映模型效率提升：降價只占節省金額的 14%，其餘都來自模型減少輸出。規劃時應以工具迴圈那列為準，因為多數 agent 流量都是這種形態。在該項測試中，降價占整體節省幅度的 41%。

提高 effort 值得嗎？

在這類工作負載下不值得，而且代價很高。Opus 5.5 使用 max 時，每次工具迴圈成本為 $0.1087，是自身預設設定的 3.3x，但解出的仍是相同 12 個問題。額外預算都花在工具呼叫上：中位數從預設的 5 次增至 12 次，輸出 token 也從 427 增至 3,124。在單次任務中，max 是唯一比 Opus 5 更貴的等級，成本分別是 $0.0240 與 $0.0220。

這些預算都用在推理上。在這些只有單一答案的任務中，thinking 占 Opus 5.5 預設輸出 token 的 98.4%，在 max 則占 99.6%。所有 thinking token 都按輸出費率計費，而且在預設顯示設定下完全看不到。Anthropic 的官方指引建議只在前沿問題上使用 max。實測結果很直接：對模型本來就能解決的任務，提高任何一級都只會增加成本。

更換 model ID 後，哪些請求會壞掉？

有兩種可在 Opus 5 使用的請求格式，換成 Opus 5.5 後會回傳 400。現有程式碼很容易遇到這兩種情況。

系統會拒絕強制使用工具。用戶端若指定模型必須呼叫某項工具，這也是從聊天模型取得結構化 JSON 的常見做法，就會收到以下錯誤：

tool_choice: type "tool" and "any" are not supported for this model.

透過 OpenAI 相容用戶端也會收到相同錯誤。該介面的同類請求會寫成 tool_choice: "required"，或指定具名函式。auto 與 none 仍可使用。遷移時應在 prompt 中清楚描述何時需要使用工具，並透過嚴格的工具 schema 或 structured outputs 取得符合 schema 的 JSON。

Thinking 無法停用。thinking: {"type": "disabled"} 與手動設定 budget_tokens 都會失敗。在 OpenAI 相容介面上，對應的 reasoning_effort: "none" 也會遭拒。替代方案是使用 effort 參數：

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[{"role": "user", "content": "Summarize this incident report in five bullets."}],
    output_config={"effort": "low"},   # low | medium | high | xhigh | max; medium is the default
)

# Thinking is billed as output whether or not you can read it.
print(response.usage.input_tokens, response.usage.output_tokens)

low 最接近舊版關閉 thinking 的行為。在我們的單次任務中，它既是最便宜的等級，也能維持正確率。但 thinking 並未免費消失：模型仍會推理，thinking 也仍按輸出 token 計費。

Prompt 預算能直接沿用嗎？

Token 預算可以完全沿用。相同的四組輸入在兩個模型上的計數幾乎一致：英文段落是 1,277 對 1,275，Python 程式碼是 583 對 581，JSON 工具引數資料塊是 482 對 480，中文內容則是 500 對 498。固定相差的兩個 token 來自請求框架，而非文字本身。因此，在 Opus 5 上調整好的 context 預算或分塊門檻，不需要為 Opus 5.5 重新建立基準。

什麼時候該切換？

如果目標是降低成本，只要先修正上述兩種請求格式，就可以改用 Opus 5.5。即使排除降價因素，在正確率相同的情況下，單次任務仍便宜 56%，工具迴圈也便宜 22%，這不是小幅差異。大多數正式環境實際遇到的比較，也會是預設設定對預設設定。

Effort 應重新調校，不要直接沿用。預設值從 high 改成 medium，可調範圍是 Opus 5 的四倍，而且最佳等級取決於工作負載形態。在單次任務中，low 最便宜且正確；工具迴圈則是預設設定同時勝過 low 與 max。

常見問題

Claude Opus 5.5 真的比 Opus 5 便宜 40% 嗎？ 帳單上的結果很接近：Opus 5.5 在我們的工具迴圈中，每次執行成本比 Opus 5 低 37%，單次任務則低 65%。其中 20 個百分點來自較低定價，無論模型如何運作都能省下。排除降價後，工具迴圈的效率差距為 22%，單次任務則為 56%。

Opus 5.5 還能停用 thinking 嗎？ 不能。thinking: {"type": "disabled"} 與手動 token 預算在 Opus 5.5 上都會回傳 400。請改用 output_config.effort，其中 low 是最便宜的設定。每個等級的 thinking token 都會按輸出計費。

什麼可以取代強制使用工具？ 保留 tool_choice: {"type": "auto"}，並在 prompt 中明確說明觸發工具的條件。需要符合 schema 的 JSON 時，使用嚴格的工具 schema 或 structured outputs。在 Opus 5.5 上，any 與具名工具格式會直接回傳 400，不會靜默降級，因此你看到的是請求失敗，而不是錯誤答案。

需要重新測量 prompt 大小嗎？ 不需要。在文字、程式碼、JSON 與中文內容上，相同輸入在 Opus 5 和 Opus 5.5 的 token 計數相同，因此 context 預算可以原樣沿用。

Opus 5.5 可以取代 Fable 5.1 嗎？ 在 Anthropic 自己公布的 benchmark 表格中，Opus 5.5 以 Fable 5.1 40% 的 token 價格，在所有列出的 benchmark 上都取得更高分。Anthropic 仍將 Fable 5.1 定位於高難度推理與長期 agent 工作，並表示實際差距比得分顯示的更小。可靠的做法仍是重新執行自己的 eval，而不是只看表格。

相關測量：Claude Opus 5 與 Opus 4.8 的比較、GPT-6 Astra 的 effort 階梯，以及各供應商的 thinking 控制方式。

測量日期為 2026-09-23，也就是發布後一天。測試透過連接 Claude API 與 OpenAI 相容介面的閘道執行。單次任務共進行 468 次評分呼叫（13 項任務，標準答案在本機以暴力求解產生，重複 3 次，6 種 effort 設定，2 個模型），另有 48 次工具迴圈執行（4 個多步問題，重複 3 次，4 個實驗組）。每個 prompt 都加入 salt；各模型透過支援其 effort 參數的介面呼叫；成本依 Anthropic 定價計算，而非直接讀取回應。

← 返回部落格