Prompt-Cache Economics

資料來源#

摘要#

生產環境部署會並用兩種 token 成本槓桿：prompt caching（用 cache_control 標記前綴，重讀時享有大幅折扣）和 prompt compression（傳送較少 token）。Cache-Aware Prompt Compression（Yan Song，PayPal，arXiv 2607.15516，2026-07-17，empirical）是本語料庫首篇將兩者合併計價為同一項最佳化的研究，並發現主流壓縮家族會積極妨礙主流快取機制。

背後的機制來自結構本身。具查詢感知的壓縮器（LLMLingua、LongLLMLingua 及同類方法）依其設計，會為每個查詢產生不同的壓縮前綴。前綴快取要求 token 完全一致。因此每次呼叫都是未命中，每次都要支付未快取輸入費率，外加快取寫入溢價；壓縮省下的成本又花在重寫快取上。文獻從未注意到這點，因為它把快取命中率隱含建模為 ρ = 1.0——也就是免費且完美的快取。實際測量並非如此。

本文的核心有兩項結果。第一，ρ 既不是 1.0，也不會平滑變化：Sonnet 4.6 的快取在約 3,500 個 token 處有階躍變化，低於此處時，即使前綴穩定且未經修改，仍會未命中。第二，在採用確定性評分的公開基準測試中，具查詢感知的壓縮成本比傳送未壓縮提示高 40.1%——這種減少 token 的技術 ROI 為負，而且是按帳單而非 token 計數器測得。

實測快取#

所有數字均採用 claude-sonnet-4-6、5 分鐘 TTL 的短暫快取、2026 年 5 月價格；每個快取前綴都加上每次執行專用的 UUID，以免實驗彼此污染。特性測量成本：$1.91。

價格（§3.3）。 輸入 $3.00/MTok、輸出 $15.00/MTok、快取寫入（5 分鐘）$3.75/MTok、快取讀取 $0.30/MTok。Anthropic 的帳單在三次獨立執行中都與機械計算結果相差不到 1%——發表的表格數值精確。關鍵的成本形狀是寫入與讀取之間相差 12.5 倍，而寫入成本甚至高於未快取 token。

兩階段階躍（§3.1）。 以前綴大小為變數掃描，每種設定各做 n = 3 次試驗：

快取前綴	ρ (N=5)	ρ (N=10)	ρ (N=30)
2,053 tok	0.53	0.63	0.83
4,096 tok	1.00	1.00	1.00
6,139 tok	1.00	1.00	1.00
8,182 tok	1.00	1.00	1.00

三次 2k 試驗的結果完全相同，都是 25/30 = 0.833（σ = 0）。超過階躍點後，ρ 從下一次呼叫起就是 1.0。另一組 2.4k 試驗則從 0.47（N=5）升到 0.89 的平台（N=50），σ ≤ 0.01。模型採用的門檻是 T ≈ 3,500 個 token，並將兩個區間命名為下方的 hot/limited 和上方的 persistent/replicated。圖 1 和圖 2 清楚呈現此形狀：一條紫色曲線從 0.53 緩慢爬升，而 4k/6k/8k 曲線從 N = 5 起便平貼在 ρ = 1.0 線上。

這是實務工作者不會預料到的發現。維持前綴逐位元組完全一致，仍不足以確保快取命中——低於門檻時，約每六次呼叫就有一次仍得支付寫入費率，而且使用者看不出任何原因。

失效判定要求 token 嚴格一致，但有一項例外（§3.2）。 不同的 cache_control 後續查詢仍會命中；在前綴開頭修改 1 個字元、在中間修改 5 個字元，以及附加真正的 token 後綴，都會未命中（4/4，符合預測）。不過，在前面加上一個空格仍會命中——Claude 的 tokenizer 在計算快取鍵之前，會正規化前導和尾隨空白。只有空白不同不會造成真正的失效；對任何會為提示片段建立指紋的系統來說，這是個小而可利用的特性。

交叉點規則#

刪去所有策略都相同的項目，並令快取成本等於壓縮成本，即可得到快取命中率門檻；低於這個門檻，快取就不再是較便宜的選擇：

ρ_cross(r) = (c_w − p_in/r) / (c_w − c_r) = (α − 1/r) / (α − β)

其中 α = c_w/p_in 是寫入溢價，β = c_r/p_in 是讀取折扣。這個無因次形式是論文最容易移植的成果：只需要三項已公布價格，不需要測量。Sonnet 4.6 的 5 分鐘 TTL 給出 α = 1.25、β = 0.10（1 小時 TTL 的 α = 2.0；OpenAI 的自動快取則為 α = 1.0、β = 0.5）。

壓縮比 r	ρ_cross	解讀
2	0.652	ρ > 0.65 時，只有快取較划算
3	0.797	ρ > 0.80 時，只有快取較划算
4	0.870	ρ > 0.87 時，只有快取較划算
6	0.942	只有 ρ ≥ 0.94 時，只有快取才較划算
8	0.978	只有 ρ ≥ 0.98 時，只有快取才較划算
10	1.000（封頂）	不可能——只有快取永遠不會勝出

以實測約 0.89 的平台值來看，這代表r ≥ 6 時，單純快取不如具查詢感知的壓縮——正好與傳統觀念相反。r = 6 的設定已在 4/4 次試驗中確認。

呼叫次數也呈現相同反轉：與假設命中率為 1.0 相比，實測 ρ 會讓損益兩平所需的 N 增加 3–5 倍。r = 3 時，理想模型預測快取在 7.0 次呼叫後回本；實際上需要 24 次。r = 4 時，則從 8.3 次變成 38 次。r ≥ 6 時，永遠無法回本。

這條規則取決於價格，不是固定常數。 固定 β = 0.1，將 α 從 1.25 降至 1.1，會把「快取永遠不會勝出」的範圍從 r ≥ 10 拉低至 r ≥ 4——進入真實工作負載常見的比例。將 α 提高至 2.0（1 小時 TTL），則會把這個範圍推到 r ≥ 16。**在一個供應商與一種 TTL 上測得的快取政策門檻無法直接套用；能移植的是產生門檻的公式。**只要 β < 1 < α，定性主張（存在有限交叉點）就成立，而所有已推出的快取 API 都符合這條件。

CAPC 與維持快取層級的上限#

建議的解法並不花俏，這正是重點：在請求路徑之外，先以不依賴查詢的方式壓縮文件一次，接著用 cache_control 標記壓縮區塊，再把查詢附在後面。四行程式碼。文獻的貢獻是選擇了具查詢感知的壓縮；修正方法則是停止這麼做。

非顯而易見的部分是一條上限。提高 r 會縮小快取前綴並降低每次呼叫成本——直到前綴掉到層級門檻以下，ρ 隨之崩落，相當比例的呼叫就得支付寫入費率：

r_max_safe(|D|) = floor(|D| / T), T = 3,500 tokens (Sonnet 4.6)

以 12,191-token 文件測量：r = 3 時前綴為 4,067 個 token（持久層級），每次查詢成本 $0.0057；r = 4 時則降至 3,119 個 token（熱層級），成本回升至 $0.0101——壓縮旋鈕只多轉一格，成本就增加 77%。過度壓縮會造成成本回升，不只是品質下降，而 token 計數器完全看不出來。

LongBench-v2 結果（4 份文件 × 4 種比例，每個組合 N = 10 個查詢）：CAPC 在四種策略中有 16/16 組合成本最低，平均比 vanilla 省 89.6%，比 cache-only 省 48.5%，比具查詢感知的壓縮省 64.4%。各策略平均品質分數落在很窄的區間（vanilla 0.73、cache-only 0.75、具查詢感知的壓縮 0.67、CAPC 0.66）；r = 2 時四者分數差距都在 0.04 以內。在 12,191-token 文件的真正同品質比較中，CAPC 成本為 $0.0057，cache-only 則是在相同 q = 0.77 下花費 $0.0122——便宜 53%；27,917-token 文件的標題數字 78% 節省，是以品質下降 0.05 換來的，並非同品質比較。

AdaptiveCacheBoundary 將此方法延伸至呼叫之間會變動的提示。針對觀察到的 K 個版本，為每個句子位置建立指紋（正規化日期、數字、金額，以及空白；理由來自上述 tokenizer 發現），計算變動率 µ = 1 − max_h count(h)/K，分類為 STATIC（µ ≤ 0.05）/ QUASI（µ ≤ 0.30）/ DYNAMIC，並快取最長的連續 STATIC 或 QUASI 前綴。在三份真實且經過大量編輯的生產程式碼檔案上（每份 25 次提交），44–80% 的句子位置被分類為 DYNAMIC，找出的穩定前綴很短——12、17 和 749 個 token。即使如此，相較於快取整份檔案，仍省下 62.6–70.5%，完全是靠不快取易變的其餘部分達成。這個教訓不只適用於演算法：對頻繁變動的檔案而言，多數動態內容的快取寫入成本居主導地位，正確做法是幾乎什麼都不快取。

生產環境實際執行的結果#

三種提示形狀、三項驗證，結果彼此不同，而差異正是關鍵所在。

企業級工具使用助理——約 94,401-token 靜態前綴（1,312-token 系統提示加上 287 個 MCP 工具定義，約 93k token 的結構描述）。r = 3 的 CAPC 在模擬器中比 vanilla 減少 51.7%，走完整個生產程式碼路徑則減少 45.5%（命中率 99.1%，多回合工具使用回合數為 107，低於 vanilla 的 147——壓縮過的系統提示更具指示性）。有兩個結果比標題數字更值得注意：

Cache-only 只省下 18.3%，遠低於 LongBench-v2 的情境，因為 Anthropic 會隱式快取大型 tools= 陣列，完全不需要 cache_control 標記（vanilla 基準顯示，第一次呼叫後每次都讀取約 106k 個快取 token）。大部分「免費」快取效益早已到手。在這個情境下，CAPC 的價值幾乎全來自壓縮層。
不依賴查詢的壓縮，比具查詢感知的壓縮帶來更好的工具選擇（相較 vanilla 工具選擇的 set-IoU 為 0.700 對 0.603）。讓壓縮器看到查詢，會讓它保留與查詢相關的內容——而在這裡，這表示丟掉模型正準備選用的工具定義。均勻壓縮整份目錄反而勝出。

第二點與 Context Lifecycle Management 從情境管理角度指出的失敗模式相同：針對目前狀態最佳化的編輯，會摧毀原本屬於未來相依項目的物件。具查詢感知的壓縮器把這個失敗模式包裝成一項功能。

τ-bench 零售（50 項任務、多回合工具代理、確定性資料庫狀態獎勵，整個流程沒有任何 LLM judge）是論文中最乾淨的結果：

策略	平均每項任務成本	獎勵	相較 vanilla
vanilla	$0.1244	36/50	—
cache-only	$0.1252	37/50	+0.6%
具查詢感知（r=3）	$0.1744	38/50	+40.1%
CAPC（r=3）	$0.1145	36/50	−7.9%

CAPC 在任務完成獎勵與 vanilla 完全相同時（兩者皆為 36/50；雙比例 z = 0.00，p = 1.00）成本最低。具查詢感知的壓縮則是實驗中最昂貴的策略——比完全不壓縮、原樣傳送所有內容還貴。機制正如預測：每次呼叫都修改 wiki 系統區塊，讓快取寫入 token 從 vanilla 的 0.87M 升至 1.64M（+87%），而讀取端只省下一小部分。這是論文最有力的主張，也是最不容易受到評分器偏誤影響的一項。

但也要如實看待獎勵欄：具查詢感知的策略獲得最高獎勵（38/50），成本也最高；N = 50 時，四個策略的 95% Wilson 區間大量重疊。這項基準測試實際能判定的是成本排序，而非品質排序。

Knowledge-graph RAG（在 FastAPI 和 httpx 上使用 graphify）：在命中率 ≥85% 時，CAPC 相較於快取整張圖，成本分別降低 9.3 倍和 2.4 倍。可移植的發現關乎架構而非經濟——索引器輸出的是指標，不是內容（節點標籤、source_file、行位置、社群 ID），因此其價值完全取決於模型原本知道多少。在 Sonnet 4.6 熟悉的 FastAPI 上，結構中繼資料比什麼都不提供更糟（0.613，低於無圖基準的 0.647——新增行數稀釋注意力，卻沒有增加資訊）。在它不熟悉的 httpx 上，相同中繼資料則讓品質從 0.300 提升至 0.637。CAPC 實施的雙層切分——一層是快取、與查詢無關的索引層，另一層是逐查詢層，負責追查指標並傳送約 40 行實際原始碼——才是在兩種情境中都補上落差的關鍵。Knowledge graph 會索引內容；你仍得把內容送過去。

數字之外仍成立的精煉結論#

兩種代理工作負載使用相同技術，卻得到符號相反的結果：具查詢感知的壓縮在 τ-bench 上增加 40.1% 成本，在企業助理上則省下 31%。論文中最容易移植的主張解釋了這個落差：

具查詢感知的壓縮對成本的影響，會隨著壓縮器修改快取前綴的比例單調變化。

τ-bench 中，被修改的 wiki 區塊約占快取前綴一半，因此幾乎整個快取都被打破。企業助理中，壓縮器只碰了約 10% 的系統部分，而靜態的 94k-token tools= 陣列仍持續命中 Anthropic 的隱式快取——實際失效的快取位元組不到 15%，成本代價因此被掩蓋。所以，「具查詢感知 vs 不依賴查詢」是依修改比例參數化的光譜，而非二元標籤；同一點也適用於一般的快取寫入成本：關鍵不在於是否編輯提示，而在於你碰了多少快取區域。

同樣的精煉也適用於單純快取。LongBench-v2 上，cache-only 相較 vanilla 省下約 90%；在 94k 工具結構描述前綴上省下約 18%；在 9k-token τ-bench 前綴上則是**+0.6%（等於完全沒省）**。明確的 cache_control 標記會帶來少許寫入成本，只有當可快取前綴夠大時才划算；前綴較小時，隱式快取已取得效益，明確標記的淨效益就接近零。

乾淨模型失準之處#

讀者若要套用 r_max_safe，就得把以下限制納入考量：

超過門檻時 ρ = 1.0 的結果，在生產規模下不成立。 §3 測得 4k 至 8k token 的所有前綴，其 ρ 都是 1.0。但 94k-token 企業前綴與 262k-token 圖前綴，最後都只收斂到 約 85%；前 5–15 個查詢還會出現寫入量偏高的暖機期。論文將此歸因於「第 3.1 節的多伺服器複製機制」——§3.1 並沒有這種機制（已對照 PDF 確認；該節只報告階梯函數，沒有其他內容），而且 §3 宣稱有「四項實證發現」，實際只提出三項。因此，層級模型是在 2–8k 視窗內得出的乾淨實驗結果；用來調和此結果與生產規模下約 85% 命中率的機制，只被提出，從未實際描述。應把 T ≈ 3,500 視為超過此值的下限，而非保證上方 ρ = 1.0 的承諾。
隱式快取缺乏文件記載，卻是左右結果的關鍵。 供應商會快取大型 tools= 陣列，完全不需標記。已公布的定價模型沒有記載此行為；研究者是意外發現的，而且它會實質改變明確快取的價值。這類行為也可能在沒有版本說明的情況下改變。
一種模型、一種 TTL、一家供應商。 所有數字都是 Sonnet 4.6 在 2026 年 5 月、TTL 為 5 分鐘時測得。作者清楚區分哪些貢獻屬於通用架構（成本模型、交叉點分析、CAPC、比例上限、特性測量方法），哪些只是特定時點的觀察（T ≈ 3,500、ρ ≈ 0.83、支配比例）。
大多數品質數字由 Haiku 4.5 的自我一致性評分器評分，並以完整情境的答案作為參考；作者也揭露了一次事件：評分器呼叫觸及速率限制後，悄悄改用 0.5 預設分數，直到有人發現前都沒人察覺。只有 τ-bench 獎勵不使用評分器。
其中一份文件在 r ≥ 6 時出現依內容而異的品質懸崖，但因 N = 6，無法拆解是文件還是查詢造成。作者自己的結論是：維持層級的上限是必要條件，但還不夠；安全部署仍需要品質監控器。
簡單的帳務落差：企業助理模擬器在 §6.3 說是 15 個查詢，在 §7.1 又說是 40 個；成本一處為 $9.91，另一處為 $9.57。

從 harness 端提出的相同算式#

Writer 的 harness 交換論文（The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI，arXiv 2607.06906，empirical；相信任何幅度估算前，請先讀 Orchestration Sets Token Economics 的 COI 警示）獨立推導出本頁的成本模型，並以此建構產品。其有效輸入價格表達式相同，並明確標出命中率：

p_eff = p_in · (1 − h(1 − κ)), κ ≈ 0.1

其中 h 是以快取讀取方式提供的輸入 token 比例。附帶的主張才是有趣之處，而且談的根本不是快取：h 不是模型屬性，也不是供應商恩惠——它取決於不同回合之間提示的位元組穩定程度，而這完全由協調層組裝情境的方式決定。由於代理工作負載的輸入輸出比例接近 100:1，輸入項目幾乎構成整張帳單，因此harness 同時控制兩項因素——送出多少 token，以及主要 token 以什麼價格計費。他們的設計結論是採用雙區域提示：位元組穩定的前綴（工具結構描述目錄、穩定系統提示、只附加不改寫的持久逐字稿），每次工作階段最多設四個供應商斷點，並啟用一小時保留；易變尾端則每回合重建，且在結構上禁止納入前綴——這是以正確性規則強制執行，標記邏輯不允許在第一則易變訊息或之後放置斷點。

有兩點需要與此主張一併看待：

他們的標題快取數字是最佳情況，不是穩態。「7,876 個提示 token 中有 7,886 個（99.9%）以快取讀取方式提供」是在他們自家儲存庫內，測量一次前綴完全相同的呼叫。本頁的獨立數字顯示，生產前綴大小下的真實快取會在寫入較多的暖機期後收斂至 ρ ≈ 0.85–0.89；低於約 3,500 個 token 時，即使位元組完全一致的前綴仍約每六次就有一次未命中。位元組穩定是必要條件，顯然卻不足以保證命中；假設 h ≈ 1 的設計，是用它曾測得的最佳單次結果來估價。
**壓縮與快取經過共同設計，從另一端得出相同洞見。**他們把檢查點保留為持久資料列，並將重建後的提示當作新的可快取前綴，明確指出「若摘要器每個回合都改寫歷史，就會摧毀快取計價所依賴的前綴穩定性」。這就是本頁的修改比例精煉結論，只是以架構規則而非測量得出——也說明為什麼兩個來源在設計方向上相符，即使對可達命中率的看法不同。

TTL 選擇取決於閒置間隔分布，而非固定預設值（Uber，2026-08）#

本頁的交叉點規則把 α（寫入溢價）當成可代入的定價常數。Uber 說明其 harness 預設值的文章（Medisetty, 2026-08-27，case-study）則把Anthropic 兩種 TTL 之間的選擇（5 分鐘與 1 小時；按本頁符號分別為 α = 1.25 和 2.0）定價為工作階段中回合間隔超過較短 TTL 的頻率函數。文章以兩條實測時間軸演算，每條五回合，並與每回合都重新傳送完整情境相比：

主執行緒互動工作階段（間隔 2m/16m/3m/14m——工程師讀差異檔、開會、等待緩慢的工具呼叫）：四個間隔中有兩個超過 5 分鐘，所以 5 分鐘 TTL 會以 1.25 倍寫入費率重建兩次，總成本為 3.95 倍；相同間隔下，1 小時 TTL 從未過期，總成本為 2.40 倍，便宜 39%。
子代理工作階段（間隔 15s/20s/20s/30s——在 90 秒內啟動、工作並結束）：沒有任何間隔接近 5 分鐘，所以 5 分鐘 TTL 從未過期，總成本為 1.65 倍，便宜 31%；1 小時 TTL 則為這個工作階段用不到的持續時間保證付出較高寫入費率，總計 2.40 倍。

Uber 推出的預設值完全依照算式調整：主執行緒工作階段從預設 5 分鐘 TTL 改為 1 小時；子代理則維持 5 分鐘。兩條時間軸在相同的 2.40 倍總成本下，卻導向相反的 TTL 選擇——1 小時對一種流量形狀是便宜答案，對另一種則是昂貴答案，絕對成本卻相同。這是本頁的 ρ(N,|P|) 特性描述和交叉點規則未納入的變數：不只前綴有沒有重用，也要看重用在時間上如何分布；在 5 分鐘與 1 小時的選擇中，這比前綴大小更重要。無法將這些結果與本頁實測的 ρ 或 T ≈ 3,500 門檻比較——Uber 沒有公布快取命中率，只提供根據牌價演算的例子。

這如何改變 wiki#

「維持前綴穩定就能用便宜的快取命中」只在高於門檻時成立。Agent Context Files、Hermes Agent 和 Client-Side Agent Optimization 都包含實務規則：穩定的系統提示能讓後續訊息大幅便宜（practitioner-opinion，Nous Research 文件）。實測顯示，低於約 3,500 個 token 的穩定前綴仍有約 17% 的未命中率；在小前綴代理工作負載中，明確的 cache_control 僅帶來**+0.6% 的成本，也就是完全沒有省到**。此規則的方向正確，但無條件適用的說法不成立。
裁剪情境有下限。Context Lifecycle Management 的快取感知提交法會比較情境編輯成本與它造成的前綴快取破壞。CAPC 從底層補上限制：若把保留的前綴縮到約 3,500 個 token 以下，就會掉入熱層級；壓縮強度只增加一格，成本可能反而上升約 77%。token 縮減政策會增加帳單有兩個獨立原因——一個是編輯前綴，另一個是把前綴縮得太小。
壓縮文獻仍以 token 計價，如今這點已有明確證據，而非推論。Not Worth Another Token: Marginal Value Estimation for Efficient Deep Research Agents（arXiv 2608.08389，2026-08-09，empirical）研究情境裁剪，共有 40 組設定，明示研究主題是成本；但附錄 A.4 將「成本」定義為各紀錄階段的輸入加輸出 token 總和，結果表的 Cost 欄組讀作 # Tokens + Runtime (s)。文中完全沒有美元金額。本頁的交叉點規則讓這個差距變得重要，而非吹毛求疵：token 減少是否能降低帳單，要看減少的是哪些 token，以及是否碰到快取前綴；該論文本身的帳務資料提供了這些項目——早期裁剪組移除輸出 token 的速度比輸入快（Sonnet 4.6 的定價卡上輸出 token 費率是輸入的 5 倍，且從不享有快取折扣），而晚期裁剪組只移除輸入，正是本頁測得成本增加 40.1% 的修改前綴情境。按已公布價格計算、且不建模快取時，各階段的美元差距會擴大（早期組減少 71.1% / 74.5%，而 token 減少 69.5% / 73.3%），晚期組的美元差距則會縮小（7.2%，而 token 減少 11.5%）——因此，用 token 百分比宣傳結果不只是無法精確反映帳單，還會因階段不同而朝相反方向錯估。完整算式見 Tool-Output Pruning。
同一成本還有第三個槓桿，而且可能與前兩者衝突。本頁比較快取與壓縮；Shopify 的 Sidekick 說明（Shopify Engineering，2026-08-05，case-study，第一方且尚未重複驗證）推出了gist compression——以相同模型執行兩次，teacher 使用完整系統提示，student 使用一小段學得的 gist token 嵌入；在凍結模型權重的情況下，訓練嵌入以匹配 teacher 的輸出分布，再部署 student。報告結果：約 6,000 個 token 降至約 1,500 個，且*「評分器未測得品質損失」。他們對問題的診斷與本頁如出一轍：「代理的系統提示很長且固定。注意力會隨序列長度擴展……長提示是每次請求都要支付的延遲與服務成本固定稅。」從結構來看，這是把 CAPC 的做法推到極限——在請求路徑之外，以不依賴查詢的方式壓縮一次——並且更進一步：壓縮區塊不是文字，因此其位元組穩定性由設計保證，壓縮器永遠不會碰到快取區域。依本頁的標準，有兩點使它不能直接視為勝利。(1) 這些數字不能與本文任何數字直接比較：TTFT −19%、端對端延遲 −38%、每秒請求數 +16%、每秒輸出 token 數 +12%，以及「GPU 數量約減少 14%」*，都是在每分鐘 350 個請求的負載測試中量得的自架服務指標，不是 API 實際計費成本；文章中的美元數字則是另一項推算。(2) 在代管快取上，低於門檻時，兩種槓桿會互相牴觸：r_max_safe = floor(|D|/T) 顯示，在 Sonnet 4.6 的 T ≈ 3,500 下，6,000-token 前綴安全壓縮的 r 上限為 1；1,500 個 token 明確落在熱層級，即使位元組完全一致的前綴仍約每六次有一次未命中。Shopify 自行託管權重，因此不需支付寫入溢價，也不會遇到這種取捨——這正是重點：學得的壓縮是取代快取還是與它衝突，取決於誰擁有服務堆疊；目前沒有人測量過兩者的組合效果。
token 軸線指出 Cost-per-Task Over Cost-per-Token 這件事：沒有人公布，而有人公布了。該頁長期指出，供應商只印出價格，從不公布每項任務的 token 數。這裡有第三方同時列出兩者，並將總支出與供應商帳單核對至 1% 以內；整個端對端預算為$98.96，任何團隊都能重現。它也提出更尖銳的論點：每 token 價格根本不是固定常數——而是快取狀態、前綴大小和呼叫次數的函數；所有成本感知路由論文卻都把這個項目視為固定值。

延伸閱讀#

Cost-per-Task Over Cost-per-Token——來源的完整成本公式、Pareto 模型選擇基準，以及其他 token 縮減槓桿列表；本頁按閒置間隔選擇 TTL 的章節也從該頁連結至此
Orchestration Sets Token Economics——從 harness 角度推導出相同有效輸入價格模型，並將其化為設計規則（雙區域提示、位元組穩定性作為正確性不變條件、快取感知壓縮）；主張快取命中率是協調層屬性，而非供應商或模型屬性。文中的 99.9% 快取讀取率是在供應商自己的儲存庫中測量一次前綴完全相同的呼叫；本頁實測顯示這是上限，而非穩態
Context Lifecycle Management——從情境角度探討同一聯合問題。Self-GC 為破壞性前綴編輯定價（CommitBenefit ≈ N_future·(C−C′) − L_cache_break − L_GC，預期裁剪率超過 0.3 才提交）；CAPC 提供此門檻所屬的參數式形式，並補上底線限制（快取前綴不可裁剪至低於約 3,500 個 token）。兩者的失敗模式也相似：Self-GC 主張編輯只有在物件不是未來相依項目時才安全，這正是具查詢感知的壓縮在工具選擇上不如不依賴查詢壓縮的原因——壓縮器針對目前查詢最佳化，丟掉模型正準備呼叫的工具。該頁現在也收錄了本頁試圖推翻的最清楚假設：Maximem 的 ACM 成本模型（arXiv 2607.21503，empirical，由供應商撰寫）推導完整附加的成本為 O(n²)，而有界方案為 O(n)，接著假設不考慮快取——「忽略快取折扣；它會改變常數，但不改變漸近複雜度。」漸近分析正確，實際操作方向卻相反：寫入溢價 α > 1、約 3,500 token 以下的未命中，以及 τ-bench 上 +40.1% 的結果，全是常數因子效應，而每個提交或保留的決定都由常數主宰
Cost-per-Task Over Cost-per-Token——實測缺少的 token 軸線：總計費支出與供應商帳單核對至 1% 以內，並證明每 token 價格取決於快取狀態，而不是固定常數。本頁主張倒過來看最鮮明的例子：一種減少 3 倍 token、卻讓帳單增加 40.1% 的技術
Client-Side Agent Optimization——AgentOpt 將快取列為用戶端槓桿，Hermes 表格也將「工作階段中途不要破壞提示快取」列為部署風險。此處為該風險補上成本模型、設計規則和實測失敗：快取黏著性正是 AgentOpt 先前成本感知路由方法視為靜態模型價格的項目；作者也指出，將 ρ(N,|P|) 與路由器結合是後續研究方向
Agent Context Files——來自靜態角度的快取穩定性規則（在工作階段內不要修改情境檔案）。本頁從兩個方向精煉此規則：低於層級門檻時，穩定性仍不足以確保命中；要求 token 嚴格一致的快取，則能容忍前導與尾隨空白編輯，因為 tokenizer 會在建立快取鍵之前將空白正規化
Tool-Output Pruning——有兩種尚未計價的快取互動，也是本頁警告最鮮明的實際案例。若要讀取工具回應的骨幹隱藏狀態，就得刻意擊敗該片段的前綴快取：SWE-Pruner Pro 特別透過 SGLang 的請求路徑傳遞 hidden_states_start_len，以限制 max_prefix_len；由於 radix 快取只儲存 KV、不儲存隱藏狀態，這會迫使快取位置重新通過前向傳播。接著，將裁剪後的回應放回歷史記錄，又會在下一回合使後綴失效；這相當於每回合都發生一次 Context Lifecycle Management 的提交中斷，而不是在選定的邊界發生。論文報告 token 數、API 呼叫次數和耗時（整體額外成本 15.0%），卻從未計算帳單；而在其中一個骨幹模型上，論文自己的 SWE-Bench 數字顯示輸入 token 反而增加 7.4%，API 呼叫次數也從 94.8 升至 111.8。這正是 τ-bench 的情況：每次呼叫的 token 變少，不代表花的美元變少
Repository Exploration Subagent——程式碼庫知識的同一個最後一哩問題。FastContext 不把探索結果塞進解題器的視窗，而是回傳精簡的檔案與行號引用；CAPC 的 graphify 研究則顯示，若精簡回傳內容只有指標，在模型熟悉的程式碼庫上甚至比完全沒有圖更差（0.613 對 0.647）；在模型不熟悉的程式碼庫上則大幅提升（0.637 對 0.300）。兩者最後都指向同一做法：傳送少量實際內容，而不只是位置
Out-of-Band Prompt-Injection Defense——成本研究以外的前綴快取保留設計限制：APPA 會採用分支而非重新合成情境，因為子項共用完全相同的 token 前綴；它也會在執行開始時註冊補救工具，特意避免在執行途中使快取失效。本頁算出這些選擇為何值得
Context Window Smart Zone——保持提示較小的另一項理由；請注意這兩個目標可能衝突，因為符合成本最佳化的快取前綴有下限，符合注意力最佳化的前綴則沒有
Knowledge-Centric Self-Improvement——本頁定價的設計模式已在實際系統中採用：每個論壇提示都建構成 ForumPromptParts 配對——包含代理與生成方式皆不變的 cacheable_prefix（任務 ID、描述、工具清單、回合指示、輸出結構描述），唯一的 cache_control 標記也在其中；以及逐代理變動的 variable_suffix（先前嘗試、工作階段記憶、同儕貼文），以一般區塊附加。其成本表也按已公布的快取寫入和讀取費率計算，讓快取特性不同的方法仍可公平比較——這種帳務紀律正是本頁的主張，並由一篇主題並非快取的論文採用
Agent Quality Flywheel——上述同一個靜態前綴成本的第三種槓桿：gist compression 把系統提示訓練到約 1,500 個學得的嵌入，而非讓它能以低成本重讀；在自架堆疊上極度適合快取，在代管堆疊上則低於本頁的層級門檻。它也是唯一提供生產環境前綴壓縮技術實例的來源，報告的效益是 GPU 和延遲，而非帳單
Inference Efficiency as Capability——同一種快取，但從下一層著手，以工程方式處理，而非計價。該頁追蹤快取 token 占用多少空間：Gemma 4 將全域快取縮小 37.5%；Keyless Attention（arXiv 2606.21848，empirical）則直接刪除 key 投影，讓 Value-Only Cache 在 8,192 個 token 時恰好減半——0.118 對 0.236 GB。本語料庫沒有任何內容將位元組節省換算為費率：每 token 占用空間減半，是本頁所測層級門檻和 12.5 倍寫入／讀取價差背後的資源；但沒有供應商公布快取容量如何對應快取價格，因此「快取」的架構帳本與帳單帳本仍未接合
Anthropic——本頁測量的對象是這家供應商的快取行為、定價，以及未公開的 tools= 隱式快取

開放問題#

兩階段階躍在生產前綴大小下仍成立嗎？還是門檻以上的真實穩態命中率處處都只有 ρ ≈ 0.85？§3 在 4k–8k token 測得 ρ = 1.0，而 94k 和 262k 工作負載最後都收斂到約 85%；論文用來調和結果的「多伺服器複製」機制卻從未真正描述。
大型 tools= 陣列的隱式快取，是有文件記載且穩定的供應商行為，還是某種路由設定的副作用？它大幅改變工具密集型代理中明確 cache_control 的價值，而且是意外發現，並非刻意驗證。
快取前綴有多少比例被修改時，具查詢感知的壓縮會從省錢變成增加成本？兩種生產工作負載在此軸線上分別落於約 15%（省下 31%）和約 50%（增加 40.1%），但沒有來源測量中間的曲線。
快取與學得的提示壓縮是互補、替代還是互相衝突？gist 壓縮前綴依設計可保持位元組穩定（非常適合快取），卻小到會低於本頁的層級門檻（此時即使位元組完全相同的前綴仍會未命中）。可證偽的驗證方式是：在同一堆疊上，以三種方式提供同一個靜態前綴——完整前綴 + cache_control、gist 壓縮，以及 gist 壓縮 + cache_control——並同時報告實際計費成本或 GPU 時數和品質，直接測量組合效果，而非停留在辯論。唯一在生產環境使用 gist token 的來源自行託管權重，因此根本不需面對寫入溢價。
按閒置間隔選擇 TTL 的方法，能否從人工區分主執行緒與子代理，推廣為測量工作階段實際間隔分布、動態挑選 TTL 的政策？一旦以實測 ρ 取代 Uber 的牌價算術，5 分鐘和 1 小時總成本相同的交叉點會不會移動？

資料來源#

Sidekick's continual learning loop——Andrew McNamara 與 Cody Mazza-Anthony，Shopify Engineering，2026-08-05，case-study（作者自家生產系統的第一方說明；未重複驗證，也沒有受控組）。本頁僅引用其中 「Compress the prompt to serve it faster」 段落：凍結權重的 gist teacher/student 架構、約 6,000 → 約 1,500 token 數字（已由文章自有的 System prompt vs gist tokens 示意圖確認，圖中沒有新增數字），以及每分鐘 350 個請求負載測試的變化（TTFT −19%、端對端 −38%、每秒請求數 +16%、每秒輸出 token 數 +12%、GPU 數量約減少 14%）。這些是自架服務指標，不是 API 實際計費成本，不能與本頁任何美元數字比較；文章的 $27M → $1M 是根據「平均 token 成本」所作、帶有情態保留的推算，並非帳單。完整來源分析見 Agent Quality Flywheel
Not Worth Another Token: Marginal Value Estimation for Efficient Deep Research Agents——Kolukuluru、Ashok、Arora、Ciccarelli、Ashok Kumar、Nie、Dernoncourt、Basu、Rossi 與 Lipka（UMass Amherst / UT Austin / Adobe Research），Not Worth Another Token: Marginal Value Estimation for Efficient Deep Research Agents，arXiv 2608.08389，2026-08-09，empirical。本頁僅引用其成本慣例和輸入／輸出區分：附錄 A.4（成本的 token 計數定義）、表 5（Cost 欄組為 # Tokens + Runtime (s)），以及表 10（逐設定的輸入／輸出 token 數，可據此換算 token 成美元）。論文從未提及快取。以上美元重建數字是 wiki 依 Sonnet 4.6 已公布費率、且不建模快取狀態所做的算術；僅供說明，並非實測。各表判定及論文內三處數字矛盾，記錄於 Tool-Output Pruning
The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI——Sayed Ali 等人（33 位作者，全部來自 Writer, Inc.；arXiv 2607.06906，2026-07-08，empirical，完全受供應商利益衝突影響）：§3.1 的有效輸入價格表達式及輸入量約為輸出的 100:1 主導比例；§4.3(1) 的雙區域提示與 7,876/7,886 前綴完全一致時的快取讀取測量；§4.3(2) 的壓縮與快取共同設計。原始解析中的表 2 儲存格遭合併，表 7 列位移；本文不引用兩表
Running a Software Factory Efficiently at Uber Scale——Uday Kiran Medisetty，Uber Engineering 部落格，2026-08-27（case-study，第一方）：按閒置間隔選擇 TTL 的時間軸演算（圖 6），以及 Uber 已推出的主執行緒／子代理 TTL 區分。不是由 PDF 取得，沒有 docling 表格解析風險。完整成本公式分析見 Cost-per-Task Over Cost-per-Token；各來源筆記見 Sources
Cache-Aware Prompt Compression: A Two-Tier Cost Model for LLM API Caching——Yan Song（PayPal），Cache-Aware Prompt Compression: A Two-Tier Cost Model for LLM API Caching，arXiv 2607.15516，2026-07-17，empirical。§3（ρ(N,|P|) 特性描述：T ≈ 3,500 的兩階段階躍、表 2、token 嚴格一致的失效判定與空白正規化例外、帳單核對誤差在 <1% 以內，以及 Sonnet 4.6 精確費率表）；§4（各策略成本表達式、以價格形式和 α/β 無因次形式表示的 ρ_cross(r) 交叉點、四種定價／基礎設施敏感度情境）；§5（CAPC 流程、維持層級的上限 r_max_safe = floor(|D|/T)，AdaptiveCacheBoundary 的 STATIC/QUASI/DYNAMIC 分類和真實 git 歷史驗證，見表 6）；§6（表 7 的 16/16 支配網格、表 8–9 的成本—品質 Pareto 掃描、表 10–11 的企業助理、表 12–13 的 graphify FastAPI/httpx、表 14 的 τ-bench 零售、$98.96 明細預算）；§7（tools= 隱式快取、修改比例精煉結論、單模型／單 TTL 範圍、LLM 評分器警示，包含未被察覺的 0.5 預設值回退，以及依內容而異的品質懸崖）。依據圖片兩階段規則查看圖 1 和圖 2——兩者都直接證實階躍：2.4k token 時 ρ 從 0.47 上升至 0.89，低 N 時誤差範圍很大；4k/6k/8k 曲線則從 N = 5 起平貼在 ρ = 1.0。注意：表 1（定位網格）原始解析中的儲存格遭合併，表 9 的品質註記有位移（2026-09-07：兩處均已依 PDF 手動修復原始資料；verify.py 現在回報 ok）——本文引用的表 9 數值（$0.0122 / q=0.77，以及 cache-only 的 $0.0323 / q=0.77）均直接從 PDF 取回；其他所有引用數字也都取自正文、圖說，或經正文核對的表格。Docling 也把所有 em dash 正規化為連字號（外觀差異）。2026-09-07：表 9 位移已依 PDF 手動修復原始資料；解析後的兩個數值現已相符