聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

Day 2 埋了一個數字：快取命中只算 0.1 倍 input 價，是四種計價光譜裡最便宜的一格。Day 8 又埋了一個直覺：把「穩定不變的內容」跟「每次都變的內容」分開放。

今天把這兩件事合起來，講完整的 Prompt Caching。

先講一個容易誤解的地方：很多人以為快取是「Claude 記得我們聊過什麼」，像人腦的記憶一樣。不是。 快取是一個更機械、更純粹計價層面的機制——它讓你不用為「同一段已經送過的內容」重新付全額，僅此而已。它不會讓 Claude 更懂你,也不會跨對話保留記憶。搞懂這個邊界,你才知道快取解決的是什麼問題、不解決什麼問題。

本篇規格、倍率與行為細節，對照 Prompt caching 官方文件 查證。

目錄

一、快取在做的事，只有一件：記住前綴的雜湊

官方對快取的核心說明其實很機械：在內容區塊上標記 cache_control，等於寫入一筆快取——「從開頭到這個標記點的內容」的雜湊值。 之後的請求如果前綴（開頭那一段）跟這筆記錄一致，就算命中，用 0.1 倍價讀取；不一致，就得重新寫入。

這代表快取比對的是內容前綴，不是語意、不是主題、更不是「這是同一個使用者」。你昨天問的問題如果今天再問一次但整段文字一字不差，也不會自動命中——除非你把它結構化成會被重複讀取的前綴。

啟用方式有兩種：

自動快取（Automatic caching）：在請求最外層放一個 cache_control，系統自動套用到最後一個可快取的區塊，並且隨著多輪對話自動往前推進快取點——每一次新請求都把「上一輪為止」的內容當作可讀取的快取，新增的部分才是新寫入的。

顯式快取斷點（Explicit breakpoints）：直接在特定內容區塊上放 cache_control，最多可設 4 個斷點，適合「不同區塊變動頻率不同」的情境——例如工具定義幾乎不變、大段背景資料一天更新一次、使用者訊息每次都不同，這時分開設斷點比整段自動快取更有效率。

兩種方式可以混用，自動快取會佔用 4 個斷點中的一個。

二、計價：從 1.25 倍到 0.1 倍，中間差了 12.5 倍

用 Opus 5（input 基準價每百萬 token $5）為例，四種 token 各自的價格：

寫入比一般 input 貴——5 分鐘版本貴 25%，1 小時版本貴一倍。但只要被讀到一次，5 分鐘版本就已經回本（寫入 1.25×，讀取只要 0.1×）；1 小時版本則需要被讀到兩次才划算。

TTL（存活時間）的計算方式也值得記住：存活時間是從「寫入或讀取那筆快取的請求開始」算起，不是從回應結束算起。 換句話說，模型生成回應花的時間，也算在這 5 分鐘或 1 小時裡——如果你的請求本身處理得很慢，留給下一次命中的時間窗其實比你想的短。

三、多長的內容才「值得」被快取

快取有最小可快取長度的門檻，短於這個長度的內容，就算標了 cache_control 也不會真的被快取——不會報錯，就是安靜地不生效：

怎麼確認自己是不是真的命中了？看回應的 usage 欄位：

{
  "cache_creation_input_tokens": 5120,
  "cache_read_input_tokens": 1800,
  "input_tokens": 50
}

如果 cache_creation_input_tokens 和 cache_read_input_tokens 都是 0，代表這次請求完全沒有被快取——可能是內容太短，也可能是前綴不一致（下一節講原因）。三個欄位加總，才是這次請求實際的總 input token 數。

四、快取為什麼突然失效？回溯窗口與破壞快取的動作

快取讀取採向後查找：系統在你設定的斷點位置往回檢查最多 20 個區塊，找是否有先前寫入過的匹配前綴。這代表快取斷點不能離「真正穩定的內容」太遠，否則可能超出查找範圍而找不到。

官方文件裡有個很實用的除錯案例：如果你的 prompt 結構是「五段固定不變的系統資訊（區塊 1-5）+ 一段每次都帶時間戳的請求內容（區塊 6）」，而你把 cache_control 設在區塊 6，那麼查找永遠找不到匹配——因為時間戳每次都不同，區塊 6 本身從來不會重複。正確做法是把斷點往前移到區塊 5，也就是「最後一個跨請求維持不變」的區塊。

會讓快取整段失效的常見動作：

• 改變工具定義（名稱、描述、參數）→ 工具、系統、對話快取全部失效
• 切換 web search 或 citations 等功能開關 → 系統與對話快取失效
• 改變 tool_choice → 對話快取失效
• 新增或刪除圖片（不論在 prompt 哪個位置）→ 對話快取失效
• 改變 thinking 設定（模式或 budget_tokens）→ 對話快取失效

特別提醒（呼應 CLAUDE.md 已記錄的重點）：改變 output_config.effort 的值，會讓對話快取失效——對工具快取與系統快取的影響則跟 thinking 參數一樣，依模型而定。如果你的應用會動態調整 effort（例如依任務難度切換），要有心理準備：每次切換都可能打掉這一段的快取，Day 14 會再展開 effort 的完整用法。

五、Before / After：把穩定內容搬到前面

❌ Before：把常變動的內容跟穩定內容混在一起

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    system=f"現在時間：{datetime.now()}\n\n{COMPANY_STYLE_GUIDE}",  # 時間戳在最前面，每次都不同
    messages=[{"role": "user", "content": user_question}],
)

✅ After：穩定內容在前、標記快取，變動內容放後面

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": COMPANY_STYLE_GUIDE,          # 穩定不變的規格書
            "cache_control": {"type": "ephemeral"},
        },
        {
            "type": "text",
            "text": f"現在時間：{datetime.now()}",  # 每次都變的部分，放在快取斷點之後
        },
    ],
    messages=[{"role": "user", "content": user_question}],
)

Before 版本把時間戳放在最前面，等於每一次請求的前綴都不一樣——快取永遠找不到匹配，cache_control 標了等於白標。After 版本只做一件事：把會變的東西挪到快取斷點後面。這正是 Day 8 技巧五那句話的完整版本：「把穩定不變的內容跟每次都變的內容分開放」。

如果你的規格書本身超過 512 tokens（多數公司風格指南、產品文件都輕鬆超過），這個改動能讓第二次以後的每一次呼叫，那一大段固定內容只算 0.1 倍價錢。

六、Batch 處理也能疊加快取（先劇透 Day 10）

快取不只用在即時請求上。Message Batches API（Day 10 主題）也支援 prompt caching，而且快取折扣可以跟批次的 5 折疊加。差別在於批次請求是非同步、並行處理的，快取命中屬於「盡力而為」，命中率官方觀察值落在 30% 到 98% 之間，取決於你的流量模式——這也是為什麼想在批次情境用好快取，得讓多筆請求共用完全相同的 cache_control 結構，並維持穩定的送出節奏。

七、不寫程式的人，快取怎麼幫你省？

看到這裡你可能想問：上面全部都在講 cache_control 這個參數，那我平常是在終端機裡用 Claude Code、或在編輯器裡叫它改程式碼，我有辦法用到快取嗎？

有，而且方式跟前面完全相反——你不用標，但你會不小心打斷它。

官方講得很明確：Claude Code 自動幫你處理快取，你不需要（也沒辦法）手動標記斷點。它每一輪都把「系統提示 → 專案脈絡 → 對話歷史」照這個順序排好，讓最不常變動的東西排在最前面，新內容永遠往後面接——這正是第一節講的前綴匹配原理，只是有人幫你排好了。

所以你能做的不是「設定快取」，是別在任務進行到一半時去動那些會重算前綴的東西。官方文件有一句話可以直接當結論：

"Pick your model and effort level at the top of a session, then save /compact for natural breaks between tasks. The fewer changes you make mid-task, the higher your cache hit rate."

（開場就把模型和 effort 選定，把 /compact 留到任務之間的自然段落。你在任務中途做的改動越少，快取命中率越高。）

具體來說：

兩個值得單獨記住的細節：

① 想放棄一段走錯的路時，/rewind 比 /compact 便宜。 因為 rewind 是把對話截斷回到之前的某一輪，而那個前綴早就被快取過了，直接命中；/compact 則是生一份新摘要，等於建立一個全新的前綴，得從頭寫入。官方原文：「Rewinding truncates back to a prefix that is already cached, rather than building a new one as compaction does.」

② 快取的範圍是「同一台機器 + 同一個目錄」。 兩個不同目錄開的 session 不會共用彼此的快取——包含同一個 repo 的不同 git worktree，因為系統提示裡embedded 了工作目錄路徑，路徑不同前綴就不同。

（Claude Code 還有一批跟 CLAUDE.md、TTL 設定有關的快取行為，那是 Day 22 的主場，這裡先不展開。）

但 Day 8 講的那個原則在任何介面都成立：把穩定不變的內容放前面、每次都變的內容放後面。 就算你看不到快取的計費細節，這個習慣本身就會讓你的請求結構更清楚。

八、什麼時候快取反而會虧錢

快取不是萬用的省錢按鈕。把第二節的價目表倒過來看，有兩種情境你標了 cache_control 反而更貴：

① 內容只會被讀一次。 5 分鐘快取的寫入價是 1.25×，讀取一次省下的是「本來 1× 的 input，變成 0.1× 的讀取」——這個差額要靠至少一次命中才能打平寫入多付的那 25%。如果這段內容天生就是一次性的（例如每次都不一樣的使用者輸入），標了快取只是白白多付 25% 的寫入成本，永遠等不到回本的那一次讀取。

② 內容雖然會被重複讀，但重複的間隔超過 TTL。 5 分鐘內沒有第二次請求進來，快取就過期了，前面寫入多付的成本直接打水漂。如果你的重複請求間隔不穩定、有時候隔了 10 分鐘才有下一筆，換成 1 小時版本的快取（寫入 2×）反而更划算——但 1 小時版本要兩次命中才能回本，門檻更高。判斷原則很簡單：先估你的內容多久會被重複讀到一次、讀幾次，再回頭選 TTL。

這兩種情境的共通點是：快取的價值來自「被重複讀取」，不是來自「被標記」。 標記本身不會讓你變便宜，只有真正命中才會。這也是為什麼第三節一直強調要回頭檢查 usage 裡的 cache_creation_input_tokens 和 cache_read_input_tokens——沒有實際數據佐證的快取策略，很可能是在做反效果的優化。

本篇自我挑戰

• 今日挑戰：檢查你目前的 system prompt 或最常重複使用的一段內容，量一下它有沒有超過你使用模型的最小可快取長度（Opus 5 是 512 tokens，用 Day 7 學到的 count_tokens 就能量）。如果超過，試著加上 cache_control，跑兩次相同結構的請求，比對第二次的 cache_read_input_tokens 是否符合預期。

• 反思：快取解決的是「重複內容不用重新付全額」，但它不會讓 Claude 記得你們之前聊過什麼——這兩件事很容易被搞混。你有沒有曾經誤以為「開了快取＝Claude 有記憶」的經驗？這個誤解會讓你在系統設計上做出什麼錯誤假設？

總結

Prompt Caching 的本質很單純：替一段內容的前綴建一筆雜湊記錄，之後前綴一致就用 0.1 倍價讀取。 它不理解語意，只比對內容是否一致。

今天最重要的三件事：第一，寫入比一般 input 貴（1.25× 或 2×），但通常一次命中就回本；第二，內容太短不會被快取，而且不會報錯——記得檢查 usage 欄位確認是否真的命中；第三，改變 effort、工具定義、圖片、thinking 設定都會讓快取失效，這些是實務上最容易讓快取「突然不見了」的地方。

而如果你不寫程式、平常是在 Claude Code 裡工作——快取一直都在幫你省，你只是沒看到它。 你能做的不是設定它，是別在任務中途換模型、換 effort，把 /compact 留到任務之間的自然段落。

把 Day 8 那句「穩定內容放前面、變動內容放後面」落地成今天的具體做法，你就有了一套能立刻套用的快取策略。

本日關鍵字回顧

• Prompt Caching：對內容前綴建立雜湊記錄，命中時以 0.1× input 價計費的機制，不涉及語意記憶。
• 自動快取 vs 顯式斷點：前者自動推進快取點，後者最多 4 個手動標記點，可混用。
• 最小可快取長度：因模型而異（512～4,096 tokens），不足則不快取、不報錯。
• 20 區塊回溯窗口：快取讀取向後查找的範圍上限，斷點離穩定內容太遠會找不到匹配。
• effort 使快取失效：改變 output_config.effort 一定會讓對話快取失效，是動態調整 effort 時的隱藏成本。
• Claude Code 的自動快取：不需（也無法）手動標記，使用者能控制的是「任務中途少做會重算前綴的動作」，/rewind 因命中舊前綴而比 /compact 便宜。

明天接著講計價光譜裡的另一個折扣——不靠快取，直接把 input 和 output 都打五折的 Batch API，以及它跟今天的快取怎麼疊加使用。

Day 10，用時間換金錢的非同步任務打開方式。