Claude Code token 瘋狂消耗真相：system-reminder 注入機制的致命 bug

文章資訊

作者：cab_late
來源：https://www.threads.com/@cab_late/post/DVpSUz9E1GL
發布時間：2026-03-09
觀看數：11,100
社群反應：225 讚、40 則回覆

問題發現

如果你發現 Claude Code 額度越燒越快，不是你的錯覺、也不是你真的多做了多少事情，而是他們的 system-reminder 在坑人。

翻了一下 GitHub 災情大概半年前就有了。

異常現象

對話過程中要求輸出該次對話 system reminder 都注入了什麼，共同的狀況大概是：

變更檔案的完整 diff
內容會被明確標記「不要主動告知使用者」（所以你完全不知道）
Skill 與 Plugin 的 metadata 每次對話都會重新注入
以上所有內容不會出現在 JSONL 中，所以你無法直接觀測

實際影響

變成我根本沒聊多少內容，但如果編輯過檔案的話，哪怕只是一句簡單的請求與回應，就會直接吃掉 2%-3% 的 5hr 額度。

作者表示：

這個月 token 額度燒這麼快
上週也開始覺得 100 美金方案不夠燒
但仔細想想又沒多做甚麼事情

技術分析：逆向 Claude Code 2.1.71

作者深入研究後，決定逆向 Claude Code 的原始碼。

readFileState 機制

Claude Code 內部有一張表叫 readFileState，記錄「我知道的檔案長什麼樣」。

每次發訊息時的流程

Claude Code 會遍歷這張表裡的每個檔案：

這個檔案是「完整讀取」的嗎？ → 不是就跳過不管
檔案的修改時間比我記錄的新嗎？ → 沒有就跳過
重新讀一次，跟我記錄的內容比對 → 沒差異就跳過
有差異 or Offset 沒狀態 → 把 diff 當 system-reminder 塞進你的訊息裡

特殊檔案

像是 CLAUDE.md 或 MEMORY.md 這類基礎機制的檔案，預設永遠追蹤。

呼應了為甚麼官方後期也越來越強調你 CLAUDE.md 不要塞太多東西。

bug 根本原因

表格建立與還原

這張表的建立來自於：

對話過程
打開對話時當下已紀錄的 JSONL

正常對話改檔案，都會讓檔案最後修改時間 ≤ 當前時間，或是表格中有 offset 狀態紀錄，只要沒撞到 bug 都不會造成重新注入。

關鍵問題

這張表是在記憶體的，所以關掉就沒了，resume 後才會從 JSONL 還原表格。

resume 後的災難

該次 session 的 JSONL 如果有修改或讀取任何檔案，這張表格就會有最多 10 筆的追蹤檔案
表格被還原之後，表中的檔案是還沒有 offset 狀態的
接下來只要你送出一句話，就會把這 10 個檔案內容讀取並注入進去
然後更新追蹤表狀態，再下一句對話就不會重新注入了（嗎？）

路徑對應問題

這種機制就很怕路徑與實際讀取路徑的兩串字是對不起來的。

只要對不起來，追蹤表上明明應該要被更新的始終不會被更新，那就是每次都走注入流程。

Agent SDK 用戶：大中計

所以恭喜 Agent SDK 用戶大中計。

因為 Agent SDK 的持續對話得要以 resume 為主：

每一次你送一筆訊息過去就是走 resume 跑上面的流程
判斷一堆檔案要注入、然後注入一堆檔案
每一次都注入，不管你讀了幾百次都一樣
每次都會重建這張表

額外災情（感謝 @codemeteor 翻 issue）

提示詞的快取運作不正常
- 每次相同內容再注入時也根本沒有命中快取來幫你省 token 開銷
SDK 執行快取的 TTL 時間錯誤
- 被挖出是跑 1 小時留存的設定
- 比原本文件寫的 5 分鐘留存版本花費還要貴 50% 左右
- 跟第一點連動起來 = 雪上加霜

GitHub Issue

https://github.com/anthropics/claude-agent-sdk-typescript/issues/197
[DOCS] Document prompt caching behavior: invalidation causes, TTL defaults, and optimization guide

解決方案

唯一解法

1. Claude Code CLI 用戶

避免頻繁 resume
任何 Update / Edit 之後，都要再做一次 Read 來觸發狀態更新
雖然會因為多讀一次而先多燒一次，總比後續根本沒用到那個檔案然後被瘋狂浪費來得好

2. Agent SDK 用戶

主動讓 AI 提供「當前 system-reminder 中 Data Modified 的篇幅」
太長就自己重開對話吧，這目前無解

作者結論

研究完只能說真的是太誇張了，SDK 用戶根本被抓起來當盤子宰，API 收費就已經貴很多還這樣吃錢...

目前看起來官方是一副「誰理你啊」的樣子，所以我可能也要開始研究怎麼自己去改 source 來緩解這些問題了。

社群反應

tobypang（5 小時前）：

難怪我感覺正常，因為只要 context 沒爆掉我都放着視窗不管，有些視窗的 Claude Code 版本甚至還停留在 .5x

（意思是：舊版本沒這個 bug，或是不 resume 就不會中招）

重點摘要

問題：Claude Code 的 system-reminder 機制會瘋狂注入不必要的內容（diff、metadata）
根因：readFileState 表格在 resume 後重建時，沒有 offset 狀態，導致每次都重新注入
影響：Agent SDK 用戶每次對話都會重建表格，每次都注入，token 消耗暴增
額外問題：快取機制不正常、TTL 時間錯誤（1 小時 vs 5 分鐘，貴 50%）
解法：避免頻繁 resume、主動監測 system-reminder 大小、Edit 後立即 Read

分類

技術分析 | Claude Code | Bug 追蹤 | 成本優化

備註：這是一篇非常深入的技術分析文章，透過逆向工程揭露了 Claude Code 長期存在的 token 消耗問題。對於重度使用者（尤其是 Agent SDK 用戶）非常重要。官方對此問題似乎反應冷淡，社群已經開始自救。