首頁

快訊深度數據 Skill&API

一周省下3億代幣，Anthropic工程師的Claude Code快取指南

閱讀本文需 17 分鐘

讓快取持續重複使用，讓長會話少做重複計算

原文標題：Anthropic 工程師究竟是如何節省代幣的
原文作者：Nate Herk
翻譯：Peggy，BlockBeats

編者按：當許多人使用 Claude Code 時，最直接的感受是代幣消耗過快，長會話很容易耗盡額度。但從 Anthropic 工程師的角度來看，真正影響成本的往往不是你寫了多少程式碼，而是系統是否持續重複使用已處理過的上下文。

本文分享的核心是如何通過快取機制節省代幣。作者在一周內通過快取重複使用了超過 3 億代幣，單日快取量達到 9100 萬。由於快取代幣的成本僅為普通輸入代幣的 10%，這意味著 9100 萬快取代幣的實際計費相當於 900 萬普通代幣。Claude Code 長會話之所以顯得更「耐用」，不是因為模型免費運作，而是大量重複上下文被成功重複使用。

Prompt 快取的關鍵在於「不要打斷快取」。Claude Code 將系統提示、工具定義、CLAUDE.md、項目規則和歷史對話分層快取；只要後續請求的前綴保持一致，Claude 就可以直接讀取快取，而不是重新處理整段上下文。Anthropic 內部也會監控 prompt 快取的重複使用率，因為它不僅影響使用者額度，還直接關係到模型服務成本和運行效率。

對普通用戶來說，不必理解所有底層細節，只需要掌握幾個關鍵習慣：不要讓會話空置超過 1 小時；切換任務時做好 session handoff；避免頻繁切換模型；大文檔盡量放進 Projects，而不是反覆貼進對話。

這篇文章與其說是在講一個省代幣技巧，不如說是在提供一套更接近工程師思維的 Claude Code 使用方法：將上下文當作資產管理，讓快取持續重複使用，讓長會話少做重複計算。

以下為原文：

我這周省下了 3 億代幣，單日 9100 萬，一周超過 3 億。

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

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

TL;DR

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

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

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

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

快取到底怎麼算錢？

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

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

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

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

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

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

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

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

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

快取是如何在每一輪對話中增長的？

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

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

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

根據 Claude Code 文件，一個全新會話通常是這樣運行的：

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

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

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

快取本身可以分成三層：

來自 Thariq 的 X 文章：

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

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

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

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

1 小時和 5 分鐘的混淆

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

Claude Code 訂閱版：默認 TTL 是 1 小時。

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 小時視窗。

覆蓋 95% 用戶的三個習慣

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

不要暫停太久

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

切換任務時，直接重新開始

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

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

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

在 Claude 聊天裡，大文檔盡量放進 Projects

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

哪些操作會悄悄破壞快取？

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

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

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

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