針對成本與智慧進行最佳化

當工作負載從原型走向正式環境時，成本便成為首要的設計限制。能力最強的模型在大規模使用時可能過於昂貴，而最便宜的模型則可能在品質上有所不足。妥善管理成本意味著要了解每個成本槓桿如何影響輸出品質，因為有些槓桿會以品質作為交換，有些則不會。Claude Platform 讓您能直接控制這項取捨。您可以為每個請求選擇模型、effort 等級與架構，這讓您幾乎可以將工作負載放在「cost-to-intelligence frontier」（成本與智慧前緣）上的任何位置。

這些槓桿分為兩類：

• 免費的收益可在不影響品質的情況下削減支出：「prompt caching」（提示快取）、token 衛生、針對您正在執行的模型進行提示稽核、對可等待最多 24 小時的工作以五折進行批次處理，以及作為最後防線的工作區支出限制。
• 取捨則以成本換取智慧：模型選擇、effort、輸出上限與任務預算，以及多模型架構。

每個槓桿都附有實測結果以及何時划算的判斷規則。在 Anthropic 的測量中，提示快取是遙遙領先的最大槓桿：在本指南的基準測試中，它將代理迴圈的成本降低了 2.5 到 3.7 倍，並將一個小型分類代理的帳單削減了 83%，若再加上輸入修剪則達 88%。多模型槓桿的適用範圍較窄；第二個模型在兩種形態下划算：顧問（advisor）與協調者（orchestrator）。



從這裡開始

將您的情況對應到某一列。

這些結果為 Anthropic 內部結果（參考的基準測試），僅具方向性而非保證，因此請使用四步驟方法在您自己的工作負載上進行測量。



在不損失品質的情況下削減支出

提示快取、token 衛生、批次處理，以及針對您目前模型的提示稽核，都能在不降低輸出品質的情況下降低您的支出。有兩項但書：批次處理以延遲換取折扣，而 context editing（上下文編輯）這項 token 衛生槓桿，在本節所測量的執行中花費的比節省的還多。



快取重複的上下文

在使用任何其他槓桿之前，先開啟提示快取，因為代理任務的每一回合都會重新傳送整個不斷增長的對話：「system prompt」（系統提示）、工具定義，以及每一個先前的回合。一個 40 回合的任務會將其第一回合傳送 40 次，因此任務成本大致隨回合數的平方增長。快取並不會阻止重新傳送，但每次重新傳送的成本約為十分之一且處理速度更快：前綴以快取讀取費率計費，即輸入價格的十分之一，而每一回合僅對新增的部分支付 1.25 倍的快取寫入費率。

在 Anthropic 所測量的執行中，快取讀取經常是任務成本中最大的單一組成部分，這使得快取的價值高於大多數模型選擇決策。Anthropic 對 WideSearch¹ 與 DeepResearch Bench II⁷ 的執行分別在有快取與無快取的情況下進行了定價：

快取的預設存留時間為 5 分鐘，而代理迴圈的回合之間僅相隔數秒，因此折扣適用於每一回合的大多數 token；圖表中的執行達到了 81% 到 90% 的命中率。節省幅度隨情節深度而異，因為較短的迴圈重新讀取的內容較少，但在所測量的每個模型與基準測試上，快取始終是最大的單一槓桿。

如果您的迴圈在回合之間需要等待人類，請使用 1 小時快取持續時間。它的寫入成本較高（輸入價格的 2 倍而非 1.25 倍），但在第一次避免未命中時就能回本，因為一次未命中會以全價重新傳送整個前綴並再次寫入。

設定所需的工作很少。自動快取會為您放置斷點；否則，Claude Code 隨附的 Claude API skill 可以透過一個提示為現有整合加入快取。以下摘錄顯示該 skill 將快取加入產生這些測量結果的測試框架中：

$ claude
> /claude-api add prompt caching to this integration

Done. Prompt caching is now wired into the harness. Two changes:

- build_system() now adds cache_control: {"type": "ephemeral"} to the
  system block. Since the API renders tools -> system -> messages, this
  one breakpoint caches the entire static prefix -- the full tool array
  plus the system prompt.
- apply_moving_cache_breakpoints() strips any stale markers, then marks
  the last content block of the two most recent user turns. The older
  marker is the read point matching the prefix the previous request
  cached; the newer one extends the cache for the next request.

That's 3 breakpoints total, under the limit of 4.
...

這些斷點的放置遵循明確快取斷點中的標準模式。

有三項設定可能在任務期間破壞您的快取。在請求之間變更 effort 會使已快取的前綴失效，因此只在您本來就會重新快取的地方變更它，例如在壓縮邊界。在中途變更任務預算也會造成同樣的結果，因此請在第一個請求時設定一次即可。每一次 context editing 都會使前綴從其清除點開始失效，而下一個請求需要付費重新快取其後的所有內容，因此請以少數幾個大批次清除，而非許多小批次。請在自然的中斷點進行這三項變更，然後確認快取讀取沒有下降；如果下降了，快取診斷會顯示前綴在何處分歧。



修剪輸入與上下文 token

大多數代理請求都帶有從不影響答案的 token。修剪它們不會損失任何輸出品質，儘管此處並非每個槓桿在測量時都省了錢。有兩個地方值得檢視：

• 輸入修剪。 web fetch 工具中的動態過濾可將樣板內容排除在擷取的頁面之外，圖片調整大小可將視覺輸入調整為適當大小，而具延遲載入的工具搜尋僅在需要時載入工具定義。程式化工具呼叫讓 Claude 從程式碼執行多個工具呼叫，因此只有過濾後的結果會進入上下文；其文件報告在代理搜尋基準測試上輸入 token 減少 24%，且分數更高。管理工具上下文比較了工具搜尋、程式化工具呼叫、提示快取與 context editing。
• 上下文生命週期。 Context editing 會清除過時的工具結果，而自動壓縮及其閾值可防止長迴圈將其整個歷史記錄一路帶下去。

這些槓桿會與快取及彼此互相影響，因此請以淨效果來評斷它們，並使用快取診斷確認您的已快取前綴在每次變更後仍然存在。Anthropic 針對一個處理來自公開儲存庫的 20 份附有螢幕截圖的真實錯誤報告的議題分類代理，逐一開啟這些槓桿（第二個面板則是同一工作的較長變體）：

快取幾乎完成了所有工作，而修剪將總計帶到 88%。每個長條代表一次執行，因此 $0.10 的差異屬於雜訊；此處顯示的差異則不是。壓縮需要足夠長的工作階段才能觸發：20 個議題的執行在其輸入被修剪後從未達到 50,000 token 的下限，但在第二個面板的較長變體中，它觸發了一次並將帳單進一步削減 38%。

Context editing 是此處唯一不免費的槓桿。每一次清除都會重寫已快取的對話，這與提示快取相互抵銷；在這次執行中，context editing 花費的比節省的還多。請將它用於在上下文視窗中騰出空間，並以少數幾個大批次清除。



將可等待的工作批次處理

Batch API 對請求的每個 token（包括已快取的 token）提供五折優惠，代價是結果會在 24 小時內的任何時間送達。將所有沒有人在等待的請求透過批次路由，其餘則保留互動路徑。對於無人值守的代理工作而言，批次處理是僅次於快取的第二大免費槓桿：評估執行、回填，以及排程工作，例如 token 修剪測量中議題分類代理的定期執行。它可與本頁面上除互動性以外的所有內容結合，但不適用於 Claude Managed Agents 工作階段，因為其設計本質上就是互動式的（請參閱 Claude Managed Agents 定價）。



針對目前模型稽核提示

每一代模型對提示的回應方式都不同，因此提示會累積為您不再使用的模型所撰寫的文字。常見的情況是為了彌補較舊模型而加入的過度具體指令：「驗證兩次」、「盡可能徹底」、強制性的逐步程序，或手工打造的推理草稿區。較新的模型會逐字遵循這些指令，產生額外的工具回合與額外的撰寫，因此帳單上升而準確度沒有任何提升。針對您現在執行的模型稽核提示，並在每次更換模型時再次稽核，是一項免費的收益。

稽核只需一個指令。Claude Code 隨附的 Claude API skill 有一個 prompt-audit 指令，可讀取專案的提示與請求程式碼，並報告哪些內容是為不同模型所撰寫的。這段縮短的摘錄顯示它針對包含這些模式的客服台提示與請求程式碼執行的結果：

$ claude
> /claude-api prompt-audit

10 findings. The three that matter most:

1. budget_tokens returns a 400 on Opus 5 (support_agent.py:10). This code
   does not run against its own target model. Everything else here is
   quality; this one is an outage.
2. The prompt contains two live contradictions. Line 15 says confirm before
   every refund, line 17 says process every eligible refund immediately.
   Line 19 asks for a complete recap *and* a three-sentence maximum.
3. The reasoning scaffold and the 6-step script fight the model rather than
   steer it. <scratchpad> + "reason step by step" is now a request
   parameter, not prose; the mandatory 6-step procedure plus "investigate
   fully even when the ticket looks simple" forces four tool calls on a
   "where's my package" ticket.
...
-After any refund or escalation, verify twice before submitting: re-fetch
-the order, re-check every figure in your reply against the fresh lookup,
-and review the reply a second time for errors.
+Before submitting a refund or an escalation, re-fetch the order and confirm
+every figure in your reply matches the fresh lookup.

該指令接著以 diff 形式提出其編輯建議（顯示一個區塊），並列出它刻意保留不動的內容：退款期限、語氣要求與品質標準。您審查的是一個修補檔，而非重寫。

效果是可測量的。在一項客服台評估¹⁴中，為 Claude Opus 4.8 撰寫的提示在 Claude Opus 5 上每張工單的成本高出 36%，而準確度沒有變化。對相同的提示執行稽核後，Opus 5 既比未稽核版本便宜（14%），也更準確（97% 的工單，從 92% 上升，此增益超出雜訊範圍）。在 Claude Sonnet 4.6 到 Claude Sonnet 5 的遷移中，稽核在相同準確度下削減了 14%：

兩種過時文字的代價不同。新模型過於逐字遵循的指令會花錢：移除「驗證兩次」將 Opus 5 每張工單的成本削減了三分之一，移除「盡可能徹底」的效果幾乎相同。不再適合模型的文字則會損失準確度：已淘汰的思考設定、相互矛盾的規則，以及與模型自身思考衝突的手工打造草稿區，在 Opus 5 上移除後各自恢復了 7 到 11 個百分點：

相同的模式也出現在工具描述與 skills 中，同樣值得在那裡移除。



以成本換取智慧

這些槓桿決定單一模型在成本與智慧之間的位置：模型選擇、effort、以較高設定重新執行失敗的任務，以及它運作所依據的預算與上限。請從在您目前模型上進行 effort 掃描開始（調整 effort）。從最低到最高的成本與能力，目前的模型依序為 Claude Haiku 4.5、Claude Sonnet 5、Claude Opus 5 與 Claude Fable 5（前緣模型）；模型概覽有完整的陣容與價格。



以每個任務的成本比較模型

價目表是以每個 token 撰寫的，而以每個 token 來看，前緣模型看起來很昂貴：Claude Fable 5 的每 token 價格是 Claude Sonnet 5 的數倍。然而，您付費的是完成的任務，因此請以每個完成任務的成本比較模型。能力更強的模型以更少的工作完成任務：更少的回合、更少的搜尋、更少地重新讀取自己的上下文，以及更少的回溯。每 token 的溢價經常被「所有事情都做得更少」所抵銷。

Anthropic 在 DeepResearch Bench II⁷ 上直接測量了這一點，這是一個難度足以區分模型的研究報告基準測試：

儘管存在每 token 的差距，low effort 的前緣模型比中階模型更準確，且每個任務便宜約 10%。不過它並非總是獲勝。在本頁面的 SWE-bench Pro³ 子集上（兩個模型大致都已飽和，且其分數無法與公開排行榜比較），單獨的 Claude Opus 5 與單獨的 Claude Fable 5 相當（91.7% 對比 91.3%，在執行間雜訊範圍內），而成本約為其 60%。在更困難的工作上，例如 DeepResearch Bench II 任務，Fable 的優勢會重新出現。

對於大多數代理工作負載，請從 Claude Opus 5 開始：以每 token 計算，它的成本是 Fable 5 的一半、Sonnet 5 的 2.5 倍，而在該程式設計子集上它與 Fable 的準確度相當。在另一端，Claude Haiku 4.5 回答 GPQA Diamond⁹ 問題的每題成本約為 Opus 5 的十分之一，準確度為 63%，而 Opus 為 92%，且在長程式設計任務上落後得更多。它適合具有可檢查輸出的高流量工作，而非長代理迴圈。

排名會因工作負載而翻轉，而沒有任何價目表能告訴您會往哪個方向翻轉。請在您自己的流量上以每個完成任務的成本為每個候選模型定價，包括 Claude Opus 5 與降低 effort 的前緣模型。

為您工作負載的尾端定價，而非中位數：在您最困難的十分之一任務上比較模型，而非典型任務。在典型任務上，每個模型看起來都差不多，最便宜的看起來最好，但帳單是由較便宜模型失敗的任務所決定的，因為失敗的任務仍會對其 token 計費，然後是重試，然後是失敗在下游造成的任何成本。即使沒有任何失敗，尾端也是錢花掉的地方。在一次 20 個問題的 WideSearch¹ 執行中，兩個問題佔了 43% 的支出：

多模型策略的存在，就是為了將前緣智慧花在那個尾端上，而不必為其餘部分支付前緣費率。



調整 effort

Effort 是將模型調整至您任務的最直接方式。effort 參數控制模型進行多少思考、工具呼叫與自我驗證，而預設值（high）適合要求嚴苛的任務。成本隨所有這些活動而擴展；準確度僅隨您任務所需的部分而擴展。在模型的上限以下，最高的 effort 等級是在為任務從未使用的深度付費。

在研究與知識工作基準測試上（WideSearch¹、DeepWideSearch⁶、BrowseComp⁴ 與 GDPval²，全部使用 Claude Fable 5），準確度對成本的曲線幾乎是平的：low 放棄了 1 到 3 個百分點，換取每個任務成本減少三分之一到一半；medium 以預設值 70% 到 85% 的成本達到與預設值相當的準確度；而在這四項中的任何一項上，預設值相較於 medium 都沒有買到任何可測量的東西。在 DeepWideSearch 上，low 也以低 20% 的成本與搭配 Claude Sonnet 5 工作者的協調者相當：降低 effort 勝過了架構變更。

較低的設定也更快，這在延遲是限制條件時很重要。在這些執行中，low 在 DeepWideSearch 上每個問題花費 4.5 分鐘，而預設值為 7.9 分鐘。在語料庫基準測試上（其輸入無法放入任何單一上下文視窗），Fable 5 在 low、medium 與預設值下每個情節分別花費 7.9、9.1 與 11.4 小時。

長時程程式設計是另一種形態。在 SWE-bench Pro³ 上，Claude Opus 5 在 medium 放棄約 2 個百分點換取一半的成本，在 low 放棄約 8 個百分點換取四分之一的成本：這是真正的取捨，而以較高 effort 重新執行失敗的任務可將其轉回為節省。此圖表繪製了研究與知識工作基準測試以及 SWE-bench Pro 的準確度對成本：

由此產生兩個結論。第一，在您加入第二個模型之前，先為您自己的工作負載繪製這條曲線：在這些內部測量中，一個看起來比預設單一模型便宜的多模型配置，其成本高於同一模型在較低 effort 下的成本。第二，這條曲線是任何多模型策略必須擊敗的單一模型基準線，因此在您自己的工作負載上測量的步驟 2 會跨 effort 等級建立基準線。

在達到模型上限的工作負載上，較低的 effort 確實會損失準確度，因為在那裡準確度真正隨推理深度而擴展。在 DeepResearch Bench II⁷ 上，每份報告都獎勵每個子主題的深度推理，每一個 effort 階段都買到約 2.4 分的評分標準分數；在那條曲線上沒有免費的成本削減：

僅憑任務描述無法揭示您擁有哪一種工作負載，因此請在您自己流量的樣本上掃描兩到三個 effort 等級，並從曲線上讀出答案。請在個別的工作階段中測試每個等級：在工作階段中途變更 effort 會使快取失效（請參閱快取重複的上下文）並扭曲比較結果。有關參數詳細資訊，請參閱 Effort。



以較高 effort 重新執行失敗的任務

當任務的結果可檢查時，effort 曲線上最便宜的策略不是固定設定：以低設定執行每個任務，並僅以較高設定重新執行失敗的任務。

Anthropic 根據調整 effort 中 SWE-bench Pro³ 子集上的 effort 執行，逐任務計算了此策略。使用 low 的 Claude Opus 5，16% 的任務失敗；將這些任務以預設值重新執行後，約 93% 通過，每個約 $0.70，相較於全部以預設值執行的 91.7%、$1.39：相同的通過率，一半的成本，且已計入失敗的便宜嘗試。改從 medium 開始則解決了約 94%，每個約 $0.95。小幅提升的大部分來自第二次嘗試（以預設值重新執行預設值自己的失敗任務，分數大致相同，但花費更多），因此請為了節省而使用此策略，而非為了提升：

有兩個條件適用。第一，您需要一個失敗訊號（此處為基準測試自己的測試）；一個會放行不良工作的檢查器會讓這些失敗通過。第二，每個第一輪失敗都需要兩次執行的實際時間，因此節省是以失敗任務上的延遲為代價。



設定預算與輸出上限

大多數代理任務執行都很便宜，但少數會在搜尋、重新驗證與過度測試上花費中位數成本的許多倍。任務預算針對的就是那個尾端。模型會看到整個任務的即時 token 倒數並自我調節，修剪低價值的搜尋、跳過多餘的驗證，並收尾而非陷入螺旋。

Anthropic 在 SWE-bench Pro³ 上使用 Claude Fable 5 測量了隨預算收緊時的通過率與每個任務成本：

寬鬆的預算放棄了約 2.7 個百分點的通過率換取 18% 的成本節省，而允許的最緊預算放棄了 4.4 個百分點換取 47% 的節省。預算在此買到的是效率，而非準確度。

三項控制做三件不同的事。任務預算能省錢，因為模型看得到它。max_tokens 是一個安全上限，不會省下任何東西。在 Claude Managed Agents 上，工作階段預算是兩者背後的硬性金額停止點。請三者都設定：任務預算、高的 max_tokens，以及針對您永遠不想在帳單上看到的執行所設的工作階段上限，並以工作區支出限制作為最終防線。

• 任務預算處於 beta 階段（beta 標頭 task-budgets-2026-03-13），適用於 Claude Opus 5、Claude Fable 5、Claude Opus 4.8 與 Claude Opus 4.7，但不適用於 Claude Sonnet 5；請先查看支援表。從接近您迴圈第 90 百分位數的 token 使用量開始，然後收緊（選擇預算說明如何收集該分佈）。低於目前 20,000 token 下限的預算會被拒絕，而非常緊的預算可能產生類似拒絕的行為。請在第一個請求時設定一次預算，因為任務中途的變更會使快取失效。預算是建議性的，引導模型而非停止它，因此請在您的工作負載上驗證遵循情況。
• max_tokens 限制單一回應，且對模型不可見，因此降低它不會讓模型節約。需要該空間的回合會被丟棄但仍會計費。在一項內部儲存庫任務基準測試¹²上，16,384 token 的上限終止了 Claude Opus 5 15% 的嘗試與 Claude Fable 5 三分之一的嘗試，其中沒有任何一個被解決。受限的執行每次嘗試花費較少，但買到的解決數也成比例減少，因此每個已解決任務的成本與 64,000 時相同。在該設定下沒有任何內容被截斷，而在兩次執行都有評分的問題上，Fable 解決了 54.6% 的任務而非 36.6%（在參考資料 12 所述的 SWE-bench Pro³ 子集的另一個切分上，為 92% 而非 90%）。重試受限的嘗試只會增加成本：在相同上限下它們從未成功，而在較高上限下您還要為浪費的嘗試付費。對於代理工作，請將 max_tokens 設為 64,000（在 xhigh 或 max effort 下設為最大值 128,000），對這麼大的回應使用串流，將 stop_reason: max_tokens 視為失敗，並透過模型看得到的 effort 與任務預算來省錢。
• Claude Managed Agents 上的工作階段預算是硬性停止點。工作階段預算是針對單一工作階段以 token、搜尋與工作階段時間的定價費率計算的金額上限。達到上限時，工作階段會以 stop_reason: budget_reached 暫停；提高預算即可恢復。它由平台強制執行，適用於任何有定價的模型（包括 Claude Sonnet 5），並可與建議性的任務預算結合。部署會將相同的欄位套用至每次執行。

兩張 max_tokens 圖表中的第一張繪製了每個上限下每次嘗試與每個已解決任務的成本：

第二張繪製了每回合輸出長度對照各上限：



組合模型

多模型架構適合任務複雜度變化足夠大、以至於不同步驟最適合由不同模型處理的工作負載。當您的流量混合了較小模型能可靠處理的例行工作與需要前緣能力的較困難步驟時，拆分工作可將前緣智慧保留在重要之處，同時大多數 token 以較小模型的費率計費。當工作負載缺乏這種混合時（因為其難度一致，或它是一條相依的鏈），單一經過良好調整的模型通常是更好的選擇。每個策略章節都提供了區分這兩種情況的規則。

兩種策略涵蓋了大多數工作負載，它們的差異在於哪個模型掌握主迴圈：



顧問策略：將困難決策向上呈報

在「advisor strategy」（顧問策略）中，由成本較低的執行者模型（executor model）運行代理迴圈並執行大多數輪次。當它遇到需要更深入判斷的決策時，例如選擇方法或從失敗中恢復，它會呼叫智慧程度更高的顧問模型（advisor model）以取得策略性指引，然後繼續執行。大多數 token 以執行者的費率計費，只有偶爾的諮詢以顧問的費率計費。

若要使用它，請將顧問工具加入您的請求中。這項 beta 功能在單一 /v1/messages 請求中於伺服器端運行整個策略：執行者發出工具呼叫，Anthropic 運行顧問推論，然後執行者帶著建議繼續執行；您無需撰寫任何編排程式碼。在 Claude Managed Agents 上，可透過在代理的 multiagent 名冊中加入一個 advisor 項目來為工作階段指定顧問；工作階段的主執行緒會以相同方式諮詢它。Claude Code 也支援此功能；請參閱使用顧問工具向上呈報困難決策。

決定回報的因素。 顧問只能透過執行者的呼叫來看到任務，因此有兩件事決定它能提供多少幫助。

第一是模型之間的差距。顧問只能交付執行者所缺乏的能力：在 GPQA Diamond⁹ 上，Claude Haiku 4.5 執行者從 Claude Opus 5 顧問獲益良多，Claude Sonnet 5 執行者獲得了幾個百分點，而前沿執行者幾乎毫無所獲。

第二，也是較脆弱的一項，是執行者是否真的會發問（即「consult rate」（諮詢率））。處於低 effort（努力程度）的執行者可能不再注意到自己卡住了：一個在預設 effort 下對大多數任務都會諮詢的配對，在降低 effort 後可能幾乎完全不諮詢，然後得分低於執行者單獨運行。諮詢率也因任務而異：在 DeepSWE¹⁰ 上，低 effort 的 Sonnet 5 執行者持續發問並獲得了 23 個百分點；在 SWE-bench Pro³ 上，同一個執行者卻停止發問。當執行者確實發問時，它能達成大部分的進展。在下圖的各個配對中，顧問彌補了與較強模型之間 60% 到 90% 的差距，而該較強模型僅在諮詢時才需付費，這使得成本上的優勢成為可能：

諮詢率會對提示做出反應。僅使用工具內建的描述時，執行者會呼叫不足，尤其是在程式設計工作上，因此顧問工具文件提供了一個系統提示，要求在實質工作前呼叫一次、在完成前呼叫一次，每個任務約兩到三次呼叫。接下來測量的程式設計配對即以該節奏運行，每個任務約兩次諮詢。該頁面也涵蓋了如何推動呼叫不足的執行者，以及如何在客戶端限制呼叫次數以控制成本。因此請留意諮詢率：透過提示引導它、測量它，並在它崩跌時恢復執行者的 effort。

何時在成本上划算。 當少數幾次以顧問費率計費的簡短諮詢，取代了以顧問的模型運行整個任務時，顧問就能省錢。當顧問模型的定價遠高於執行者模型時效果最佳，因此最具成本效益的配置是前沿顧問搭配中階執行者。即使在範圍頂端，配對也能站得住腳，因為建議也能節省執行者的 token：被告知正確方法的執行者會探索較少的死路，這可以抵銷諮詢的費用。

在一項內部代理式程式設計基準測試¹¹上，以純 API 代理運行，Claude Opus 5 執行者搭配 Claude Fable 5 顧問是所測量到最準確的配置：每次嘗試 $8.40，解決了 85.7% 的嘗試。它位於穿過各模型自身 effort 設定的曲線之上，但僅比其中最佳者高出一兩個百分點（Opus 單獨在預設設定下為 84.4%、$8.50，Fable 單獨在 medium 下為 83.4%、$8.20），單次運行無法將其與雜訊區分開來。Fable 單獨在 medium effort 下達到與該配對大致相同的準確率（83.4% 對比 85.7%），花費也大致相同（每次嘗試 $8.20 對比 $8.40）：

先前透過 Claude Code 的顧問模式進行的測量產生了相同的排序。請將此結果視為一個可在您的工作負載上測試的形態，而非一項節省：在範圍頂端，顧問以前沿價格換取少許準確率，而成本優勢屬於能力差距較大的配對，例如接下來的圖表閱讀案例。延遲成本就是諮詢本身：在此基準測試上每個任務約多出兩次前沿模型呼叫，每次都位於任務的關鍵路徑上。

何時比提高 effort 更划算。 在能力差距較大且工作負載的準確率會隨 effort 變化的情況下，一個會諮詢顧問的低 effort 執行者，可能是比提高執行者自身 effort 更便宜的升級方式，因為顧問僅在需要它的任務上才需付費。

在 Chartography¹³（一項公開的圖表閱讀基準測試，於 Claude Managed Agents 上搭配其顧問運行）上，low effort 的 Claude Opus 5 執行者搭配 Claude Fable 5 顧問，以每個任務 $0.60 得分 67.5。這高於穿過任一模型自身 effort 設定的曲線（Opus 單獨在 low 與 medium 之間從 49 升至 75，花費 $0.38 至 $0.94），儘管執行者自身的 medium 與預設設定仍保有最高分，價格分別為 1.6 倍與 3.3 倍：

低 effort 執行者在 86% 的任務上諮詢了顧問，這正是 SWE-bench Pro 配對未能滿足的條件。在依賴此配置之前，請先在您的代理迴圈中測量諮詢率。

無論是哪種配對，請先計算顧問的模型單獨在低 effort 下的價格；那是要超越的基準線。每次模型發布時都要重新檢查，因為新版本會同時改變能力差距與價格比率。

何時適用。 顧問策略適合輪次大多是機械性的、但優秀的計畫至關重要的工作負載：程式設計代理、電腦使用，以及多步驟研究管線。當每個輪次都真正需要前沿能力、當沒有什麼可規劃的（單輪問答），或當您的執行者已經接近顧問的能力時，它就不太適合。



協調者策略：委派大量工作

在「orchestrator strategy」（協調者策略）中，由前沿模型掌握迴圈。它分解任務、將子任務分派給成本較低的工作者模型（worker model），並合併它們的結果。協調者自身的對話記錄保持簡短，因為工作者吸收了 token 密集的探索工作，因此大多數 token 以工作者費率計費，而計畫與綜合仍來自前沿模型。

若要建構一個，請使用 Claude Managed Agents 中的多代理編排：配置一個協調代理（即協調者）以及一份工作者代理名冊，每個代理各有自己的模型。如需一個以 Claude Fable 5 協調者搭配 Claude Sonnet 5 工作者的完整可運行範例，請參閱 Claude Cookbook 食譜協調者模式：大模型負責規劃，小模型負責執行。

當工作者可以平行運行時，此模式可節省實際耗時：在語料庫基準測試⁸上，協調者以平台文件記載的 25 個並行工作者上限運行時，一個回合花費略多於 2 小時，相較於單獨運行的 11.4 小時。它僅在兩種測量到的情況下省錢。在單一模型可以獨自處理的工作上，同一模型在較低 effort 下每次都更便宜。

案例 1：為例行工作的成本長尾投保。 單獨運行的前沿模型偶爾會在它通常能解決的例行問題上陷入失控。由於您無法事先判斷會是哪些問題，少數幾次這樣的運行就主導了帳單。將例行工作交給成本較低的工作者的協調者可以限制該長尾，因為任何失控現在都以工作者費率發生。

Anthropic 在 BrowseComp⁴ 的一個刻意挑選的簡單切片上測量了這一點（10 個單獨模型能可靠解決的問題；50 次委派運行與 70 次單獨運行）。Claude Fable 5 協調者搭配一個 Claude Sonnet 5 工作者，平均成本略低於 Fable 單獨運行的一半，在第 90 百分位數約為三分之一（$12 對比 $33），而單獨模型最昂貴的單次運行花費 $84，且答案還是錯的：

委派在例行、通常可解決的那部分工作上划算，這與「工作者是用來處理困難問題」的直覺相反。在完整、更困難的 BrowseComp 集合上，經濟效益反轉了。如果您的流量在例行任務上有很長的成本長尾，這是應該首先測量的協調者案例。

案例 2：大於一個上下文視窗的工作。 單獨模型必須以序列方式處理如此龐大的輸入，一次一個「context window」（上下文視窗），每次都要付費重新讀取自己的狀態。工作者各自讀取自己的分區，平行進行且以工作者費率計費。仍能放入一個上下文視窗的閱讀密集型工作是模型選擇問題，而非委派問題：僅就閱讀成本而言，只有當沒有任何單一上下文能容納該工作時，協調者才會勝出。

Anthropic 為此案例建構了一項基準測試⁸：一個由 14 個公開 Python 套件組成、含 2,160 萬 token 的語料庫，其中植入了 130 個缺陷，大到任何上下文視窗都無法容納。降低 effort 無濟於事，因為帳單就是語料庫讀取本身：Claude Fable 5 單獨運行在每個 effort 設定下每回合花費 $720 至 $764，只有其準確率有所變動。協調者配置的成本比上述任何設定都低 60% 以上，得分比 medium 或預設下的 Fable 低 2 到 6 個百分點，同時徹底擊敗了 Claude Sonnet 5 單獨運行的基準線：

token 帳目說明了原因。兩份帳單大多是從快取提供的語料庫讀取：協調者配置每回合讀取約 5.7 億個快取 token，幾乎是單獨模型約 2 億個的三倍，但成本仍不到一半，因為其讀取是以 Claude Sonnet 5 的快取讀取費率而非 Claude Fable 5 的費率計費。預設 effort 下的 Fable 5 仍保有最高準確率，成本為協調者配置的 2.8 倍，因此這裡的委派買到的是大部分的準確率，而非全部。

何時委派不划算。 只有當有大量工作可以交出去時，協調者才能買到東西：許多獨立的片段，理想情況下多到一個上下文視窗放不下。當工作是一條相依的鏈，或能放入單一上下文時，協調者要為計畫、交接與合併付費，而單一模型則免費獲得這些。在每個測量到的此類案例中，協調者的模型單獨在較低 effort 下都勝出。

BrowseComp⁴ 在單一基準測試內展示了這條界線。委派在例行切片上划算，而在完整、更困難的集合上落敗，在後者中前沿模型單獨運行以低 22% 至 30% 的成本達到了協調者配置的準確率。獨立的外部研究報告了相同的模式⁵。如果工作是一條鏈、能放入一個上下文且沒有很長的成本長尾，或者單一模型在較低 effort 下已經達到您的標準，就不要建構協調者。



在兩種策略之間做選擇

大多數情況歸結為一個問題：工作是否能拆分為獨立的片段，還是它是透過一連串相依步驟得出的單一答案？策略表將這兩種答案對應到兩種策略。

如果您不確定，先不要建構任何東西：

1. 先在您目前的模型上掃描 effort。這是本頁最便宜的實驗，而大多數工作負載到此為止。
2. 如果掃描顯示出差距，請計算較強模型單獨在低 effort 下的價格。那是顧問配對必須超越的數字，而本頁中超越它的配對，都是其執行者確實有進行諮詢的配對。

本頁的多模型結果是與同一模型在較低 effort 下、以及與下一級模型單獨運行進行比較評判的。那是您應在自己的工作負載上進行的比較，也是為什麼第一步是 effort 掃描。

當您確實要加入顧問時，它只是一個工具定義，而非重新架構。



在您自己的工作負載上測量

本頁的數字來自 2026 年 7 月與 8 月，採用當時的定價，並會隨著模型與價格的變化而漂移。您的向上呈報率、任務拆分的乾淨程度，以及對話記錄長度也會影響它們。方法保持不變：

1. 從生產日誌中抽取一些任務，按真實流量加權，並為每個任務撰寫結果檢查：測試通過、工單關閉、列數正確。在分數旁記錄每個任務的成本：將每個回應的 usage 中的四個 token 計數按各自的費率計價，並在該任務的所有請求中加總（Usage and Cost API 會報告彙總值）。
2. 在各個 effort 等級（而非僅預設值）上為各模型層級建立基準線，並繪製分數對支出的圖。多模型配置必須擊敗單一模型的整條曲線。
3. 如果曲線顯示出 effort 無法彌補的差距，加入適合的多模型策略並重新運行測試套件。
4. 在切換之前，先在一部分流量上以影子模式運行勝出者，然後持續運行測試套件。

以下範例以 Claude Opus 5 的定價計算一個請求在步驟 1 中的成本：

# 取自定價頁面的每百萬 token 價格；若使用其他模型，請修改這兩個值。
INPUT_PER_MTOK = 5.00  # Claude Opus 5
OUTPUT_PER_MTOK = 25.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # 快取寫入以輸入價格的 1.25 倍計費（5 分鐘快取）；快取讀取為 0.1 倍。
    + (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

在代理迴圈中，快取讀取項通常是四項中最大的；如果不是，請檢查快取是否已啟用。當啟用顧問工具或壓縮時，某些 token 僅在 usage.iterations 中報告，而不在頂層總計中，因此請改為對 usage.iterations 加總，並將 advisor_message 項目按顧問模型的費率計價。

下表按嘗試順序列出各項手段：



引用的基準測試

所有測量均為 Anthropic 內部對這些基準測試的運行。除非另有說明，成本為 2026 年 8 月定價的美元；Claude Sonnet 5 的數字採用每百萬輸入與輸出 token $2 與 $10。標示為「notional USD」（名義美元）的圖表是將每個請求的 token 計數按這些費率計價，而非報告發票金額。

1. WideSearch： Wong et al., "WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025。廣泛的網路研究任務，依多列表格的完整性與準確性評分；200 個問題，每個配置 3 次運行。快取與 effort 圖表來自不同的運行，因此每個問題的成本略有差異。成本集中度圖表是另一次 20 個問題的運行，每個問題 3 次運行，依每個請求的計費記錄計算成本。
2. GDPval： OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025。依任務評分標準評分的知識工作交付成果；對已發布的黃金集進行 210 個任務的運行，每個任務一次嘗試。由 Claude 模型評分，因此絕對分數可能與已發表的結果不同。
3. SWE-bench Pro： Scale AI, "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025。為與 Anthropic 的評估框架相容而挑選的 482 個問題子集；分數無法與公開排行榜比較。預設 effort 下的 Claude Opus 5 為兩次運行的平均；降低 effort 的設定為單次運行。向上呈報數字逐任務取自這些運行：先 low，再對其失敗項使用預設，在各運行配對中解決了 92.5% 至 93.6%，約 $0.70；先 medium，93.8% 至 94.2%，約 $0.95；預設對其自身失敗項重新運行，94.0%，$1.58；全部使用預設，90.9% 至 92.5%，$1.39。顧問圖表上的 Claude Sonnet 5 執行者配對來自 2026 年 8 月在此子集上的同一系列：Sonnet 加 Opus 配對運行了兩次（一次運行與一次精確複製），低 effort 配對運行一次；任務預算數字為同一子集上每個預算一次運行。比較模型中的 Claude Fable 5 數字為 2026 年 7 月的單次運行，也是任務預算圖表的無預算基準線；每次有預算的運行都完成了全部 482 個問題，沒有框架錯誤。
4. BrowseComp： Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025。effort 數字使用 500 個問題的切分，每個設定一至三次運行。成本保險圖表使用來自 26 個問題切片中 10 個可靠解決的問題，50 次委派運行與 70 次單獨運行（期望值每次運行 $6.45 對比 $11.99）；委派數字帶有約 20% 的測量區間。
5. 代理架構擴展： Kim et al., "Towards a Science of Scaling Agent Systems," arXiv:2512.08296, 2025。獨立的外部研究，僅引用其關於委派何時不划算的發現方向，不引用任何數字。
6. DeepWideSearch： "DeepWideSearch: Benchmarking Depth and Width in Agentic Information Seeking," arXiv:2510.20168, 2025。220 個問題橫跨 15 個領域，每個問題結合多列收集與多跳檢索；在基準測試的常設列集上測量，每個配置 3 次運行。
7. DeepResearch Bench II： Li et al., "DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026。其橫跨 22 個領域的 132 個研究任務依專家衍生的二元評分標準評分；在橫跨所有主題分層的 50 個任務子集上測量，每個任務一次嘗試，3 次運行，在沒有任何配置拒絕的任務上評分。Claude Opus 4.6 依基準測試的評分標準協定進行評判；原始版本使用不同的評判者，而 Anthropic 的評判者可能偏好自家風格。這些運行早於 Claude Opus 5，因此它未出現在比較模型圖表中。Sonnet 5 的成本在快取圖表（推論成本，有與無快取）與該圖表（全包成本，快取開啟）之間略有差異；兩者來自相同的運行。
8. 語料庫缺陷掃描： Anthropic 內部，針對大於一個上下文視窗的工作：來自 14 個公開 Python 套件原始碼的 2,160 萬 token 語料庫，植入 130 個缺陷並採用確定性評分；協定在運行前固定並經內部審查；每個配置三次運行。每個配置都在 Claude Managed Agents 上運行。圖表中的團隊配置為 2026 年 8 月的運行，其中 Claude Fable 5 協調者在平台內以其文件記載的 25 個並行 Claude Sonnet 5 工作者上限運行整個掃描；其三個回合的 F1 得分為 0.842、0.805 與 0.810，花費 $263、$299 與 $261。單獨配置為 2026 年 7 月在同一語料庫版本上的運行。絕對 F1 特定於此語料庫版本，無法跨基準測試比較；配置之間的比較為同類比較。
9. GPQA Diamond： Rein et al., "GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023。198 個問題的 Diamond 子集，2026 年 8 月測量，每個配置兩次運行，依參考答案由模型評分，顧問 token 按每個請求計量。平台安全檢查在 Sonnet 與 Opus 執行者上拒絕了兩個生物學問題；排除它們不會使任何比較改變超過一個百分點。
10. DeepSWE： Datacurve, "DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026。2026 年 8 月測量：橫跨五種語言的 113 個原創任務，採用基於程式的驗證器。配對各為兩次運行，顧問 token 按每個請求計量，並使用客戶端顧問迴圈而非顧問工具，帳目計算方式相同。單一模型 effort 掃描為依 token 計數計價的單次運行，是一種考量快取的近似值。每個任務的成本為運行總計除以 113。
11. 內部代理式程式設計基準測試： Anthropic 內部：370 個儲存庫任務，依儲存庫自身的測試評分。API 數字（Opus 5 單獨、Fable 5 單獨，以及配對）於 2026 年 8 月在預設 effort 下以 128,000 token 輸出上限測量，每個配置一次運行：預設設定與配對為每個任務五次嘗試，low 與 medium 為一次；配對平均每次嘗試約兩次顧問諮詢；成本為每次嘗試。Claude Code 數字為 2026 年 7 月對相同任務的運行，每個配置一次運行，成本為近似值。
12. 內部儲存庫任務基準測試（上限測量）： 另一組 Anthropic 內部約 130 個儲存庫任務，2026 年 8 月以純 API 代理迴圈運行，每個任務一次嘗試。16,384 token 的數字為每個模型兩次運行的平均；64,000 token 的數字為單次運行（Opus 5 評分 124 個任務；Claude Fable 5 評分 108 個，環境在模型運行前跳過了其餘任務）。約一半被 16,384 上限終止的 Fable 嘗試在 64,000 下已解決；另一次 128,000 的 Fable 運行得分 56.1%，與 64,000 運行的差異在雜訊範圍內。SWE-bench Pro 上限數字為每個上限一次 Claude Fable 5 運行，在預設 effort 下於從參考文獻 3 的 482 個問題集分層抽出的 100 個問題子集上進行，無法與其分數比較。圖表的每輪分布來自 64,000 的 Opus 運行與 128,000 的 Fable 運行，因此兩者都未被自身的上限截斷。
13. Chartography： Surge AI, "Chartography," 2026。完整發布的 100 個問題集，2026 年 8 月以 Anthropic 在 Claude Managed Agents 上的實作測量（標準雲端沙箱；顧問配置使用 Managed Agents 顧問）。由 Claude Sonnet 4.6 而非參考評判者評分，且基準測試搭配工具運行，因此分數可在此處的配置之間比較，但無法與已發表的排行榜比較。每個配置兩次運行，合併計算；運行間的差距為 4 至 10 個百分點。成本不含沙箱時間，其增加不到 1%。諮詢率比較來自在 Messages API 上以容器工具集重新運行相同配置。
14. 支援服務台提示稽核評估： Anthropic 建構的 44 張支援工單集，採用確定性評分，2026 年 8 月在六個系統提示下運行，每個系統提示在同一個乾淨提示上加入一種在為 Claude Opus 4.8 與 Claude Sonnet 4.6 撰寫的提示中常見的模式。每個圖表點為三種情況之一（較舊模型、較新模型使用相同提示、較新模型經稽核後），對六個提示與 44 張工單取平均。Opus 5 的準確率增益有 3 至 8 個百分點的 95% 信賴區間；Sonnet 的準確率差異在雜訊範圍內。



後續步驟