Claude Opus 5.5 定價、快取與 Agent 成本

快速解答

Anthropic 於 2026 年 9 月 22 日推出 Claude Opus 5.5。這款模型面向長時間 Agentic Coding 與知識工作，提供 1M token context window、最高 128K 輸出 token，並且 Adaptive Thinking 始終開啟。Anthropic 的 API 定價為每百萬 input token 4 美元、每百萬 output token 20 美元，cache read 則為每百萬 token 0.20 美元。

Anthropic 表示，在其典型工作負載測試中，Opus 5.5 的執行成本比 Opus 5 約低 40%，輸出速度則快超過 30%。這些是 Anthropic 自己的工作負載測量結果，不代表所有應用都會得到相同比例的改善。

TowCue 認為更重要的變化是：Persistent Agent 的模型選擇正在變成系統經濟性問題。團隊應該衡量 每個通過審查並被接受成果的成本，把重複 context、快取命中、延遲、修復迴圈與人工審查一起計算，而不是只看單次 prompt 的牌價。

延伸閱讀可參考 GPT-6 Sol 與 Luna 的 Agent 經濟性、GitHub Copilot 自動模型分級，以及 Claude Code Projects 的平行 Agent 協調。

Claude Opus 5.5 改變了什麼？

Opus 5.5 是 Anthropic Claude 5.5 家族的第一款模型。Anthropic 將它定位於困難的 Coding、Computer Use、Agentic 工作與專業知識任務。

API model ID 為 claude-opus-5-5。Anthropic 列出的平台包含 Claude API、Amazon Bedrock、Google Cloud、Microsoft Foundry 與 Claude Platform on AWS；Claude 產品頁也表示，Opus 5.5 已提供給 Pro、Max、Team 與 Enterprise 使用者。

模型具備 1M-token context window，標準最大輸出為 128K token；Message Batches 搭配 Anthropic 文件列出的 beta header 時，最高可達 300K output token。

Claude Opus 5.5 要多少錢？

Anthropic 列出的標準 API 價格為：

$4 / MTok input；
$20 / MTok output；
5 分鐘 cache write 為 $5 / MTok；
1 小時 cache write 為 $8 / MTok；
cache read 為 $0.20 / MTok。

依 Anthropic 模型文件，Batch API 的 input 與 output 可享 50% 折扣。

相較 Opus 5，Anthropic 表示 input 與 output token 價格降低 20%，cache read 則降低 60%。官方發布文進一步表示，結合效率改善後，典型工作負載的執行成本約降低 40%。

這個 40% 應視為 Anthropic 報告的工作負載估算。你的實際節省幅度會受到 prompt 結構、輸出長度、cache reuse、tool call 與修復次數影響。

為什麼 cache read 對 Agent 特別重要？

長時間運行的 Coding Agent 會反覆攜帶穩定資訊，例如 repository instructions、tool schemas、架構說明、政策與先前任務 context。若每次 request 都為相同的穩定 prefix 支付完整 fresh-input 成本，長期下來會成為明顯支出。

Anthropic 明確指出，cache read 是長時間 Agentic 工作成本的重要部分。因此把 Opus 的 cache-read 價格降至 $0.20 / MTok，對 Persistent Workflow 的意義通常大於一次性問答。

真正值得問的不是單純的**「這個模型每 token 有多便宜？」，而是「這個工作流有多少昂貴 context 可以安全重用？」**

Opus 5.5 現在適合成為所有 Coding 任務的預設模型嗎？

不一定。Opus 降價並不代表 Routing 不再重要。

有明確測試保護的局部 refactor，仍可能更適合較便宜的模型。困難的 production bug、架構遷移或長時間自主任務，若更強推理能減少失敗嘗試與 reviewer 工作量，Opus 5.5 才可能更划算。

Anthropic 本身也提供多個模型層級，而 Opus 5.5 的預設 effort 為 medium。Adaptive Thinking 始終開啟，但可透過 effort 參數控制思考深度。這讓 Routing 多了一個維度：團隊可以同時依任務後果與不確定性調整模型與 reasoning effort。

TowCue 判斷：最佳化完整 Agent 迴圈

對正式 AI 工作流來說，成本公式應該比 token 價格更完整：

task → model + effort → context → tools → execution → tests → review → repair → accepted outcome

至少應追蹤：

fresh input 與 cached-input 成本；
output 成本；
到達可審查結果的時間；
failed tests 與 repair turns；
人工 reviewer 時間；
review 後的返工；
上線後逃逸的 defect。

單次 request 較貴的模型，如果能減少重試，仍可能有更低的「每個被接受變更成本」。而當任務範圍明確、驗證強時，較便宜的模型則可能更有優勢。

更快的輸出速度有什麼影響？

Anthropic 表示，Opus 5.5 的輸出速度比 Opus 5 快超過 30%。互動式工作會直接感受到較低 latency；對 Agent 而言，效果可能累積，因為一個任務通常包含多次連續模型呼叫，中間還穿插工具執行。

Anthropic 另外在 Claude Code 與 Claude Platform 提供 Opus 5.5 Fast mode，官方標示最高可達 2.5 倍速度。Fast mode 採不同價格：input 為 $8 / MTok、output 為 $40 / MTok，因此它應被視為 latency 與成本之間的選擇，而不是免費加速。

哪些團隊最值得先評估 Opus 5.5？

最明確的對象，是已經使用 Opus 等級模型進行長時間 Coding session、Computer Use Agent、研究工作流，或其他由重複 context 與 reviewer 時間主導成本的團隊。

如果較輕量模型已能穩定處理短小且可確定性驗證的任務，就沒有必要全面遷移。更好的方法是建立一組真實工作評估集，在相同工具、指令與測試條件下，把 Opus 5.5 與目前預設模型比較。

不要只看是否完成任務，也要比較總耗時、重試次數、審查成本與 cache hit 行為。

更換預設模型前應該測試什麼？

優先使用代表團隊真實工作的任務，而不是只看公開 benchmark。至少包含一個機械式修改、一個有歧義的 bug、一個跨多檔案功能、一個研究型任務，以及一個長時間 Agent 任務。

每次執行記錄 model、effort、fresh input、cache reads、output、總耗時、tool failures、repair turns 與 reviewer time，最後比較真正被接受成果的總成本。

若應用高度依賴 prompt caching，應把 cache architecture 與模型品質分開測試。Cache-read 降價只有在穩定 context 被正確組織、能實際重用時才會產生價值。

TowCue 判斷：模型能力正在變成 Agent Stack 的其中一項成本

Opus 5.5 再次顯示 Frontier AI 產品正在發生同一種變化。模型能力依然重要，但正式環境的經濟性愈來愈取決於模型周圍的系統：

routing policy → reusable context → model + effort → tools → verification → human review

這也改變了採購問題。與其問哪個模型贏了 benchmark，不如問哪一種配置能為你真正執行的工作負載，產生最好的「通過審查成果」。

最強模型應該用在歧義與失敗成本足以支持它的地方；最便宜模型則應用在容易驗證的任務。重複 context 也應被視為可以設計、測量與最佳化的基礎設施。

Claude Opus 5.5 降低 Agent 成本：為什麼快取經濟性開始影響模型選擇