Claude Code 省錢密技：工程師一週靠快取省下 3 億 Token，關鍵在別打斷

Claude Code 長對話吃額度？工程師 Nate Herk 揭露，一週靠快取機制省下 3 億 Token，單日最高 9100 萬。關鍵不是寫多少程式，而是如何不「打斷」快取，讓重複上下文不再浪費成本。
（前情提要：鞭打 Claude code 加速的 badclaude 開源專案，被 Anthropic 寄侵權通知信了）
（背景補充：Claude Code 新增雲端定時任務功能！不用開電腦，AI 自動審核 PR、升級）

本文目錄

Toggle

快取成本只有 10%，9100 萬 Token 等於 900 萬
三層架構：系統、專案、對話，層層疊加
最常見的「斷緩」陷阱：模型切換與空窗 1 小時
工程師自製儀錶板：檢視 Cache Read 與 Create
實戰心法：Session Handoff 比 /compact 更省錢

很多開發者用 Claude Code 寫程式時，最頭痛的往往是 Token 用量配額像流水一樣快速見底，長對話幾乎成了奢侈品。

但常在社群分享 AI 使用技巧的網紅 Nate Herk 在一則 X 推文中揭露，真正的成本殺手其實不是程式碼量，而是系統有沒有善用 prompt caching 機制。他本人一週內就靠快取節省了超過 3 億 Token，單日快取量高達 9100 萬：由於快取 Token 的成本僅為普通輸入 Token 的 10%，這筆帳算下來，等於一天只花了 900 萬 Token 的費用，幾乎是「免費」延長了整個程式設計對話回合的壽命。

我這周節省了 3 億 Token，單日 9100 萬，一週超過 3 億。

我沒有改動任何設定。這只是 prompt caching 在後臺正常發揮作用。

但當我真正理解了快取是什麼，以及怎樣避免把快取「打斷」之後，在同樣的使用額度下，我的會話可以持續更久。所以，這裡整理一份 Claude Code prompt caching 的 80/20 入門指南，不涉及 API 層面的深度細節。

快取 Token 的成本只有普通輸入 Token 的 10%。9100 萬快取 Token，實際計費大約相當於 900 萬 Token。

Claude Code 訂閱版的快取 TTL 是 1 小時；API 預設是 5 分鐘；Sub-agent 永遠是 5 分鐘。

快取分為三層：系統層、專案層、對話層。

會話中途切換模型會破壞快取，包括開啟「opus plan」模式。

快取成本只有 10%，9100 萬 Token 等於 900 萬

每一個被快取的 Token，成本都是普通輸入 Token 的 10%。

所以，當我的儀表盤顯示某一天有 9100 萬 Token 命中了快取時，實際計費大概只相當於處理了 900 萬 Token。這也是為什麼和沒有快取相比，長時間使用 Claude Code 時，會讓人感覺會話幾乎是「免費」延長的。

儀表盤裡有兩個數字值得重點關注：

Cache create：把內容寫入快取時產生的一次性成本。它會在下一輪對話中開始發揮作用。
Cache read：Claude 從快取中複用的 Token，比如你的 CLAUDE.md、工具定義、此前的訊息等。相比重新作為輸入處理，成本低成本 10 倍。

如果你的 Cache read 數字很高，說明你正在有效利用快取；如果這個數字很低，就意味著你在為同一批上下文反覆付費。

Anthropic 的 Thariq 有一句話讓我印象很深：「我們實際上會監控 prompt cache 的命中率，一旦命中率過低，就會觸發警報，甚至宣布 SEV 級別的事故。」

他還寫過一篇很好的 X 文章。當快取命中率高時，會同時發生四件事：Claude Code 體感更快，Anthropic 的服務成本下降，你的訂閱額度顯得更耐用，長時間編碼會話也變得更現實。

但如果命中率很低，所有人都會吃虧。

三層架構：系統、專案、對話，層層疊加

所以，雙方的激勵其實是一致的：Anthropic 希望你的快取命中率更高，你自己也希望命中率更高。真正會拖後腿的，只是一些看似不起眼、卻會悄悄重建快取的小習慣。

快取依賴的是 prefix matching，也就是「字首匹配」。

不用陷入太深的技術細節，你只需要理解一點：只要某個位置之前的內容和已經快取的內容完全一致，Claude 就可以複用這部分快取 Token。

一次全新的會話，大致是這樣展開的：

根據 Claude Code 檔案，一個全新會話通常是這樣執行的：

第一輪對話：還沒有任何快取。系統提示詞、你的專案上下文（比如 CLAUDE.md、memory、規則），以及你的第一條訊息，都會被重新處理一遍，並寫入快取。

第二輪對話：第一輪中的所有內容現在都已經被快取。Claude 只需要處理你的新回覆和下一條訊息。這一輪成本就會低很多。

第三輪對話：邏輯相同。之前的對話仍然保留在快取裡，只有最新的一輪互動需要重新處理。

最常見的「斷緩」陷阱：模型切換與空窗 1 小時

快取本身可以分成三層：

來自 Thariq 的 X 文章：

系統層（System layer）：包括基礎指令、工具定義（read、write、bash、grep、glob）和輸出風格。這一層是全域性快取的。

專案層（Project layer）：包括 CLAUDE.md、memory、專案規則。這一層按專案快取。

對話層（Conversation）：包括回覆和訊息，會隨著每一輪對話不斷增長。

如果在會話中途，系統層或專案層的任何內容發生變化，所有內容都必須從頭重新快取一遍。這就是最「貴」的操作。可以想象一下：你已經聊到第 16 條訊息，這時突然改了系統提示詞，或者中途停了一個小時，那麼從第 1 條訊息開始的所有 Token 都要被重新處理一遍。

這是最容易讓人誤解的地方。

Claude Code 訂閱版：預設 TTL 是 1 小時。

工程師自製儀錶板：檢視 Cache Read 與 Create

Claude API：預設 TTL 是 5 分鐘。你可以付出更高成本，把它提升到 1 小時。
任何計劃下的 Sub-agent：永遠是 5 分鐘。

Claude.ai 網頁聊天：官方沒有明確記錄。可能和訂閱版一樣，但我還沒有確認。

幾個月前，很多人抱怨 Claude 訂閱額度消耗得太快。當時有人以為 Anthropic 悄悄把 TTL 從 1 小時降到了 5 分鐘，而且沒有通知使用者。但事實並不是這樣，Claude Code 的 TTL 仍然是 1 小時。

問題在於，Claude Code 和 API 的檔案是分開放的，而這兩者本來就是完全不同的東西，於是造成了不少混淆。

如果你在大量執行 Sub-agent 工作流，或者直接使用 API，那麼 5 分鐘這個數字很重要。但對於 95% 的 Claude Code 使用者來說，真正需要關注的，其實只有那個 1 小時視窗。

下面這些，是我覺得日常使用中真正有用的部分。

如果你已經空閒超過一個小時，之前的內容基本都已經從快取裡過期了。你的下一條訊息會重新構建快取。這種情況下，與其繼續恢復一個已經「變涼」的舊會話，不如做一次清晰的交接，然後開啟一個新會話，成本通常更低。

/compact 或 /clear 本來就會破壞快取，所以不如趁這個節點真正重建一次。

實戰心法：Session Handoff 比 /compact 更省錢

我自己做了一個 session handoff skill，用來替代 /compact。它會總結我們已經完成了什麼、還有哪些待定決策、哪些檔案最重要，以及接下來應該從哪裡繼續。然後我執行 /clear，把這份總結貼進去，就可以像什麼都沒中斷一樣繼續推進。

compact 命令有時候執行得也很慢。而這個 handoff skill 通常不到一分鐘就能完成。

Claude.ai 上的快取機制沒有非常詳細的官方說明，但 Projects 顯然和普通對話執行緒採用了不同的最佳化方式。所以，如果你要貼上很大的檔案，最好把它們放進 Project，而不是直接塞進對話裡。

有幾件事會在沒有明顯提醒的情況下，把快取全部重建。

切換模型：因為快取依賴字首匹配，而每個模型都有自己的快取。只要切換模型，下一次請求就會在沒有任何快取命中的情況下，重新讀取完整歷史。

「Opus plan」模式：這個設定會在規劃階段使用 Opus，在執行階段使用 Sonnet。我之前在一些 token 最佳化影片裡推薦過它，是有原因的。但需要理解的是，每一次切換 plan，本質上都是一次模型切換，也就意味著要重新建立快取。從長期看，它仍然有助於延長會話額度，但你需要知道底層到底發生了什麼。

會話中途編輯 CLAUDE.md 是可以的：這個修改不會立刻生效，要等下一次重啟才會應用。因此，當前正在執行的快取不會受到影響。

我前面展示的截圖，來自一個 token dashboard。

》原文連結