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

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

成本與智慧通常被描繪成一條前緣，其中一方可以換取另一方。本頁的第一組槓桿透過在不影響品質的情況下削減成本，將工作負載推向該前緣；只有第二組槓桿會沿著前緣移動：

槓桿分為兩類：

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

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

從這裡開始

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

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

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

提示快取、token 衛生、批次處理，以及針對您目前模型的提示稽核，都能在不降低輸出品質的情況下降低您的支出。有兩點需要注意：批次處理以延遲換取折扣，而上下文編輯（一種 token 衛生槓桿）在本節測量的執行中花費超過其節省。

快取重複的上下文

為何快取優先

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

**良好狀態的樣貌。**在一整天的真實流量中，代理迴圈從快取讀取的輸入中位數為 84%，而前 10% 的「harness」（執行框架），無論是否為程式碼類，讀取 94% 或更多¹⁷。在任務深處，建構良好的迴圈只需為不到 1% 的輸入支付全價。低於約 80% 時，請尋找破壞快取的因素（請參閱什麼會破壞快取）。

在 Anthropic 的實測執行中，快取讀取通常是任務成本中最大的單一組成部分，使快取的價值超過大多數模型選擇決策。Anthropic 對 DeepResearch Bench II⁷ 的執行分別在有快取與無快取的情況下定價：

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

選擇快取時長

如果您的迴圈在輪次之間等待某人，請使用 1 小時快取時長。它的寫入成本較高（輸入價格的 2 倍而非 1.25 倍）。任一時長的未命中都會以寫入價格而非讀取價格對整個前綴計費，因此一旦每個工作階段有幾個輪次是在 5 分鐘到一小時的暫停之後，較長的時長便划算。

要做決定，請計算對話中連續請求之間的間隔：

• 大約每 20 個間隔中有超過 1 個落在 5 分鐘到一小時之間，且超過一小時的間隔很少見：使用 1 小時時長。
• 輪次間隔數秒到達：維持 5 分鐘預設值。當沒有任何暫停時，它在 Claude Sonnet 5 上比 1 小時設定便宜 15%，在 Claude Opus 5 上便宜 11%。
• 超過一小時的間隔很常見：維持預設值。超過一小時的間隔會使兩種時長都過期，而 1 小時設定隨後會以其較高的寫入價格重新寫入前綴，因此在每個這樣的間隔上都會吃虧。在您超過 5 分鐘的暫停中，如果約 60% 或更多也超過一小時，請維持預設值；只有當至少約 40% 的長暫停在一小時內結束時，1 小時時長才划算。

Anthropic 測量了修剪輸入與上下文 token中的分類工作，在某些輪次之前插入暫停以模擬人的延遲¹⁶。在所測量的兩個模型上，一旦大約每 30 個輪次中有 1 個是在暫停之後，1 小時快取便成為較便宜的設定，因此 1/20 規則留有餘裕，且超過交叉點後差距迅速擴大，因為在 5 分鐘設定下每個暫停後的輪次都會重新寫入整個前綴。每個目前的模型都使用相同的快取寫入倍數，且除 Claude Fable 5.1 與 Claude Mythos 5.1 之外的每個模型都使用相同的讀取價格，因此其他模型的交叉點落在相同範圍內；Fable 5.1 是接下來要討論的情況。每個儲存格中的準確度都維持在執行間雜訊範圍內。在 1 小時設定下，暫停後的輪次保持其溫快取延遲。下圖繪製了 Claude Sonnet 5 上每個工作階段成本與暫停輪次比例的關係：

Anthropic 也測量了保持 5 分鐘快取溫熱的額外請求。在 Claude Sonnet 5 與 Claude Opus 5 上，無論暫停輪次比例為何，它們相較於 1 小時時長都沒有可測量的節省，且在每個輪次前都有暫停時成本更高，因此請改用時長設定。

在 Claude Fable 5.1 上，最便宜的設定則不同。其快取讀取成本為輸入價格的 0.025 倍（每百萬 token $0.25），而其快取寫入維持標準倍數，因此重新讀取前綴的「keep-alive」（保活）請求很便宜，而 1 小時時長的寫入溢價才是較大的帳單。Anthropic 以相同的三種設定在 Claude Fable 5.1 上測量了分類工作¹⁹。只要暫停為數分鐘，保持 5 分鐘快取溫熱的每個工作階段成本比 1 小時快取低 13% 到 20%；只有在暫停接近 45 分鐘時，1 小時快取才勝出，每個工作階段約 12 美分。在 Claude Fable 5.1 上，當某人離開數分鐘時保持 5 分鐘快取溫熱，當暫停接近一小時時購買 1 小時時長：

要保持快取溫熱，請在前一個請求開始後的 4 分鐘內再次傳送前一個請求，並將 max_tokens 設為 0，之後每 4 分鐘一次，若設定了 stream 則將其移除。從請求的開始計時，而非其回應的結束：快取的 5 分鐘存留時間從寫入或重新整理該項目的請求開始時起算，因此回應花在生成上的時間會計入其中。這就是預熱請求：它重新整理快取的存留時間、不生成任何內容，且只計費快取讀取。不要更改前綴的任何一個位元組，也不要使用 max_tokens: 1，那會無謂地取樣一個 token。請重新傳送請求的標頭以及其主體：如果您的請求帶有 anthropic-beta 標頭（例如用於任務預算），保活請求需要相同的標頭，否則重播主體中受 beta 管控的欄位會被拒絕。當請求設定了 thinking.type: "enabled"（Claude Fable 5.1 上預設的自適應思考沒問題）、結構化輸出或強制工具選擇時，max_tokens: 0 請求會被拒絕（其限制）；在這些工作負載上，請改為購買 1 小時時長。

# 在上一個請求開始後的 4 分鐘內（生成所花費的時間會計入
# 快取的存續期間），重新傳送該請求並將 max_tokens 設為
# 0，並移除 stream（max_tokens: 0 的請求無法串流）。傳送與
# 原始請求相同的標頭，包括任何 anthropic-beta 標頭。
jq '.max_tokens = 0 | del(.stream)' last_request.json | \
  curl https://api.anthropic.com/v1/messages \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    --data-binary @-

開啟快取

設定幾乎不費工夫。自動快取會為您放置斷點；否則，隨 Claude Code 提供的 Claude API skill 可以透過一個提示為現有整合加入快取。以下摘錄顯示該 skill 將其加入產生這些測量結果的 harness：

$ 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.
...

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

什麼會破壞快取

在任務期間有幾件事可能破壞您的快取。任何每個請求都會變動的內容（例如時間戳記或佇列位置）若放在穩定前綴之前，會使每個請求都變成完整的快取寫入：在修剪輸入與上下文 token的分類執行中，系統提示開頭的一行 25 個 token 的狀態列使每次執行花費 $4.24 而非 $0.59，比關閉快取執行還多。請將每個請求變動的文字放在最新的使用者輪次中。

快取是對請求依序（工具、然後系統提示、然後訊息）進行位元組精確的前綴比對，因此任何位置的變更都會使其後的所有內容失效。在請求之間變更 effort 或思考設定會使快取從該點起失效，在某些模型上連其前面的工具與系統提示也會失效；對系統提示的任何編輯會使快取從該點起失效；設定或變更輸出格式會使整個對話的快取失效；新增、移除或重新排序工具定義會使全部失效。提示快取頁面列出了這些情況，輸出格式除外，該情況由結構化輸出涵蓋。在最新的模型上，請使用對話中途系統訊息（附加到 messages 的 {"role": "system"} 訊息）來變更指令，而非編輯頂層 system 欄位：快取的前綴保持完整。請查看該頁面以了解哪些模型支援。在支援的模型上，逐訊息 effort 變更也會讓快取前綴保持完整。在 Claude Fable 5.1 與 Claude Mythos 5.1 上風險最高：一次破壞會以輸入價格的 1.25 倍重新寫入前綴，而非以 0.025 倍讀取，因此在 100,000 token 的前綴上，一個被破壞的輪次花費 $1.25 而非 $0.03，是讀取的 50 倍，相較之下在 Claude Opus 5 上為 12.5 倍（$0.63 而非 $0.05）。

Anthropic 在分類代理的長工作階段上測量了這一點¹⁸。在工作階段中途進行的 effort 變更與新增工具分別重寫了 39,000 與 60,000 個快取 token，這些工作階段每個花費 $0.95。相同的兩項變更若在壓縮後的第一個請求上進行則花費 $0.75，若在觸發壓縮的請求上進行則花費 $0.92，因為壓縮的摘要過程隨後以快取寫入價格重新處理了 81,000 token 的上下文：該摘要過程花費 $0.21，相較之下當相同變更晚一個請求進行時為 $0.04，每個組別的準確度都在執行間雜訊範圍內：

中途變更任務預算會使任何包含預算值的快取前綴失效，因此請在第一個請求上設定一次。每次上下文編輯都會使前綴從其清除的點起失效，而下一個請求需付費重新快取其後的所有內容，因此請以少數大批次而非許多小批次進行清除。在 Claude Fable 5.1 與 Claude Mythos 5.1 上，這些每個 token 的成本都是讀取價格的 50 倍，因此在那裡最為重要。請在自然斷點進行每項會使快取失效的變更，然後確認快取讀取沒有下降；如果下降了，快取診斷會顯示前綴在何處分歧。

修剪輸入與上下文 token

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

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

這些槓桿與快取及彼此之間會互相影響，因此請以淨效果來評判它們，並使用快取診斷確認您的快取前綴在每次變更後仍然存在。Anthropic 在一個問題分類代理上測量了它們，該代理處理來自公開儲存庫的 20 份附有螢幕截圖的真實錯誤報告，以及同一工作的較長變體（token 數為 2.6 倍）。在開啟快取的情況下，輸入修剪（圖片調整大小與工具搜尋）在短執行上再削減 26%，在長執行上削減 21%。

延遲未使用的工具定義

附加到請求的每個工具定義在每個輪次都是輸入，而幾個 MCP 伺服器加起來就有數百個。Anthropic 以分類代理自己的兩個工具加上來自公開 MCP 伺服器的真實工具定義目錄（總計最多 502 個工具）執行該代理，全部載入或將額外的工具標記為 defer_loading 置於工具搜尋之後：

在每個定義都載入的情況下，隨著目錄增長，執行成本幾乎翻倍，與每個請求上的 schema token 同步。使用工具搜尋時，在每個目錄大小下都保持平穩，在 502 個工具時少 45%。無論哪種方式，每個儲存格的準確度都是 20 個中的 15 到 18 個，且模型從未呼叫錯誤的工具，因此在此規模下目錄耗費的是金錢而非正確性。透過 MCP 連接器提供的工具也是如此：附加公開 GitHub MCP 伺服器時，延遲其工具集（default_config: {defer_loading: true}）在相同準確度下將執行成本削減 20%。

將資料檔案排除在提示之外

當模型必須對表格進行計算時，請使用 Files API 上傳它，並讓模型以程式碼執行查詢它，而非將其貼入。Anthropic 對一份 1,862 列的公開 CSV 提出了 25 個彙總問題¹⁵（加總、過濾計數、分組，以及一個日期過濾），答案由 pandas 計算：

貼入提示時，該表格在每個請求上約為 91,000 個輸入 token，而 Claude Sonnet 5 正確回答了 25 題中的 6 題。上傳並使用程式碼執行時，它回答了全部 25 題，且執行成本約為十二分之一。Claude Opus 5 顯示相同的模式。

管理上下文生命週期

上下文槓桿只在工作階段長到需要它們時才划算：

在 20 個問題的執行上它們沒有任何節省，而上下文編輯多花了 74%。在長執行上，修剪節省了 39%，壓縮節省了 32%，而上下文編輯沒有改變任何東西。修剪是您自己撰寫的幾行程式碼：在每個任務邊界，將大型過時的工具結果替換為一行摘錄。它的快取效果良好，因為編輯位於對話的尾端，下一個任務無論如何都會在那裡新增內容：邊界後第一個請求的快取讀取為 89%，邊界之間的請求為 81%。就整個執行而言，修剪與上下文編輯的快取效果大致相同。修剪較便宜，是因為上下文編輯會在任務中途重寫修剪所刪除的內容（約佔差距的三分之二），也因為它使上下文保持約一半大小（另外三分之一）。如果您使用上下文編輯，請以少數大批次清除。改編自 harness 的修剪程式碼：

import re

PRUNED = "[pruned at issue boundary]"


def prune_task_boundary(messages, tool_name_by_id, threshold=2000):
    """Call once per task boundary. Replaces large, stale search results with a one-line extract."""
    for message in messages:
        if message["role"] != "user" or not isinstance(message["content"], list):
            continue
        for block in message["content"]:
            if not (isinstance(block, dict) and block.get("type") == "tool_result"):
                continue
            if tool_name_by_id.get(block.get("tool_use_id")) != "search_issues":
                continue
            result_text = block.get("content")
            if not isinstance(result_text, str) or len(result_text) <= threshold:
                continue
            if result_text.startswith(PRUNED):
                continue  # already pruned on an earlier boundary
            # 限制單行結果的長度，讓擷取內容保持簡短
            first_line = result_text.split("\n", 1)[0].strip()[:200]
            refs = re.findall(r"#(\d+)", result_text)[:5]
            extract = f"{PRUNED} {first_line}"
            if refs:
                extract += " kept refs: " + " ".join("#" + r for r in refs)
            block["content"] = extract

批次處理可以等待的工作

Batch API 對請求的每個 token（包括快取的 token）提供 50% 折扣，代價是結果會在 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 個百分點：

相同的模式往往也出現在工具描述與 skill 中，這些也值得稽核。

以成本換取智慧

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

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

價格表是以每個 token 撰寫的，而以每個 token 來看，前緣模型看起來很昂貴：Claude Fable 5.1 的每 token 價格是 Claude Sonnet 5 的數倍。然而您支付的是完成的任務，因此請以每個完成任務的成本比較模型。能力更強的模型以更少的工作完成任務：更少的輪次、更少的搜尋、更少重新讀取自己的上下文，以及更少的回溯。每 token 的溢價往往被各方面都做得更少所抵銷。

Anthropic 在 SWE-bench Pro³ 子集上測量了這一點，依客戶計費方式定價：

Claude Fable 5.1 在 low effort 下解決了 88.6% 的任務，每個已解決任務 $0.54，相較之下 Claude Sonnet 5 在其預設值下為 77.4%、$0.84：多 11 個百分點且每個已解決任務少 35%，儘管每 token 價格高出五倍。不過它並非總是勝出。在同一子集上（兩個模型大致都已飽和，且其分數與公開排行榜不可比較），單獨的 Claude Opus 5 在預設值下與單獨的 Claude Fable 5.1 相當（91.7% 對 92.1%，在執行間雜訊範圍內），每個已解決任務約少 15%（$1.01 對 $1.19），而 Opus 5 在 low 下以 $0.25 解決了 84.0%。而在長研究迴圈上，前緣模型做的工作更多而非更少：在 DeepResearch Bench II⁷ 上，Fable 5.1 在 low 下的分數比 Sonnet 5 高 10 個百分點（66% 對 56%），每個任務成本約為四倍（$4.66 對 $1.20），因為它在更大的上下文上執行更長的研究迴圈。Claude Opus 5 在其預設值下以相同基準得分 71%，每個任務 $6.71，高於 Fable 5.1 在其預設值下（65%、$7.12），因此在研究上 Fable 5.1 也只有在 low 下才值得其價格。

對於大多數代理工作負載，從 Claude Fable 5.1 在 low effort 開始，並在其失誤處提高 effort。以每 token 計，它在未快取輸入上的成本是 Claude Opus 5 的兩倍，但在快取輸入上只有一半（每百萬 $0.25 對 $0.50），而在代理迴圈中快取輸入是最大的項目。在顧問策略中的程式碼基準測試上，Fable 5.1 在 medium 下與 Opus 5 在其預設值下相當，每次嘗試成本約為三分之一（$2.91 對 $8.50）。在 Chartography¹³（一項圖表閱讀基準測試）上，Fable 5.1 在 low 下得分 62.5，每張圖表 $0.15，相較之下 Opus 5 在 low 下為 49、$0.38。在 SWE-bench Pro 子集上，如前所述，Claude Opus 5 在其預設值下仍是達到最高分的較便宜方式。在另一端，Claude Haiku 4.5 以約 Opus 5 每題成本的十分之一回答 GPQA Diamond⁹ 問題，準確度為 63%，相較之下 Opus 為 92%，且在長程式碼任務上落後更多。它適合具有可檢查輸出的高量工作，而非長代理迴圈。

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

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

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

升級模型

如果您落後一兩個模型，最便宜的槓桿就是模型字串。Anthropic 在 SWE-bench Pro³ 子集上以相同的 harness 執行了近期的 Claude Opus、Claude Sonnet 與 Claude Fable 模型，每個都以其出廠預設值並依定價表費率定價，並在 Terminal-Bench 3²⁰ 上再次執行 Opus 系列：

Anthropic 對 Opus 系列各版本的每 token 定價相同，因此任何差異都來自每個模型每個任務做了多少工作：依客戶計費方式定價，Claude Opus 4.8 解決與 Claude Opus 4.7 相同比例的任務，每個已解決任務少 14%，而 Claude Opus 5 隨後多解決 12 個百分點的任務，每個已解決任務多 21%。Claude Opus 5 在 low effort 下在此基準測試上勝過 Opus 4.8 的預設值，成本約為其每個已解決任務成本的 30%，因此最便宜的升級是以較低設定使用新模型。Sonnet 5 的節省來自其較低的每 token 價格，這足以抵銷它相較於 Sonnet 4.6 每個任務使用的額外 token：每個已解決任務少 15%，多 5 個百分點。前緣層級以相同方式獲益：Claude Fable 5.1 與 Claude Fable 5 的分數相當，每個已解決任務少 43%，大部分來自較低的快取讀取價格。該方向並非保證：在 DeepResearch Bench II⁷ 上，相同的升級在 high 下每個任務多花 41%（在 low 下多 79%），換取在每個組別都乾淨的任務上多 2 到 3 個百分點（參考文獻 7），因為新模型在那裡每個任務做更多工作。輸入與輸出價格相同，且快取讀取便宜 4 倍，因此在假設升級能省錢之前，請在您自己的工作負載上測量。

在更困難的工作上差距擴大。在 Terminal-Bench 3²⁰ 上，任務困難到由通過率而非 token 決定帳單，Claude Opus 4.7、Opus 4.8 與 Opus 5 每個任務各花費 $8 到 $15，但分別解決 7%、15% 與 41% 的任務，因此每個已解決任務的成本沿階梯從 $183 降至 $63 再降至 $28。Claude Opus 5 在飽和的程式碼子集上相對於 Opus 4.8 的 21% 溢價，在 Terminal-Bench 3 上變成 56% 的節省，因為較舊的模型在那裡大多失敗：您的工作負載越能擊敗舊模型，升級每個結果節省得越多。

以每個已解決任務的成本比較，而非每個 token：相同的文字在 Claude Opus 4.7 及之後的模型上多耗費約 30% 的 token，因此每 token 比較在結構上就會讓較新的模型看起來更昂貴。

調整 effort

「Effort」（投入程度）是針對您的任務調整模型最直接的方式。effort 參數控制模型進行多少思考、工具呼叫與自我驗證，而預設值（high）適合要求嚴苛的任務。成本會隨著所有這些活動而增加；準確度則只會隨著您的任務實際需要的那部分而提升。在模型的能力上限之下，最高的 effort 等級是在為任務從未用到的深度付費。

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

較低的 effort 設定通常更快，這在「latency」（延遲）是限制條件時很重要。在這些執行中，low 在 DeepWideSearch 上每個問題花費 4.5 分鐘，而預設值則為 7.9 分鐘。在語料庫基準測試上（其輸入無法放入任何單一「context window」（上下文視窗）），Fable 5.1 在 low、medium 與 high 下每個回合分別花費 15.2、17.5 與 19.9 小時。

長時程程式開發是 effort 真正能換來準確度的地方。在 SWE-bench Pro³ 上，Claude Opus 5 在 medium 下以一半的成本放棄了約 2 分，在 low 下以四分之一的成本放棄了約 8 分：這是真正的取捨，而以較高 effort 重新執行失敗任務能將其轉回為節省。下圖繪製了研究與知識工作基準測試以及 SWE-bench Pro 的準確度對成本關係：

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

困難的工作並不自動需要高 effort。在 DeepResearch Bench II⁷ 上，Claude Fable 5.1 在 low、medium 與 high 下的得分幾乎相同，而每項任務的成本從 $4.66 上升到 $7.12，因此在這種情況下提高 effort 並不會明顯提升輸出品質；在每個實驗組中都乾淨完成的 21 項任務上（參考文獻 7），Claude Fable 5 在各 effort 下也持平，儘管圖表的 33 項任務基礎（剔除了每個模型自己被中途截斷的嘗試）顯示它在上升。請在您要上線的模型上測量曲線，而不是您上次測量的那個模型：

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

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

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

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

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

設定預算與輸出上限

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

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

寬鬆的預算以約 3 分的通過率（處於執行間雜訊的邊緣）將每項任務成本削減了 44%，而允許的最緊預算則以 6 分的代價削減了 58%。預算在此換來了效率，其通過率代價隨著預算收緊而增加。

三種控制項做三種不同的工作。任務預算能省錢，因為模型看得到它。max_tokens 是安全上限：降低它會削減每次嘗試的成本，但不會降低每項已解決任務的成本。在 Claude Managed Agents 上，工作階段預算是兩者背後的硬性金額停止點。三者都要設定：任務預算、高的 max_tokens，以及針對您永遠不想在帳單上看到的執行所設的工作階段上限，並以工作區支出限制作為最後的防線。

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

要求更短的答案。在 Claude Sonnet 5 上，輸出 token 的成本是輸入 token 的五倍，而在代理迴圈中，模型寫出的每個 token 都會在之後的每個輪次作為輸入回來，因此您會為一個長答案一再付費。Anthropic 在三種最終答案指令下執行了分類工作，每種執行三次，使用相同的模型與工具。原始版本要求兩行：

4. Finish with exactly two lines:
LABEL: <one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish>
SUMMARY: <one or two sentences for the engineering team>

較短的變體要求一行：

4. Finish with exactly one line in this form:
DECISION | LABEL | REASON
where DECISION is one of: triage-now, needs-info, close-duplicate; LABEL is one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish; REASON is one clause under 15 words. Output nothing after that line.

較長的變體要求一份包含五個帶標題章節的備忘錄：問題摘要、證據、重複檢查、建議標籤與後續步驟。對於其中一個議題（一個在跳過問題後永遠不會送出的排隊提示），前兩種答案為：

LABEL: bug-confirmed
SUMMARY: When a user submits a new prompt instead of answering an agent's pending question, the question is cancelled/skipped but the new prompt remains stuck in "QUEUED" state indefinitely since it's waiting on a response to the now-cancelled question; the queued prompt should be processed immediately after cancellation.

triage-now | bug-confirmed | Clear repro steps show prompt queues indefinitely after cancelled question.

單行答案比兩行原始版本少用了 39% 的輸出 token，每次執行成本低 14%。備忘錄使用了六倍的輸出 token，成本是單行答案的 2.8 倍。三者對照標準標籤的得分都在彼此的執行間雜訊範圍內，因此這些格式在您付出的費用上的差異遠大於它們答對內容的差異。要求您會閱讀的答案，而不是看起來很周全的答案。

在較低的 max_tokens 上限下，兩個模型每次嘗試花費較少，但解決的任務也成比例地減少，因此每項已解決任務的成本幾乎不變：

幾乎每個輪次都遠低於任一上限就結束了。罕見的長輪次才是較高上限所換來的：

組合模型

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

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

顧問策略：升級困難決策

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

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

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

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

第二，也是脆弱的一項，是執行者是否真的會詢問（諮詢率）。低 effort 的執行者可能不再偵測到自己卡住了：一個在預設 effort 下對大多數任務進行諮詢的配對，在降低 effort 後可能降到幾乎不諮詢，然後得分低於執行者單獨運作。該比率也因任務而異：在 DeepSWE¹⁰ 上，低 effort 的 Sonnet 5 執行者持續詢問並獲得 23 分；在 SWE-bench Pro³ 上，同一執行者停止了詢問。當執行者確實詢問時，它能彌補大部分差距。在下圖中執行者持續詢問的配對中，顧問至少彌補了與較強模型之間一半的差距（程式開發配對直接勝過了較強模型），而您只在諮詢時為較強模型付費，這正是成本案例得以成立的原因：

諮詢率會對提示做出反應。僅使用工具的內建描述時，執行者呼叫不足，尤其是在程式開發工作上，因此顧問工具文件提供了一個「system prompt」（系統提示），要求在實質工作前呼叫一次、在完成前呼叫一次，每項任務約兩到三次呼叫。接下來測量的程式開發配對以該節奏執行，每項任務約兩次諮詢。該頁面也涵蓋了推動呼叫不足的執行者，以及在客戶端限制呼叫次數以控制成本。因此請關注諮詢率：為它撰寫提示、測量它，並在它崩潰時恢復執行者的 effort。

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

在一項內部代理式程式開發基準測試¹¹上（以純 API 代理執行），Claude Opus 5 執行者搭配 Claude Fable 5.1 顧問是所測量到最準確的配置，每次嘗試 $7.69。它位於穿過每個模型自身 effort 設定的線之上：以略少的費用比預設設定下的 Opus 5 單獨運作高 3.5 分（每項任務五次嘗試確實能將此差距與雜訊區分開來），並以約多一半的費用比顧問的模型單獨運作高約 2.5 分：

先前透過 Claude Code 的顧問模式進行的測量產生了相同的排序。請將此結果視為要在您的工作負載上測試的形狀：顧問以大約執行者自身的價格換來幾分。更大的能力差距並不保證更好的交易。延遲成本就是諮詢本身：在此基準測試上每項任務約多兩次前沿模型呼叫，每次都在任務的關鍵路徑上。

何時較強模型單獨運作是更好的一步。 當工作負載的準確度對 effort 有反應時，在建構配對之前，先將配對與顧問的模型在降低設定下單獨運作進行比較：顧問只在需要它的任務上付費，但在大多數任務上都觸發的諮詢，其成本高於直接執行較強模型本身。在 Chartography¹³ 上，同一配對在執行間雜訊範圍內追平了 medium 下的 Claude Fable 5.1 單獨運作（65.0 對 67.5），每項任務成本約為 2.6 倍，因為幾乎每項任務都諮詢了顧問。請先測量您自己的諮詢率：如果執行者在大多數任務上都詢問，您就是在整個工作負載上支付顧問費率，而直接執行顧問的模型本身是達到相同分數的更便宜方式。

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

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

協調器策略：委派大量工作

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

要建構一個，請使用 Claude Managed Agents 中的多代理協調：配置一個協調者代理（協調器）與一份工作者代理名冊，每個都有自己的模型。有關搭配前沿協調者與 Claude Sonnet 5 工作者的完整可運作範例，請參閱 Claude Cookbook 食譜協調者模式：大模型負責規劃，小模型負責執行。

當工作者可以平行執行時，此模式能節省實際時間：在語料庫基準測試⁸上，協調者以平台文件記載的 25 個並行工作者上限執行時，一個回合約花費 2.3 小時，而單獨運作則為 15 到 20 小時。它只在兩種測量到的情況下省錢。在單一模型能獨自處理的工作上，同一模型在較低 effort 下每次都更便宜。

情況 1：針對例行工作成本長尾的保險。 單獨運作的前沿模型偶爾會在它通常能解決的例行問題上陷入螺旋。因為您無法事先知道會是哪些，少數這樣的執行就主導了帳單。將例行工作交給較低成本工作者的協調者能限制該長尾，因為任何螺旋現在都以工作者費率發生。

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

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

情況 2：大於一個上下文視窗的工作。 單獨模型必須序列地處理那麼大的輸入，一次一個上下文視窗，並在每一輪為重新讀取自己的狀態付費。工作者各自讀取自己的分區，平行且以工作者費率進行。仍能放入一個上下文視窗的閱讀密集工作是模型選擇問題，而非委派問題：僅就閱讀成本而言，只有當沒有單一上下文能容納工作時，協調器才會勝出。

Anthropic 為此情況建構了一項基準測試⁸：一個由 14 個公開 Python 套件組成、含 130 個植入缺陷的 2,160 萬 token 語料庫，對任何上下文視窗都太大。降低 effort 無濟於事，因為帳單就是語料庫讀取本身：Claude Fable 5.1 單獨運作在三種 effort 設定下每回合成本為 $468 到 $552，只有其準確度有變動。協調者配置（Claude Fable 5.1 領導 25 個 Claude Sonnet 5 工作者）的成本約為那些設定的一半（少 47% 到 55%），得分比它們低 10 到 12 分，每回合約 2.3 小時對比 15 到 20 小時，同時直接勝過 Claude Sonnet 5 單獨運作的基準線：

token 帳目顯示了閱讀的規模：協調者配置每回合讀取約 5.6 億個快取 token，約為單獨模型約 3.65 億的一倍半，幾乎全部以 Claude Sonnet 5 的快取讀取費率計費，而整體成本仍約為一半。high effort 下的 Fable 5.1 仍保有最高準確度，成本約為協調者配置的 2.2 倍，因此此處的委派換來了大部分準確度，而非全部。

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

界線是任務難度，而非基準測試：在完整、較難的 BrowseComp⁴ 集合上，Claude Fable 5 單獨運作以低 22% 到 30% 的成本達到了協調者配置的準確度。獨立的外部研究報告了相同的模式⁵。如果工作是一條鏈、能放入一個上下文且沒有長的成本長尾，或單一模型在較低 effort 下已經達到您的標準，就不要建構協調器。

在策略之間選擇

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

如果您不確定，先什麼都不要建構：

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

本頁的多模型結果是對照同一模型在較低 effort 下以及下一級模型單獨運作來評判的。那是要在您自己的工作負載上執行的比較，也是第一步是 effort 掃描的原因。

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

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

本頁的數字反映測量時的定價，並會隨著模型與價格變化而漂移。您的升級率、任務拆分的乾淨程度與對話記錄長度也會影響它們。方法保持不變：

1. 從生產日誌中抽取幾項任務，依真實流量加權，並為每項撰寫結果檢查：測試通過、工單關閉、列數正確。在分數旁記錄每項任務的成本：將每個回應 usage 中五個計價的 token 計數依各自費率定價（未快取輸入、5 分鐘與 1 小時快取寫入分別為輸入價格的 1.25 倍與 2 倍、快取讀取，以及輸出），並跨任務的請求加總（用量與成本 API 會報告彙總值）。
2. 跨 effort 等級（而非僅預設值）為各模型層級建立基準線，並繪製分數對支出圖。多模型配置必須超越單一模型的整條曲線。
3. 如果曲線顯示 effort 無法彌補的差距，加入適合的多模型策略並重新執行測試套件。
4. 在切換前於流量切片上以影子模式執行勝出者，然後持續執行測試套件。

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

# 取自定價頁面的每百萬 token 價格；若使用其他模型，請修改這三個值。
INPUT_PER_MTOK = 5.00  # Claude Opus 5
# 輸入價格的 0.1 倍；Claude Fable 5.1 與 Claude Mythos 5.1 為 0.025 倍
CACHE_READ_PER_MTOK = 0.50
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
cache_writes = usage.cache_creation
writes_1h = cache_writes.ephemeral_1h_input_tokens if cache_writes else 0
writes_5m = cache_writes.ephemeral_5m_input_tokens if cache_writes else 0
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # 1 小時快取寫入按輸入價格的 2 倍計費，5 分鐘為 1.25 倍；讀取按快取讀取價格計費。
    + writes_1h * INPUT_PER_MTOK * 2.0
    + writes_5m * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * CACHE_READ_PER_MTOK
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

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

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

參考的基準測試

除非參考文獻另有說明，否則測量結果均為 Anthropic 內部執行這些基準測試的結果。除非另有註明，成本均以各基準測試執行時有效的定價表價格計算，單位為美元；Claude Sonnet 5 的數據採用每百萬輸入與輸出 token 分別 $2 與 $10 的價格。標示為「notional USD」（名義美元）的圖表是以這些費率對每個請求的 token 數量計價，而非報告實際帳單。

1. WideSearch： Wong 等人，"WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025。廣泛的網路研究任務，依多列表格的完整性與準確性評分；200 個問題，每種配置執行 3 次，於 2026 年 8 月 1 日至 2 日執行。成本集中度圖表是另一次 20 個問題的執行，每個問題執行 3 次，於 2026 年 8 月 3 日至 4 日執行，成本依據逐請求計費紀錄計算。
2. GDPval： OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025。知識工作交付成果依任務評分標準評分；對已發布的黃金集執行 210 項任務，每項任務嘗試一次，於 2026 年 8 月 2 日執行。由 Claude 模型評分，因此絕對分數可能與已發表的結果不同。
3. SWE-bench Pro： Scale AI, "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025。為與 Anthropic 的評估框架相容而選出的 482 個問題子集；分數無法與公開排行榜比較。Claude Opus 5 在預設 effort 下為兩次執行的平均值；降低 effort 的設定為單次執行；全部於 2026 年 8 月 4 日執行。升級（escalation）數據逐任務取自這些執行：先用 low，再對其失敗的任務使用預設值，在各執行配對中解決了 92.5% 至 93.6%，成本約 $0.45；先用 medium，為 93.8% 至 94.2%，成本約 $0.61；預設值對其自身失敗的任務重新執行，為 94.0%，成本 $1.06；全部使用預設值，為 90.9% 至 92.5%，成本 $0.93。此子集的成本依客戶組織的計量方式計價：每個請求的先前提示計為快取讀取，其新 token 計為 5 分鐘快取寫入，取自執行本身的用量紀錄，並與客戶帳本核對；評估組織本身的計量以 8,192 token 的分頁計費快取，得出的數據高出 1.4 至 1.8 倍。顧問圖表上的 Claude Sonnet 5 執行者配對來自此子集上的同一測量系列：Sonnet 加 Opus 的配對執行了兩次（2026 年 8 月 7 日與 8 月 8 日，一次執行與一次精確複製），低 effort 配對執行一次（2026 年 8 月 8 日），Claude Sonnet 5 單獨執行兩次（77.4%，為兩個 Pro 列的基準線）。「升級模型」中的 Claude Fable 5 數據點是在預設 effort 下三次執行的平均值，於 2026 年 8 月 26 日執行，以相同方式計價。Claude Fable 5.1 的任務預算數據為每個預算執行一次（35,000 token 時執行兩次），在同一子集上以預設 effort 執行，於 2026 年 8 月 26 日執行，並以同日一次無預算的執行（92.1%，每項任務 $1.10）作為基準線；較早一組在 low effort 下於 2026 年 8 月 21 日執行，無預算時得分 88.6%，每項任務 $0.48。比較模型的比較將該單次執行與同一子集中合併的兩次 Claude Sonnet 5 執行配對；在 Fable 5.1 的預設 effort 下，這組配對的結果相反，每項已解決任務的成本比 Sonnet 5 高出 41%。升級階梯為每個模型在其出廠預設值下執行一次（Opus 5 與 Sonnet 5 各兩次，Fable 5 數據點如上所述），Opus 與 Sonnet 的執行在同一週、同一框架與組織中進行。
4. BrowseComp： Wei 等人，"BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025。Effort 數據使用 500 個問題的切分，每個設定執行一至三次，於 2026 年 8 月 3 日執行，預設數據點合併了 2026 年 7 月 26 日至 27 日的兩次執行。成本保險圖表使用從 26 個問題切片中選出的 10 個可穩定解決的問題，50 次委派執行（2026 年 8 月 1 日至 2 日）與 70 次單獨執行（50 次來自 2026 年 8 月 2 日至 3 日；20 次為 2026 年 7 月 12 日至 13 日及 8 月 1 日的存檔），期望值為每次執行 $6.45 對比 $11.99；委派數據帶有約 20% 的測量區間。
5. 代理架構擴展： Kim 等人，"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 次，於 2026 年 8 月 2 日執行（單一工作者團隊數據點於 2026 年 7 月 26 日至 27 日執行）。
7. DeepResearch Bench II： Li 等人，"DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026。其橫跨 22 個領域的 132 項研究任務依專家衍生的二元評分標準評分；在橫跨所有主題分層的 50 項任務子集上測量，每項任務嘗試一次，每個設定執行 3 次，於 Claude Managed Agents 上使用平台本身的網路搜尋與擷取工具執行（2026 年 8 月 26 日至 27 日）；以沒有任何配置拒絕的 33 項任務評分，並移除被正式環境安全分類器中斷的嘗試；成本為客戶被計費的金額，即平台的請求加上網路搜尋費用。分數為每個模型在 33 項任務基礎上、移除其自身被搶先中止的任務後的平均值；在每個組別中皆乾淨的 21 項任務上，Claude Fable 5.1 在每個 effort 等級上都比 Claude Fable 5 領先 2 至 3 分，且兩個模型在各 effort 間表現持平。快取圖表以未快取費率對每個輸入 token 重新計價相同的請求。Claude Opus 4.6 依該基準測試的評分標準協定進行評判；原始版本使用不同的評判者，而 Anthropic 的評判者可能偏好自家風格。Claude Opus 5 在其預設 effort 下於 2026 年 8 月 28 日在相同介面與子集上執行三次：原始 50 項任務為 68.8%，33 項任務基礎為 70.8%，21 項任務集為 71.1%，每項任務 $6.71（無快取時為 $23.72）；其嘗試均未被安全分類器中斷，所使用的安全防護部署比其他模型執行時的版本更新。
8. 語料庫缺陷掃描： Anthropic 內部，針對大於一個上下文視窗的工作：來自 14 個公開 Python 套件原始碼的 2,160 萬 token 語料庫，植入 130 個缺陷並採用確定性評分；協定在執行前固定並經內部審查；每種配置執行三次。每種配置均在 Claude Managed Agents 上執行。圖表中的團隊配置是一次由 Claude Fable 5.1 協調者在平台內以其文件記載的 25 個並行 Claude Sonnet 5 工作者上限執行整個掃描的執行，於 2026 年 8 月 30 日執行；其三個回合在額外項目稽核後的 F1 分數為 0.764、0.825 與 0.791（原始為 0.751、0.821 與 0.781），成本為 $225、$234 與 $283。Claude Sonnet 5 單獨配置於 2026 年 8 月 3 日至 4 日執行；Claude Fable 5.1 單獨配置於 2026 年 8 月 24 日至 25 日在平台的上市服務設定下執行，每個 effort 設定三個種子，使用相同的語料庫建置。沙箱映像檔帶有部分語料庫的已安裝副本，Claude Fable 5.1 的最終組裝步驟在 9 個回合中有 7 個與之比對；在不含這些新增項目的情況下重新評分，使受影響的種子變動最多 3 分。絕對 F1 值特定於此語料庫建置，無法跨基準測試比較；配置間的比較為同類比較。
9. GPQA Diamond： Rein 等人，"GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023。198 個問題的 Diamond 子集，每種配置執行兩次，於 2026 年 8 月 7 日執行，依參考答案由模型評分，顧問 token 逐請求計量。平台安全檢查在 Sonnet 與 Opus 執行者上拒絕了兩個生物學問題；排除它們不會使任何比較變動超過一分。
10. DeepSWE： Datacurve, "DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026。該集合有橫跨五種語言的 113 項原創任務，附有基於程式的驗證器。配對各執行兩次，於 2026 年 8 月 7 日執行，顧問 token 逐請求計量，並使用客戶端顧問迴圈而非顧問工具，會計方式相同。單一模型 effort 掃描為單次執行，依 token 數量計價，為一種考量快取的近似值。每項任務成本為執行總額除以 113。
11. 內部代理式程式設計基準測試： Anthropic 內部：370 項儲存庫任務，由儲存庫本身的測試評分。API 數據以 128,000 token 的輸出上限測量，每種配置執行一次：Opus 5 單獨在預設 effort 下於 2026 年 8 月 9 日至 10 日執行，Claude Fable 5.1 單獨在五個明確設定的 effort 值下於 2026 年 8 月 20 日執行，配對於 2026 年 8 月 24 日至 25 日執行。每項任務的嘗試次數：配對與 Opus 單獨對照組為五次，單一模型數據點為一次；配對平均每次嘗試約諮詢顧問兩次；成本為每次嘗試的成本。Claude Code 數據為 2026 年 7 月 8 日至 23 日對相同任務的執行，每種配置執行一次，成本為近似值。
12. 內部儲存庫任務基準測試（上限測量）： 另一組 Anthropic 內部約 130 項儲存庫任務，於 2026 年 8 月 8 日至 10 日（Claude Opus 5）與 2026 年 8 月 20 日（Claude Fable 5.1）執行，使用純 API 代理迴圈，每項任務嘗試一次。Claude Fable 5.1 的執行為每個上限 135 項任務，在明確設定的預設 effort 下：16,384 token 的數據為兩次執行的平均值（兩次皆為 36.3%）；64,000 與 128,000 的數據為單次執行（58.5% 與 60.0%）。六個問題在每次執行中都引發安全拒絕，計為失敗。Opus 5 的 16,384 token 數據為兩次執行的平均值，其 64,000 數據為單次執行（124 項任務已評分）。SWE-bench Pro 上限數據為每個上限一次 Claude Fable 5.1 執行，在預設 effort 下於 2026 年 8 月 26 日執行，使用從參考文獻 3 的 482 個問題集分層抽出的 100 個問題子集，無法與其分數比較；兩個上限在預設值下得分相同。圖表的逐輪分布來自 Opus 在 64,000 下的執行與 Claude Fable 5.1 在 128,000 下的執行；沒有任何 Opus 輪次達到其上限，有一個 Fable 5.1 輪次達到 128,000（其 0.46% 的輪次超過 16,384）。
13. Chartography： Surge AI, "Chartography," 2026。完整發布的 100 個問題集，於 2026 年 8 月 8 日至 10 日以 Anthropic 在 Claude Managed Agents 上的實作測量（標準雲端沙箱；顧問配置使用 Managed Agents 顧問）。由 Claude Sonnet 4.6 而非參考評判者評分，且基準測試搭配工具執行，因此分數可在此處的配置間比較，但無法與已發表的排行榜比較。每種配置執行兩次並合併；執行間的差距為 4 至 10 分。成本不含沙箱時間，其增加不到 1%。Claude Fable 5.1 單獨執行來自 2026 年 8 月 24 日，在平台的上市服務設定下，每個設定執行兩次；六次嘗試達到 15 分鐘的工作階段上限並得 0 分，每次執行有兩張圖表在安全拒絕後由 Claude Opus 5 回答。搭配 Claude Fable 5.1 顧問的 Claude Opus 5 低 effort 執行者於 2026 年 8 月 30 日在相同設定下執行兩次（63.0 與 67.0，平均 65.0，每張圖表 $0.72；每次執行中有 88% 的任務諮詢了顧問，其 219 則回覆中有 4 則改由 Claude Opus 5 提供，每則皆在正式環境安全過濾器阻止顧問本身的回覆之後）。較早配對的諮詢率比較來自於 2026 年 8 月 10 日至 11 日在 Messages API 上以容器工具集重新執行相同配置。
14. 客服台提示稽核評估： Anthropic 建構的 44 張客服工單集，採用確定性評分，於 2026 年 8 月初執行並於 2026 年 8 月 8 日報告，使用六個系統提示，每個都在同一個乾淨提示上加入一種在為 Claude Opus 4.8 與 Claude Sonnet 4.6 撰寫的提示中常見的模式。每個圖表數據點為三種情況之一（較舊模型、較新模型使用相同提示、較新模型經稽核後），對六個提示與 44 張工單取平均。Opus 5 的準確度提升有 3 至 8 分的 95% 信賴區間；Sonnet 的準確度差異在雜訊範圍內。
15. 資料檔案問題集： Anthropic 建構的 25 個彙總問題集，針對一份公開酒類銷售 CSV 的 1,862 列切片，基準真值由 pandas 計算並採用精確比對評分，在 Claude Sonnet 5 與 Claude Opus 5 上執行，停用思考（上下文內組別在預設值下無法完成），4,000 token 輸出上限，且不使用提示快取，每種配置執行三次，於 2026 年 8 月 19 日執行。檔案組別透過 Files API 上傳 CSV 並使用 code_execution_20260120 工具。
16. 快取持續時間測量： 來自精簡輸入與上下文 token 的 20 個議題分類工作，於 2026 年 8 月 23 日在 Claude Sonnet 5 與 Claude Opus 5 上透過 Messages API 以相同框架執行，Claude Opus 5 的儲存格將 max_tokens 提高至 4,096，並在隨機選取的一部分輪次前插入暫停（無、5%、10%，以及在兩個模型上對全部 20 個議題每輪暫停 6 分鐘，另加在 Claude Sonnet 5 上每輪暫停 2 分鐘；在兩個模型上對 5 個議題子集暫停 20 分鐘；僅在 Claude Sonnet 5 上對 5 個議題子集暫停 45 分鐘）。每個儲存格執行三次，成本依每個回應的 usage 欄位在客戶計費組織上以定價表價格計算，準確度依相同的黃金標籤評定。兩個模型的交叉點皆約為 3.3% 的輪次：為每個工作階段損益平衡比例的中位數，由成本模型依該工作階段逐輪的上下文大小計算，涵蓋分析中全部 45 個 Claude Sonnet 5 與 36 個 Claude Opus 5 的二十議題工作階段（每個暫停排程在完整工作上執行，在全部三種快取設定下，各執行三次；5 個議題的儲存格不在其中）。5% 的儲存格在 Claude Sonnet 5 上打平，因為該次抽樣的暫停落在較小的前綴上。本頁的二十分之一規則高於測得的交叉點。Anthropic 測量了刷新 5 分鐘快取的保持連線請求，僅作為對照。它們最多與 1 小時設定相當，且在每輪前都有暫停時成本更高，因此請勿在這兩個模型上使用它們；在 Claude Fable 5.1 上算術結果相反（參考文獻 19）。
17. 正式環境中的快取讀取比例： 截至 2026 年 8 月 23 日的 14 天內彙總的第一方 Claude API 用量，僅限直接 API 產品，排除 Anthropic 內部組織，未識別任何組織。當一個組織日的請求帶有工具定義與工具結果、其提示平均包含 9 個或更多先前工具呼叫、使用了快取，且發出至少 10 個此類請求時，該組織日計為代理迴圈（API 沒有對話識別碼，因此以此代表對話長度）：橫跨 106,487 個組織的 303,003 個組織日，快取讀取比例中位數為全部輸入 token 的 84.2%，上四分位數為 91.7%。使用案例標籤（組織宣告的使用案例，否則為其分類的使用案例）涵蓋這些組織日的 74% 與其 token 的 99%；程式設計組織提供 87% 的代理式輸入 token，讀取中位數為 88.5%（在 25 個或更多先前工具呼叫時為 90.9%），上四分位數為 93.4%，約 72% 的程式設計組織日達 80% 或以上；客服、研究與資料代理讀取 84% 至 85%。組織日的前十分位數在程式設計上讀取 95.9% 或以上，在客服、研究、資料與其他代理上為 94.2% 至 94.8%。在 25 個或更多先前工具呼叫時的請求層級拆分來自六小時的樣本：程式設計為 92% 讀取、7% 寫入、不到 1% 未快取。未標籤的組織多為小型，讀取中位數為 11%。沒有工具定義的組織日讀取中位數為 34.6%。一項針對相同時間窗的獨立查詢重建了 10 個或更多請求的對話，而非對組織日評分，得出中位數為 90.2%；差異在於範圍，而非資料。
18. 壓縮時機測量： 來自精簡輸入與上下文 token 的分類代理長版本，於 2026 年 8 月 24 日在 Claude Sonnet 5 上以 5 分鐘快取執行，成本依用量欄位以定價表價格計算，每個組別五個工作階段：一個全程使用預設 effort 的無變更組別（每個工作階段 $0.81），以及兩個從低 effort 開始並進行相同兩項破壞快取之變更的組別，即切換至預設 effort 與新增一個工具，分別在工作階段中途的第 12 與第 17 個請求進行（$0.95），或在第一次壓縮後的第一個請求一併進行（$0.75）。第四個組別有六個工作階段，於 2026 年 8 月 25 日執行，在觸發第一次壓縮的請求上進行相同的兩項變更（每個工作階段 $0.92）：該請求的摘要處理將 81,000 token 的上下文寫入快取而非讀取，因此該處理成本為 $0.21，而邊界組別中相同處理為 $0.04。工作階段在第 21 至 25 個請求首次壓縮（21 個工作階段中有 16 個在第 22 個請求），即提示超過 80,000 token 的壓縮觸發點後，且有兩個無變更工作階段在接近結束時第二次壓縮。邊界組別的總額低於無變更組別，反映的是其變更前的低 effort 請求與那些第二次壓縮，而非快取：兩個組別的重新寫入成本差異不到一美分。中途組別每個工作階段支付 $0.23 的快取重新寫入；中途組別與邊界組別之間的差異為 $0.20，95% 信賴區間為 $0.11 至 $0.29。一個中途工作階段在其模型於壓縮後錯誤呼叫搜尋工具並得到空結果後執行成本偏低（$0.82）；它已納入計算，若不含它，該組別平均為 $0.98。8 月 24 日各組別的準確度平均為 20 個標籤中的 14.2 個，8 月 25 日組別為 14.7 個；快取讀取在無變更時為提示 token 的 91%，中途為 85%，邊界為 91%，在觸發請求上進行變更時為 86%。
19. Claude Fable 5.1 上的快取持續時間測量： 與參考文獻 16 相同的 20 個議題分類工作與框架，於 2026 年 8 月 23 日與 8 月 26 日在 Claude Fable 5.1 上市快照上以其上市價格執行（每百萬 token 輸入 $10、5 分鐘寫入 $12.50、1 小時寫入 $20、快取讀取 $0.25、輸出 $50），每個排程三種設定：5 分鐘快取、1 小時快取，以及每閒置 4 分鐘就對未變更前綴發出 max_tokens: 0 請求以保持溫熱的 5 分鐘快取（8 月 23 日的執行以 max_tokens: 1 發送 ping；8 月 26 日的每次 ping 都刷新了快取且未計費任何輸出）。排程：無暫停、10% 的輪次，以及對全部 20 個議題每輪暫停 6 分鐘，以及對 5 個議題子集暫停 45 分鐘；每個儲存格執行三次，成本依每個回應的 usage 欄位以定價表價格計算，準確度依相同的黃金標籤評定（20 個中有 12 至 17 個精確標籤）。8 月 26 日 5 分鐘、1 小時與保持連線設定的每工作階段平均值：無暫停為 $2.42、$3.09、$2.29；10% 暫停為 $4.50、$2.96、$2.36；每輪為 $22.89、$3.01、$2.62；8 月 23 日的儲存格在 6% 以內一致。45 分鐘的數據（每個 5 議題工作階段 $1.68、$0.59 與 $0.71）來自 8 月 26 日在一次快取計費事件破壞當日第一批儲存格後的乾淨重新執行；8 月 23 日的執行得出 $1.67、$0.58 與 $0.70。5 分鐘與 1 小時設定之間的交叉點為 3.1% 的輪次，與參考文獻 16 為相同的衡量方式。
20. Terminal-Bench 3： 公開終端代理基準測試的 74 項任務，在 Claude Managed Agents 上以兩個自訂工具執行，即由評估框架在每項任務自己的容器中執行的 shell 與檔案編輯器，取代平台的內建工具，其餘則採用平台對外部帳戶的預設設定，每個模型在 high effort 下執行兩次，2026 年 8 月 27 日至 28 日。分數為每個模型 148 次嘗試的原始通過率；單次執行的波動為 5 至 11 分。成本為客戶以定價表價格會被計費的金額，依執行的用量紀錄以 5 分鐘快取存留時間逐請求重新計價。Claude Opus 4.7 在其 148 次嘗試中有 11 次在其輸出上限處結束。

後續步驟