Claude 5.5：停止為失敗任務付費

真正重要的 Sonnet 與 Opus 配置：effort、快取、驗證，以及每個完成任務的成本

最便宜的模型，不是 token 單價最低的那個

而是能一次把事做完、通過檢查，且不會讓你為同一段上下文重複付費五次的模型

Sonnet 5.5 與 Opus 5.5 讓這個差異變得格外重要。一個的定價適合跑量，另一個則專為更困難的工作而生。兩者都有全新的 effort 行為，而且在設計良好的 Agent 循環中搭配快取使用時，成本都可能低得令人意外

直接把舊配置套用到任一模型上，結果可能會變慢、變貴，甚至直接噴出 400 錯誤

以下是我會採用的配置方式

1任務 → SONNET 5.5 → 檢查 → 必要時改用 OPUS 5.5 → 已驗證的結果
2             ↘ effort ↗         ↘ 快取 + 用量帳本 ↗

我在 Substack 上分享 AI Agents、工作流程與生產環境系統的實用解析

點此訂閱電子報

決定你技術架構的關鍵數字

多數模型比較都從「每百萬 token 多少美元」開始

但你的 Agent 交付的不是 token，而是完成的任務

https://x.com/claudeai/status/2102435511222890900

再強調一次：那是他們的測試。你的架構需要你自己的數據

這意味著驗證不能只是看完一個漂亮答案後隨手比個讚。寫程式時，就用會擋下合併請求的那組測試；做資料擷取時，就拿必填欄位去跟標註好的資料集比對；做研究時，就記錄引用的來源是否真的支持每一項主張。別只算 demo 裡那些成功案例，也要把始終無法通過驗證的任務成本算進去

另外，要單獨檢視長尾難題。如果最便宜的設定能處理 90% 的請求，卻把一半預算燒在剩下那 10%，那麼平均值就會掩蓋掉真正需要換模型的那段流程

5.5 價格表到底說了什麼

截至 2026 年 10 月 3 日，依 Claude API 標準費率計算，每百萬 token 的價格如下：

1SONNET 5.5
2全新輸入  $2       輸出  $10
3快取讀取   $0.20    快取寫入  $2.50 / 5 分鐘, $4 / 1 小時
4
5OPUS 5.5
6全新輸入  $4       輸出  $20
7快取讀取   $0.20    快取寫入  $5 / 5 分鐘, $8 / 1 小時

兩個模型都支援 1M token 的上下文視窗，最大輸出為 128K token。這些是上限，不是叫你想辦法把它們塞滿的理由。

模型規格與定價

比較特別的是快取讀取那一行

Opus 的全新輸入與輸出價格是 Sonnet 的兩倍，但快取前綴在兩個模型上的費用完全相同，都是每百萬 token $0.20。這不代表跑一次 Opus 會一樣便宜：它在新輸入、輸出和快取寫入上還是付得更多。但這確實意味著，在大量讀取的對話中，兩者的價格差距會縮小

還有第二個大家常忽略的差異。Anthropic 說的「比 Opus 5 便宜 40%」是對典型\執行成本\的估算。Opus 5.5 的全新 token 價格降了 20%；快取讀取價格則降了 60%。這兩個數字有關聯，但不能混為一談

Effort 是路由決策，不是品質滑桿

Sonnet 5.5 支援 low、medium、high、xhigh 和 max。在 API 上預設為 high；而在 Claude 應用程式中，Anthropic 表示預設為 medium。Opus 5.5 在 API 上預設為 medium。這些等級的意義，並不完全等同於上一代模型中相同名稱所代表的程度。

我的初步對應方式：

• Sonnet low：用於範圍明確、對延遲敏感，且有低成本驗證方式的請求
• Sonnet medium：用於規格清楚的程式開發與例行多步驟工作
• Sonnet high：當 medium 跑出來的結果過不了實際驗證，或任務本身已被證明具有一定複雜度時使用
• Opus medium：用於定義模糊、跨檔案、週期長的任務，也就是 Sonnet 會一直繞圈圈打轉的情況
• Xhigh/max：只有當你的評估結果顯示，多花的時間與 token 確實值得時才用

這只是起點假設，不是放諸四海皆準的階級表。在 Anthropic 公布的 Sonnet 5.5 FrontierCode 結果中，xhigh 的分數反而高於 max。花更多力氣並不保證結果更好

Anthropic 的註解說明了這個反直覺的結果：在 max 模式下，模型更常啟動額外的程式碼審查工作。在其中兩個被檢視的案例裡，這導致了逾時，或是超出任務範圍的修改。

失敗的原因不是「模型想得不夠」，而是把力氣用錯了地方。如果你的 Agent 已經能通過驗證，額外的審查回合只會增加成本，甚至製造新的錯誤

https://x.com/edwinarbus/status/2104675431853248816

另外，別以為把 max_tokens 調低就叫最佳化。這個上限同時涵蓋思考過程與可見輸出。如果你在工作做到一半時把它切斷，換來的不會是省錢，而是一個被截斷的答案加上第二次執行的費用

https://x.com/claudeai/status/2104633115620823187

這是個很有吸引力的上市宣傳。但正式環境的配置，還是得贏過你自己的基準線才行

先跑一小輪掃描，別急著發明模型路由器

挑 10 到 30 個你真正在乎的任務。包含簡單工作、定義模糊的工作，以及日誌裡那些煩人的失敗案例。為每個任務準備一個驗證機制：測試、結構化比對、已知答案，或在執行前先記錄好的人工評分標準

以下是最精簡但實用的 API 探測程式。它會記錄你需要的 usage 欄位。針對同一個任務，在各模型與各 effort 等級上跑一遍，再接上你自己的通過／失敗檢查。這不是完整的 Agent 基準測試

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # 換成 claude-opus-5-5 再跑一次
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # 換成 high 再跑一次
8    messages=[{"role": "user", "content": "把這裡換成真實任務。"}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("fresh", usage.input_tokens, "output", usage.output_tokens)
15print("cache read", usage.cache_read_input_tokens)
16print("cache write", usage.cache_creation_input_tokens)

這段程式假設你已安裝官方的 Anthropic Python 套件，並設好了 ANTHROPIC_API_KEY 環境變數。它只是一次未啟用快取的獨立呼叫，所以快取讀取與寫入理應都是零。下一節會說明如何改變這一點

對於真正的 Agent，請把所有 API 呼叫在同一個任務 ID 下的用量加總起來，包含重試與工具呼叫。只有當驗證機制判定工作完成時，才算一次通過

在決定預設配置前，先比較每次通過的總花費（以美元計）

讓測試保持誠實：

• 在比較不同配置前，先凍結任務集與驗證機制
• 對每個候選方案使用相同的工具、權限、上下文與輸出要求
• 記錄通過率、總支出、每次通過成本、延遲，以及耗時最長或最貴的失敗案例
• 把 stop_reason: "max_tokens" 視為未完成，而不是低成本的成功

上面那段簡短範例為了單輪探測使用了 8K 的輸出上限。別把這個上限照搬到長任務的程式開發 Agent 上

Anthropic 建議為 agentic 工作保留更大的空間，因為隱藏的思考過程也計入同一個上限。

根據工作需求設定上限，然後透過 effort、快取與任務預算來控制花費，而不是強迫回答在工作做到一半時停下來

把工作裡穩定的部分快取起來

Agent 會反覆傳送相同的系統指令、工具定義、儲存庫結構圖與先前的對話內容。如果那段前綴是固定的，提示詞快取對成本的影響會遠大於小幅改寫提示詞

舉例來說，200K 的快取 token 被讀取 50 次，就是 10M 的快取讀取 token。以每百萬 $0.20 計算，在任何一個 5.5 模型上，這些讀取只需 $2。

若用 Opus 5.5 把同樣的 10M token 當作全新輸入傳送，則要花 $40。而第一次為 200K token 建立五分鐘快取又要再加 $1。

這僅是前綴費用的示意：新輸入、輸出、其他寫入、TTL 到期，以及實際的快取未命中都會增加帳單

實務守則：

• 在 Claude API 上，需透過頂層的 cache_control={"type": "ephemeral"} 或明確的快取斷點來啟用提示詞快取。上面的探測程式兩者都沒用，所以它的快取計數器通常會維持在零
• 把固定的指令與工具放在會變動的使用者請求之前
• 確保各回合間的共享前綴完全一致；並實際檢查 cache_read_input_tokens
• 切換模型時，要視為開啟新的對話預算，而非免費延續。快取是依模型區分的：Opus 的請求無法讀取 Sonnet 剛快取的前綴
• 避免每一回合都更改頂層 effort；這會改變渲染後的提示詞，導致已快取的前綴失效

在支援的模型上，逐則訊息調整 effort 可以保留先前的快取，但這需要使用 Anthropic 的 beta 標頭，而且與更改頂層 output_config 的效果不同。

Sonnet 5.5 還有一個 between_tools 注意事項：在該模式下，effort 無法在對話中途變更。

提示詞快取文件

別因為回應很快就認定是快取命中。請直接讀取 usage 物件，它會分開列出全新輸入、快取建立與快取讀取

兩個 5.5 模型的可快取前綴都至少需要 512 個 token。太短的系統提示詞無法產生上述範例中的節省效果。預設快取存活時間為五分鐘，很適合快速的工具循環。

一小時的寫入成本更高，只有在實際對話經常暫停超過五分鐘窗口時才有意義。在為更長的 TTL 付費前，先測量這些間隔有多頻繁

根據證據升級，而不是根據焦慮

多數團隊都把路由器建反了：先把任務歸類為「困難」，丟給昂貴的模型，然後永遠不知道便宜的路徑其實也能過關

把驗證機制當作路由訊號

11  Sonnet 5.5 · 選定的 effort  → 執行任務
22  驗證機制                    → 通過即接受
33  Opus 5.5 · medium           → 只在有失敗證據時才重試
44  驗證機制                    → 接受，或帶著證據交接出去

驗證可以是測試套件、schema 驗證、已知答案或人工審查。它應該要能說明哪裡失敗了。

「這個答案感覺不太行」是很糟的升級訊號；「改動後的端點沒通過兩項整合測試」才有用

別盲目地重複一模一樣的提示詞。要把失敗的檢查結果、相關產出物，以及針對缺口修正的具體指示交給下一次嘗試。記得為這個升級階梯設上限，以免 Agent 為了修一個需要人類決定的任務而燒光預算

你可以在離線掃描中測試 Sonnet high 的重試效果。只有當它確實降低每個已驗證任務的成本時，才放進正式路線。沒有理由讓每次失敗都得先付兩次 Sonnet 的錢才換 Opus

切換模型本身就可能破壞已快取的前綴。在比較「救援路徑」與「Opus 優先路徑」時，要把這點算進去

交叉點很容易被忽略。假設一次 Sonnet 嘗試花費 $0.06，且能通過你 80% 的任務。

如果每個失敗的任務接著要花 $0.20 在 Opus 上完成，那麼你的示意平均值就是每個完成任務 $0.10：$0.06 加上每五次有一次 $0.20 的救援。這比每個任務都付 $0.20 給 Opus 划算。但如果 Sonnet 要花 $0.14 且只有一半通過率，同樣的階梯成本會變成 $0.24，這還沒算上切換模型的代價。在那種工作量下，Opus 優先反而更便宜也更快

這些數字只是範例，不是實測的 Claude 結果。它們的目的是讓路由規則具備可證偽性。只有當省下來的 Opus 呼叫足以抵銷失敗的 Sonnet 嘗試、快取未命中與增加的延遲時，這個階梯機制才有存在的價值

還有一條中間路線：Anthropic 的 beta 版 advisor tool。Sonnet 可以繼續執行任務，只在遇到困難決策時向 Opus 求助，而不是把整份工作都丟給 Opus。

這不一定比較便宜。請記錄 Sonnet 實際諮詢 advisor 的頻率、這些呼叫的成本，以及它們是否提升了最終的通過率。如果執行者很少發問，advisor 就只是個閒置功能。

在這些 5.5 模型上，建議內容本身會加密回傳給客戶端，因此你應該評估最終產出的成果，而不是假裝自己能審查私密的建議文字

四個在挑選模型前就先墊高帳單的漏洞

不是每個成本問題都需要新的路由器

先檢查這些：

• 不斷膨脹的輸出：在兩個 5.5 模型上，輸出 token 的價格都是全新輸入 token 的五倍。在對話中，冗長的答案還會在後續回合變成上下文再次計費。請要求它產出成品加上一句簡短的完成說明，而不是每一步的旁白紀錄。隱藏的思考過程也會按輸出計費，所以光靠精簡的最終答案無法解決 effort 的問題。但也別為了省錢而刪掉驗證結果所需的證據
• 超出任務需求的圖片：Sonnet 5.5 能處理比舊版 Sonnet 更高解析度的圖片，這可能提高圖片 token 數量。如果 Agent 只需要一個按鈕標籤或一段文字，就先裁切或縮小。如果它需要密集的圖表或細小的 UI 細節，就保留解析度並實際測量成本，而不是盲目壓縮
• 沒人用到的上下文：工具定義、過期的日誌、舊的搜尋結果，以及一份龐雜的 CLAUDE.md，可能會跟著每個請求一起送出。把長期適用的規則放進簡短穩定的前綴裡；暫時性的證據則留在需要它的任務附近。精簡上下文時，別把模型正確完成工作所需的事實也刪掉了
• 為沒人等的工作支付互動式定價：Message Batches API 對兩個模型的輸入與輸出都提供五折優惠。它適合離線評估、文件回填與其他非同步工作。但它無法取代即時工具循環——那種使用者現在就需要下一步的情境

這四點的邏輯都一樣：在花錢買更強的智力，或把 effort 降到品質崩壞之前，先剔除任務不需要的運算

讓省錢計畫變成 400 錯誤的遷移陷阱

舊的請求主體不適合直接拿來跑 5.5 系列。

特別是：

• Opus 5.5 的思考模式永遠開啟：移除 thinking: {"type": "disabled"} 與舊的固定 budget_tokens 設定；改用 output_config.effort 控制深度
• 強制指定工具在兩個 5.5 模型上都會失敗

tool_choice 的值設為 any 或 tool 會回傳 400。請使用 auto，明確指定何時該用該工具，並在自己的程式碼中驗證工具回傳結果

• Thinking 區塊不是 text 區塊：請依 type 讀取內容，而不是用 content[0]。在工具循環中，assistant 回合要原封不動地回傳 thinking 區塊
• 你的 UI 可能會看起來像當機：在 Opus 5.5 上，工具之間的進度可能會出現在 thinking 區塊中，而這些區塊在預設顯示設定下是空的。如果你以前會把這些筆記呈現給使用者，請改用支援的 thinking 顯示模式，並依類型渲染區塊。否則 Agent 可能在努力運作，介面卻看起來像凍結了一樣
• 舊版的 computer-use 工具版本可能會失敗：遷移瀏覽器／電腦 Agent 前，先確認目前的工具版本
• 較小的 max_tokens 上限可能會中斷工作

即使文字被隱藏，思考過程仍計入其中

這些是 API 行為的變更，不是寫提示詞的技巧。

Opus 遷移指南 與 Sonnet 遷移指南

把約定寫進 Claude Code，而不是記在腦海裡

API 是你能量化每個 usage 欄位的地方。而 Claude Code 則是許多人第一次感受到模型差異的地方。原則相同：給 Agent 一個有邊界的完成定義，然後要求它提出證據

在 Claude Code 中，/model 用來選擇模型，/effort 用來選擇支援的 effort 等級。比較不同對話前，先確認目前的設定。Sonnet API 的預設值，並不能可靠地反映你的 Claude 應用程式或 Claude Code 對話目前實際使用的狀態

以下是一個完整且可重複使用的 CLAUDE.md 起始區塊。請依照你的專案修改其中的指令

1# 工作約定
2
3只做要求的變更。不要動到無關的部分。
4編輯後執行相關測試。回報任何你無法執行的檢查。
5當要求的工作通過驗證後就停止。不要自行新增額外功能或審查循環。
6結尾格式：Changed / Verified / Remaining risk。
7執行破壞性操作、發布，或修改此儲存庫以外的內容前，必須先詢問。

這個區塊不會神奇地讓每次執行都變便宜。它只是讓成功與失敗變得可見。有了它，你就能在同一批任務上比較 Sonnet 優先與 Opus 優先的工作流程

任務訊息仍然必須具體。以下是「修復付款程式碼」與 Agent 真正能完成的任務之間的差別

1Change: 將付款端點遷移到新的 client
2Done: 移除舊 client、端點測試通過、diff 僅限於此路徑
3Stop: 刪除資料或修改 repo 以外的內容前須先詢問
4Report: 變更的檔案、實際執行的檢查項目、剩餘風險

這份小小的約定讓驗證機制有具體的東西可查。它也給了模型停手的理由。一句開放式的「審查到完美為止」，可能會把原本能過的修改拖進另一輪付費循環

對於長期專案，把檢查清單放在不會因壓縮而消失的檔案裡。對於 subagent，要求主導的 Agent 在採信報告前先檢查它們的證據。如果你只是想聽聽點子，就告訴 Claude 別動手做。這些是工作流程的界線，不是「變聰明一點」的提示詞

我會先上線的配置

• 挑 10 到 30 個真實任務，並為每個定義檢查方式
• 用 Sonnet 5.5 的 medium 與 high 掃一輪，再用 Opus 5.5 的 medium 掃一輪
• 記錄每個任務的全新輸入、輸出、快取寫入、快取讀取、延遲、重試次數與通過／失敗結果
• 讓穩定的前綴可被快取，並在 usage 中確認確實命中
• 只把失敗的案例往上送，並附上相關證據
• 工作量改變時重新檢視這個階梯。存下來的基準測試不是永恆真理

如果那困難的 10% 總是直接從 Sonnet 失敗跳到 Opus 成功，那就考慮一開始就把這類特徵明顯的任務導向 Opus。如果 Sonnet high 能用更低成本搞定同樣的案例，就讓它們留在那裡。路由器是一套經過測量的策略，而不是對哪個模型比較聰明的永久定見

5.5 的升級不只是「便宜活給 Sonnet，難活給 Opus」

這是一個機會，讓你不再為模型計價，而是為完成的工作計價

如果你看到了這裡

-> 訂閱我的 Substack

-> 加入我的 Telegram

-> 收藏這篇文章

-> 追蹤 @0xwhrrari