正在替客服或程式助理付 Claude API 帳單的小團隊，可以把 Opus 5.5 排進測試了。Anthropic 9 月 22 日發布的新模型調低了單價，但升級需要同時檢查程式：舊流程若把 thinking 關掉，或指定模型一定要呼叫某個工具，直接換代號可能先收到錯誤。
我會先拿一批已知答案的工作比較「完成一件正確任務要多少錢」，再決定是否切換。這篇先把價差算清楚，接著指出最容易卡住升級的地方；沒有把官方測試當成本站實測。
單價降 20%，為什麼官方說能省 40%？
依官方定價表，一般 API 價格如下，單位都是每百萬 token、美元：
| 計費項目 | Opus 5 | Opus 5.5 | 單價降幅 |
|---|---|---|---|
| 一般輸入 | 5 | 4 | 20% |
| 輸出 | 25 | 20 | 20% |
| 快取讀取 | 0.50 | 0.20 | 60% |
| 5 分鐘快取寫入 | 6.25 | 5 | 20% |
Anthropic 在發布文章中說，預設設定下的典型工作量可省約 40%；這個結果同時包含單價與任務消耗 token 的變化。它是供應商的工作量測試結果，不能直接拿來把你的上月帳單乘以 0.6。
舉一筆純價格試算：假設某批任務使用 100 萬一般輸入、10 萬輸出 token，完全沒有快取。Opus 5 是 5 + 0.1 × 25 = 7.50 美元，Opus 5.5 是 4 + 0.1 × 20 = 6.00 美元，省下 20%。
如果同一批任務另有 1,000 萬 token 的快取讀取，兩者再加 5 與 2 美元，變成 12.50 與 8.00 美元，這一筆便省下 36%。這是固定用量的假設例子，沒有計入建立快取的寫入費、其他工具費或稅費；實際 token 數也可能隨模型改變。
所以，先看帳單裡一般輸入、輸出和快取各占多少。常常重複讀取同一份程式庫或文件的流程，值得優先重算；只偶爾送一個短問題的流程，收益可能不同。若要拆得更細，可接著看 AI 成本優化。
舊程式最容易卡在 thinking 與工具呼叫
這一段適用於自己串接 Messages API 的開發者。官方遷移指南另說明，使用 Claude Managed Agents 時，只需更新模型名稱；兩種介面不要混為一談。
Messages API 的模型代號是 claude-opus-5-5。先查舊請求有沒有下面兩類設定：
thinking.type設為disabled，或使用手動budget_tokens：新模型不接受，會回傳 400。它固定使用 adaptive thinking，可用effort調整思考程度。tool_choice.type設為any或tool：新模型不接受強制工具呼叫。原本靠這個參數保證拿到指定格式的流程，需要重新設計與驗證。
還有一種錯誤不一定發生在送出請求時：程式若只讀 content[0].text，第一個區塊可能是 thinking，便拿不到預期的文字。解析時應依區塊的 type 取值；工具循環則要完整保留並送回 thinking 區塊，即使其中沒有可顯示的文字。
這些只是最常見的入口檢查，完整遷移仍要依自己原本的模型版本核對指南。使用電腦操作、路由到其他模型或中途修改對話的產品，也有額外相容性事項。
思考程度相同，才比較得出帳單差在哪裡
Opus 5.5 的模型說明列出的預設 effort 是 medium。如果舊程式沒有明確指定，升級後可能同時改變模型與思考程度；看到更快或更便宜，還不能判斷是哪一項造成的。
思考用掉的 token 也按輸出計費，即使介面沒有顯示思考文字。因此，比帳單時要讀 API 回傳的用量，不能只計算最後那幾句回答有多長。
例如你有一個客服分類流程，回答只需要類別與一句理由。測試時除了分類是否正確，也要記錄失敗重試、截斷回應和人工修正；便宜的單次呼叫若經常重跑，最後未必划算。反過來說，修程式的任務若少走幾輪彎路，節省也可能大於單價降幅。
我的建議是先保留舊版本，選一小批能核對結果的任務，明確設定 effort，記錄總費用與成功件數。品質合格、相容性問題處理完，再逐步增加用量。用自己的完成成本決定升級，比替每種工作套用同一個折扣可靠。
只在 Claude 網頁聊天的讀者，不需要照這篇改 API 參數；一般操作可看 Claude 使用指南，程式工作則看 Claude Code 入門。