不一定。
假設你剛剛把 Claude Prompt Cache 設定好了。
第二次執行後一看：
cache_read_input_tokens
非常高。
你可能會很自然地想：
「太好了，這個 AI 工作現在一定便宜很多。」
方向可能是對的。
但還不能直接下結論。
因為 Prompt Cache 真正降低的是：
重複讀取那一段既有 Context 的成本。
不是替整個 AI 工作打：
75% 折扣。
先搞懂 Cache Hit 到底證明什麼
Claude API 會把輸入使用量拆成幾部分。
其中包括：
cache_read_input_tokens
代表這次從既有 Cache 讀取的 Token。
cache_creation_input_tokens
代表這次建立新 Cache 的 Token。
input_tokens
則主要是沒有從 Cache 讀取、位於 Cache 後面的新 Input。
所以當你看到：
Cache Read 很高，
真正能確認的是：
這一次有大量 Prompt Prefix 沒有重新按照一般 Input 價格處理。
這當然是好事。
但它回答的是：
「背景資料有沒有成功重複利用？」
還沒有回答：
「整件工作到底花多少錢？」
Fable 5.1 的 Cache Read 確實非常便宜
Claude Fable 5.1 目前每百萬 Token 的一般 Input 價格是：
10 美元。
5 分鐘 Cache Write：
12.50 美元。
1 小時 Cache Write：
20 美元。
Cache Read：
只要：
0.25 美元。
所以同樣 100 萬 Token，
如果真的已經存在有效 Cache，
從 Cache Read 取得，
確實比重新用一般 Input 處理便宜很多。
但你不能只看這一格。
因為模型還是要處理「今天新增的東西」
假設一個 Agent 每次工作都有：
100,000 Token 固定專案背景。
這次 Cache 全部成功命中。
很好。
但今天又加入：
50,000 Token 新文件。
這 50,000 Token 並沒有因為前面的 Cache Hit，
自動變成 Cache Read。
它仍然是新的 Input。
所以真正的請求不是：
「100,000 Token 全部很便宜。」
而是：
固定背景便宜地重用＋今天新資料正常處理。
這兩塊都要算。
還有一塊經常更貴：Output
Claude Fable 5.1 的 Output Token 價格目前是：
每百萬 Token：
50 美元。
比一般 Input 更高。
所以你可能碰到一個很有趣的情況：
Prompt Cache 做得非常漂亮。
背景資料幾乎全部命中。
但是你要求 AI：
產生超長研究報告。
寫大量程式碼。
列出幾十種方案。
反覆解釋每一步。
最後 Output 很長。
那麼：
Input 省下來了，Output 帳單仍然可能很大。
所以「Cache Hit 很高」不能直接等於：
「這次 API 很便宜。」
更麻煩的是 Agent 不一定只呼叫一次模型
一般聊天可能是：
Input。
Output。
結束。
Agent 工作可能完全不同。
它可能：
讀資料。
思考。
呼叫工具。
拿回結果。
再呼叫模型。
發現錯誤。
重新規劃。
再用工具。
再呼叫模型。
最後整理結果。
因此你看到的其實不是：
一個 Prompt 的成本。
而是：
整條工作流程很多次推理加起來的成本。
有些迭代可以吃到 Cache。
但每一輪仍可能產生新的：
Input。
Output。
Tool Result。
甚至其他模型呼叫。
所以高 Cache Hit，可能只是代表「其中一部分做得很有效率」
可以想像一家印刷店。
每天都使用同一份：
品牌規範。
紙張規格。
印刷模板。
這些固定資料都已經準備好了。
今天不用重新整理一次。
很好。
但第一個客戶只要：
改一個日期。
很快完成。
第二個客戶卻要求：
重寫全部內容。
產生 30 頁。
修改 5 次。
重新校稿。
重新輸出。
兩件工作都用了：
完全相同的固定模板。
固定背景重用率一樣高。
但最後總成本顯然完全不同。
Prompt Cache 也是一樣。
那 Cache Hit Rate 到底該怎麼看？
Anthropic API 提供的是：
Cache Read Tokens。
Cache Creation Tokens。
一般 Input Tokens。
Output Tokens。
你可以利用這些 Usage 數字，
自己建立適合工作流程的 Cache 指標。
例如想知道：
這一次所有輸入裡，
有多少比例來自既有 Cache。
可以比較：
Cache Read Tokens
和：
整體 Input Token 結構。
但這是你建立的營運指標。
不要把它誤認成：
「品質分數」。
Cache Hit 只是在描述：
Context 重複利用程度。
Cache Hit 也完全不代表答案比較正確
這一點更重要。
假設你 Cache 的是：
公司退款政策。
但那份政策其實已經過期。
接下來：
Cache Hit 100%。
代表什麼？
代表 AI 非常有效率地：
反覆讀取同一份過期政策。
Cache 沒有能力替你判斷：
這份資料是不是最新版。
它只是讓：
相同 Context
不用一直重新處理。
所以：
Cache 效率
和：
資料正確性
是兩個完全不同的問題。
甚至可以「更便宜地做錯很多次」
這就是最危險的誤解。
假設一個客服 Agent 原本每次呼叫成本比較高。
加上 Prompt Cache 後：
成本下降。
於是公司開始讓它：
每天跑更多次。
但它使用的：
產品規則錯了。
Tool Definition 有問題。
分類邏輯錯了。
或回答經常需要人工重寫。
這時你可能得到：
非常漂亮的 Cache 指標。
API 單次成本也下降。
但公司真正得到的是：
更便宜地產生更多需要修改的結果。
這不叫真正的成本優化。
所以真正該看的不是「一次呼叫多少錢」
而是：
Cost per Usable Task。
也就是：
完成一件真正可以使用的工作，
到底花多少錢？
這比：
單次 API Cost
更有意義。
假設流程 A：
一次 API 成本 0.20 美元。
10 次裡只有 5 次可以直接使用。
另外 5 次都要重跑或人工修改。
流程 B：
一次成本 0.30 美元。
10 次有 9 次可以直接使用。
只看：
單次 Token 成本，
A 比較便宜。
看真正完成的工作，
答案就不一定了。
這和我們之前談 AI ROI 是同一個問題
之前 SasaDaily 已經談過：
「AI 成果可直接用比例很高」
不代表 ROI 一定很好。
反過來也一樣：
「AI Token 成本很低」
也不代表 ROI 一定很好。
因為公司真正付出的成本還有：
人工修改時間。
重新執行。
錯誤處理。
驗證。
維護。
Agent 失敗後的人工接手。
真正值得追蹤的是：
整條工作最後有沒有：
省時間。
省成本。
提高成功率。
或創造更多價值。
那應該同時看哪些數字？
如果你真的要評估 Prompt Cache 是否值得，
至少可以一起看五件事。
第一：
Cache Read Tokens。
固定 Context 到底有多少真的被重複利用？
第二：
Cache Creation Tokens。
是不是一直重新建立 Cache？
如果每次都 Cache Miss，
只是不斷付 Cache Write 成本，
就要檢查 Prompt 結構。
第三：
Output Tokens。
Input 省很多，
Output 是否反而愈來愈長？
第四：
成功率。
工作有沒有真正完成？
第五：
人工修改量。
完成後是不是還要花很多時間修？
這五個一起看，
才比較接近：
真正的成本。
還有一個常被忽略的成本：Cache Miss
5 分鐘 Cache 的 Write 價格，
對 Fable 5.1 是一般 Input 的：
1.25 倍。
1 小時 Cache Write 則是：
2 倍。
也就是：
建立 Cache 本身不是免費的。
你真正期待的是：
建立一次之後，
後續多次利用便宜的 Cache Read。
如果：
剛建立就過期。
Prompt 每次都改。
Prefix 一直變。
或使用頻率太低。
結果可能一直變成：
Write。
Write。
Write。
卻很少：
Read。
這時「有使用 Prompt Cache」
不代表「Prompt Cache 有省錢」。
5 分鐘和 1 小時也不是愈長愈好
Anthropic 預設 Cache TTL 是：
5 分鐘。
每次成功使用，
會重新刷新。
如果 Agent 在短時間連續跑很多步，
5 分鐘通常就很合理。
1 小時 Cache 適合的是：
下一次需要同一段 Context，
經常會發生在：
5 分鐘以後。
1 小時以內。
因為 1 小時 Cache Write 比較貴。
所以不能看到：
「1 小時保存比較久」
就直接全部改 1 小時。
真正該問：
我的工作多久會再次讀同一份 Context？
如何知道 Cache 到底有沒有真的命中？
不要猜。
Claude API 的 Usage 會直接提供：
cache_read_input_tokens
如果有數字，
代表這次真的從 Cache 讀取。
如果：
cache_creation_input_tokens
和：
cache_read_input_tokens
都一直是 0，
就代表這份 Prompt 並沒有真的被 Cache。
Anthropic 也提醒：
內容太短、沒有達到最低 Cache 長度時，
系統可能直接正常處理，
但不會建立 Cache。
所以：
「我有寫 cache_control」
也不等於：
「這次一定 Cache Hit。」
還要注意工具本身也可能影響 Cache
Agent 的 Context 不只有：
文字 Prompt。
還可能包含：
Tool Definitions。
Tool Results。
Web Search。
Browser。
Computer Use。
某些工具設定改變，
也可能影響前面的 Cache。
例如 Anthropic 官方指出，
啟用或停用 Web Search，
會讓相關 System／Messages Cache 失效。
這代表：
Agent 架構愈複雜，
Cache Optimization 就愈不能只看：
「我的 System Prompt 有沒有改。」
工具也屬於 Context 的一部分。
所以什麼才算真正好的 Prompt Cache？
不是：
Cache Read Tokens 永遠最高。
而是：
該重複的東西成功重複。
固定的：
System Instructions。
Tool Definitions。
專案背景。
大型文件。
範例。
能穩定重用。
新的：
問題。
資料。
任務。
則正常處理。
最後整體：
成本下降。
延遲下降。
品質沒有下降。
人工修改沒有增加。
這才叫有效。
一個很實用的檢查方式
如果你今天剛把 Prompt Cache 做好，
不要只比較：
昨天 0 Cache。
今天 80% Cache。
而是建立一個很小的比較表。
看：
每件工作總成本。
平均 Output。
成功完成比例。
需人工修改比例。
失敗／重試次數。
Cache Read Tokens。
跑個：
20 次。
50 次。
甚至 100 次。
再看趨勢。
因為真正的問題不是：
「Cache 有沒有工作？」
而是：
「Cache 有沒有讓整個工作變得更有效率？」
最後回答今天的問題
Claude Prompt Cache Hit 很高，
是好訊號。
它表示：
你的固定 Context 很可能正在被有效重複使用。
尤其 Fable 5.1 把 Cache Read 降到：
每百萬 Token 0.25 美元後，
這對大型 Agent 確實可能帶來很明顯的成本優勢。
但高 Cache Hit 本身不能證明：
總帳單一定最低。
工作一定成功。
Output 一定合理。
資料一定最新。
或結果一定可以直接使用。
真正該追求的不是：
最高 Cache Hit。
而是：
最低的「每件可用成果總成本」。
因為 AI 真正替你工作的時候，
你付錢買的不是：
Token。
你真正想買的是：
一件完成、正確，而且不用重新做的工作。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 快問快答｜2026/08/10：AI 成果「可直接用」比例很高，就代表 ROI 一定很好嗎？
AI 一分鐘教學｜2026/08/10：別只記 AI 成本，每次結果先標成「可用、需修改、失敗」
今日 AI 工具｜2026/08/10：Langfuse，把 AI 每次花多少錢、跑多久、結果好不好記下來，不再只看總帳單
