調整提示快取、指令與努力程度，可在不犧牲應用程式效能的情況下降低 Claude 的成本。
效能與成本常被視為一種取捨：為了花費更少，你接受較差的結果。實際上，我們發現許多使用 Claude Platform 的應用程式，可以透過三個修正來降低成本而不犧牲效能：最大化提示快取命中率、在升級到前沿 Claude 模型時移除提示中的反模式，以及根據任務校準努力程度。我們已將此指南放入 claude-api 技能。在本文中，我們將展示 Claude Code 搭配 claude-api 技能如何經常找到降低成本，同時維持或提升效能的方法。
提示快取
在 Claude 產生回應之前，它會先將你的提示處理成內部工作狀態。這個稱為預填充的步驟，是處理輸入中成本較高的部分。提示快取會儲存該狀態（即鍵值對，或稱 KV 快取）：當請求以相同的前綴開始時，Claude 會讀取它，而不是重新計算。快取讀取的計費價格僅為完整輸入價格的一小部分。
要有效使用提示快取，有幾個實際考量。首先，提示快取是綁定特定模型的。其次，提示快取讀取在前綴部分必須是位元組完全一致的。最後，提示快取有有限的存活時間（TTL）。
考量這些要點，這裡有一些實用技巧：
- 在對話中途更改努力設定時要小心。這些設定會在你的內容之前渲染到提示中，因此它們是快取前綴的一部分。只有特定的 Claude 模型（包括 Opus 5 和 Fable 5.1）允許你在對話中途更新努力設定而不破壞快取。
- 將易變的值排除在前綴之外。系統提示中的動態時間戳或 ID 可能會在模型呼叫之間改變，從而破壞快取。
- 避免使用會自行重新排序的工具定義。使用 Claude messages API 時，提示的組裝順序是固定的，工具定義會渲染在最上方。對工具定義的任何更改都會破壞快取。
- 分岔對話時要小心。子 Agent 和分支僅在分岔的前綴位元組完全相同、使用相同模型且使用相同努力程度時，才能共享父對話的快取。
如何修復
我們累積了一些關於提示快取管理的經驗：
- 仔細監控你的提示快取命中率。Claude Console 和快取診斷 API 提供提示快取診斷，包括快取未命中的原因（圖 1）以及兩個請求在哪裡產生分歧。
- 延遲載入不常用的工具。事先宣告所有工具，但將不常用的工具標記為 defer_loading：它們會保留在快取前綴之外，僅在 Claude 使用工具搜尋查找它們時才附加到對話中，從而保留快取。
- 將系統提示更新作為訊息應用。某些 Claude 模型允許你在對話中途將系統指令作為訊息添加，而不是編輯系統提示，這樣可以保留快取。
- 安排請求結構，讓穩定的部分保持穩定。先添加靜態上下文（工具定義和系統提示），然後在其後添加不斷增長的對話（圖 2）。
- 在提示快取即將被破壞時才更改模型或努力程度。某些操作，例如壓縮，已經會重寫大部分的快取（對話）。這是切換模型或努力程度的好時機，因為你無論如何都要為一次快取未命中付費。
- 隨著對話增長移動快取斷點。使用 Claude Platform，你可以設定自動快取，將快取斷點應用於最後一個可快取的區塊。
- 預先暖機快取。為了減少延遲，發送一個帶有 max_tokens: 0 和明確快取斷點的請求，並使用與實際流量相同的努力設定。這會處理提示並將其寫入快取，而不產生任何內容。如果你在會話開始時（例如，在使用者輸入時）執行此操作，第一個真實請求將會命中一個已暖機的快取。
- 不要超過提示快取 TTL。5 分鐘的快取 TTL 是從請求開始時計算的。如果一個 Agent 在工具呼叫或子 Agent 請求上阻塞超過 5 分鐘，父對話的快取會在結果返回之前過期。在這種情況下，可以考慮為前綴設定 1 小時的 TTL。
指令
提示可能會累積用於修補模型弱點的指令。這些指令可能會偏離最新 Claude 模型的能力。以下是一些常見的提示「反模式」，它們會妨礙前沿 Claude 模型，並可能無意中增加成本：
- 驗證儀式。像「雙重檢查你的工作」或「在回應前驗證兩次」這類指令，前沿模型通常會照字面理解，從而浪費 token。
- 詳盡性與強調增強詞。「做到最大限度的詳盡」、「關鍵：你必須總是……」在使用前沿模型時可能導致冗長和額外的工具呼叫。
- 強制性程序與草稿板支架。固定步驟的流程（例如，「在草稿板中逐步思考」）或推理模板是前沿模型不需要的儀式。這種支架會疊加在原生推理之上，並使用不必要的 token。
- 過時的範例。針對舊模型失敗模式調整的少樣本範例，可能會教導前沿模型在不需要的請求上模仿冗長的推理鏈。
- 矛盾的規則。前沿模型更擅長遵循指令。矛盾的指令（例如，「始終在政策範圍內退款」與「未經上報不得退款」）可能會被前沿模型更嚴格地遵循，導致效能下降。
- 過時的配置。為舊一代 Claude 編寫的設定（例如，手動思考預算）可能會被 Claude Platform 與較新模型拒絕。
如何修復
我們已更新 claude-api 技能，新增了一個用於偵測這些反模式的指令。在 Claude Code 中，對你的提示、技能或工具描述執行 /claude-api prompt-audit。此審計涵蓋你工作目錄中的任何內容，包括呼叫 Claude API 的應用程式碼以及 Claude Code 自身的配置（例如，CLAUDE.md 或技能）。
例如，我們在一個客戶支援基準測試上測試了從 Opus 4.8 到 Opus 5 的模型遷移。我們從一個乾淨的提示開始，一次植入一個反模式（一個已淘汰的思考設定、一對矛盾的退款規則、一個手動草稿板、「驗證兩次」、「做到最大限度的詳盡」以及一個強制性的六步驟程序），總共生成了六個舊版提示。
我們在 Opus 4.8 上、在僅更改模型 ID 的 Opus 5 上，以及在每個提示上執行一次 /claude-api prompt-audit 後的 Opus 5 上分別運行了這些提示（圖 3 顯示了六個提示的平均結果）。
使用 Opus 5 時，驗證儀式（「驗證兩次」）透過在每次退款時重複查詢訂單來使用不必要的 token。強調增強詞（「做到最大限度的詳盡」）則導致了數十次不必要的知識庫搜尋。
執行 /claude-api prompt-audit 移除了這些反模式，平均降低了 14.6% 的成本，並將準確率提高了 5.3%。成本下降是因為消除了額外的工具呼叫和重複的推理。準確率提升則有三個原因。已淘汰的思考設定導致 API 直接拒絕了每個路由請求。矛盾的退款規則導致 Opus 5 在要求客戶確認的同時，扣留了四筆本應退還的款項。而手動草稿板與 Opus 5 的內建思考功能發生衝突：在三張工單中，它將工具呼叫寫在了推理過程中，從未執行。
努力程度
努力程度告訴 Claude「要花多少力氣工作」。在低努力程度下，Claude 通常會更快得出結論。在高努力程度下，Claude 在回答前會進行深思、驗證並探索替代方案。
在單一模型上，不同努力程度之間的成本與效能可能有所不同。例如，Claude Fable 5 在低努力程度下，在 FrontierCode Diamond（最難的 50 個任務）上得分為 11.5%，每個任務成本為 $5.35 美元。在最大努力程度下，Fable 5 得分為 30.9%，每個任務成本為 $19.00 美元；改變努力程度使分數提高了約 2.7 倍（+19 分），但成本約增加了 3.5 倍（圖 4）。
在 Claude Fable 5.1 上，Humanity's Last Exam（不使用工具）顯示出一條陡峭的曲線，最後一步的收益遞減。它在低努力程度下得分約為 53%，每個問題成本約為 $0.30 美元；在最大努力程度下得分約為 61%，每個問題成本約為 $2.23 美元；最後一步提升到最大努力程度，分數僅增加約半點，成本卻增加了 46%。這個收益落在基準測試的運行間噪音範圍內，因此你付出了更多成本，卻沒有獲得可衡量的收益。
努力程度可能在兩個方向上校準不當：
- 假設越高越好。高努力程度可能導致過度思考。Claude 花費比任務所需更多的時間進行深思，這增加了成本和延遲，並可能降低答案品質。只有在仍有證據可循時，深思才有所幫助。
- 偏向低努力程度。設定過低時，Claude 在獲得足夠證據前就停止了。它會進行較少的工具呼叫，因此可能根據第一個搜尋結果而非第三個來回答。它在困難步驟上思考較少，並跳過通常會自行執行的檢查。答案看起來完整，但卻是建立在部分資訊之上。
如何修復
有一些有用的方法可以校準努力程度：
- 在低努力程度下測試更強的模型。一個在低努力程度下的更強模型，可能比一個在高努力程度下努力工作的較弱模型更便宜。例如，在 CursorBench 3.2 上，低努力程度的 Claude Fable 5.1 匹配了高努力程度 Fable 5 的效能，但成本僅為其三分之一（圖 5）。有兩個原因使較新模型更便宜：在低努力程度下，它每個任務做的工作更少；而且 Fable 5.1 的提示快取讀取定價為每百萬個 token $0.25 美元，而 Fable 5 為 $1.00 美元。即使按照 Fable 5 的價格，低努力程度的 Fable 5.1 成本也會降低約 40%。
- 了解你的任務形狀。在一系列努力程度上衡量應用程式效能，是了解特定任務成本與效能權衡的有用方法。在一個非飽和的評估中，不同努力程度之間的成本效能曲線趨於平坦，表明該任務不受思考計算的限制；增加努力程度並無益處。
這種校準通常涉及跨模型和努力程度運行評估。在 Claude Code 中，/claude-api hillclimb 為你執行此搜尋：它將你的評估拆分為訓練集和測試集，提出配置更改，並讀取失敗的訓練範例來修正發現的問題。
我們在一個客戶支援基準測試上運行了它，從預設（高）努力程度的 Opus 4.8 開始。這個爬山演算法首先嘗試了低努力程度的 Opus 5，應用 prompt-audit 來移除強制性的工具呼叫儀式、草稿板步驟和矛盾規則。這超越了 Opus 4.8 的基準線（訓練準確率為 98.9%），並將成本降低到每張工單 2.6 美分（圖 6）。
然後，它進一步降低到低努力程度的 Sonnet 5，成本更低，每張工單僅 1 美分，但準確率下降到 88.9%。透過閱讀失敗的訓練工單，Claude 在提示中添加了路由規則和退款上限交叉引用，使 Sonnet 5 在相同成本下恢復到 98.9% 的準確率。
在搜尋從未見過的 14 張保留工單上，最終配置得分為 90.5%，而原始設定為 78.6%，成本約為原來的五分之一。
自動化降低成本
提示快取、指令和努力程度是降低成本的常見槓桿。我們的文件涵蓋了更多內容。為了對使用 Claude API 的應用程式碼進行全面的成本審計，我們新增了 /claude-api cost-optimize：它會分析你的花費去向，應用成本降低措施，並且，如果你提供評估，它會顯示節省與效能之間的權衡。
cost-optimize 首先找出你的 token 花費在哪裡：如果你有 Claude Admin API 金鑰，則來自你組織的使用量和成本報告；如果你的應用程式記錄了 API 回應，則來自每個 API 回應上的 usage 物件；如果兩者都不可行，則透過讀取你的請求建構程式碼並進行估算。
然後，它會對可用的節省措施進行排序，從提示快取開始，修剪每個請求攜帶的內容（包括 prompt-audit），限制輸出，以及批次處理無人值守的工作。如果你提供評估，它會更進一步，計算不同努力程度和模型選擇下的成本與效能。我們以 Sonnet 5 為基準，在四個公開基準測試上運行了此功能（圖 7）：
- LegalBench（成本降低約 58%）：cost-optimize 建議快取跨任務共享的前綴，設定低努力程度，並透過 Batch API 處理任務。思考 token 從 102,779 個下降到 8,284 個，通過率保持在噪音範圍內，成本降低了約 58%。
- tau2-bench retail（成本降低約 73%）：透過實施帶有明確斷點放置的提示快取，cost-optimize 將支出減少了 72%，同時保持通過率不變。
- OfficeQA Pro（成本降低約 52%）：cost-optimize 添加了批次處理和文件快取，使成本從 $136.20 美元降至 $64.87 美元。
- SWE-bench Verified（成本降低約 55%）：cost-optimize 發現預設配置已正確快取。節省來自將努力程度設定為中等，並將 Agent 的輸出限制為幾個簡潔的句子。每個任務的中位數步驟從 29 步降至 17 步，提示 token 從 75.2M 降至 33.7M。
開始使用
當你已遷移到前沿 Claude 模型並想檢查現有提示時，請從 /claude-api prompt-audit 開始。它會掃描你工作目錄中的提示、技能和工具描述。這可以是呼叫 Claude API 的應用程式碼或 Claude Code 的配置（CLAUDE.md、技能）。它會移除妨礙前沿模型的常見反模式。
當你的應用程式使用 Claude API 並且你想要進行成本審計時，請使用 /claude-api cost-optimize。它會分析 token 花費，然後測試不同的槓桿：它會應用 prompt-audit，但也會檢查透過提示快取、批次處理無人值守工作或限制輸出來降低成本的方法。如果你提供評估，它會衡量努力程度和模型選擇的權衡。
最後，使用 /claude-api hillclimb 進行成本和效能的搜尋。給定一個評估，Claude 會將其拆分為訓練集和測試集，然後提議對你的應用程式進行更新，旨在降低成本同時維持基準效能。Claude 會讀取失敗的訓練案例來引導搜尋，最終配置會在保留的測試集上進行評分。
要了解更多：
作者：Lance Martin (@RLanceMartin)、Brad Abrams (@brada)、Isabella He (@IsabellaKHe) 和 Ben Lehrburger (@benlehrburger)。
