Claude Code一周份額，一天燒完一半？有人逆向工程發(fā)現(xiàn)了7個bug

機器之心編輯部

Claude Code 負責人 Boris Cherny 最近可能很頭疼，因為這款神級 AI 在快速更新的同時被曝出各種問題。

其中鬧得最兇的是最近一段時間的質量退化風波 —— 有人發(fā)現(xiàn) Claude Code 的模型思考深度從今年 1 月底的約 2200 字符，到 2 月下旬驟降至 720 字符，降幅高達 67%，3 月初更進一步跌至 560 字符。這位開發(fā)者直言「Claude 已經(jīng)退化到無法信任其執(zhí)行復雜工程任務的程度?！?/p>

與此同時，一個名為 redact-thinking 的功能在 3 月上線，將思考過程從界面上隱藏，使得這一退化對用戶變得不可見。

思考深度的削減帶來了一連串連鎖反應：模型不假思索就改代碼、無效迭代率飆升、API 總調用成本暴漲百倍。

Boris 不得不出面解釋，稱 redact-thinking 只是 UI 層面的隱藏，并不影響實際推理；真正影響行為的是兩處變更 ——2 月引入了讓模型自主決定思考深度的「自適應思考」模式，3 月又將默認 effort 級別調為 Medium，他表示用戶可以手動調回高強度模式。

目前，圍繞這件事的討論還在發(fā)酵，Claude Code 似乎正在面臨一場嚴重的信任危機。

與此同時，我們還發(fā)現(xiàn)，Claude Code 可能還有其他值得關注的 bug，這些 bug 浪費的是每個用戶的真金白銀。

7 個 bug 疊加，一周的 token 配額一天就燒完一半

發(fā)現(xiàn)這些 bug 的開發(fā)者是一位 Claude Max 20x 訂閱用戶，僅 4 月 1 日單天，他就燒掉了 43% 的一周配額。

于是，他花了幾天時間逆向分析 Claude Code 的源碼，找出了 7 個疊加在一起的 Bug。截至發(fā)帖時（三天前），3 個已修復，2 個可以規(guī)避，2 個仍未修復。

其中最嚴重的一個 bug 是：Extra Usage 會悄悄關掉緩存。

在 Claude Code 的 cli.js 文件里，有一個函數(shù)負責決定向服務器申請多長時間的緩存 —— 要么 1 小時，要么 5 分鐘。這個函數(shù)會偷偷檢查你是否進入了 Extra Usage（超額付費）模式，一旦檢測到，就會靜默地把緩存時長降級為 5 分鐘，全程不給任何提示。這意味著你只要停下來超過 5 分鐘 —— 哪怕只是去趟衛(wèi)生間 —— 就會觸發(fā)一次完整的上下文重建，費用直接從你的 Extra Usage 余額里扣。作者驗證過，服務器在被要求時是完全愿意給出 1 小時緩存的，是客戶端主動停止申請的。

這個降級的代價非常具體。以 220K 的上下文為例，1 小時緩存每輪大約花費 0.22 美元，而 5 分鐘緩存每輪高達 0.61 美元，貴了整整 1.8 倍。換算下來，30 美元的 Extra Usage 額度，在 1 小時緩存下大約能撐 135 輪對話，但在 5 分鐘緩存下只能撐約 48 輪。

更糟糕的是，這會形成一個「死亡螺旋」：其他緩存 Bug 先把計劃內配額加速耗盡，計劃配額一用完就觸發(fā) Extra Usage，客戶端檢測到 Extra Usage 后把緩存降為 5 分鐘，于是每次短暫停頓都變成一次全額重建，Extra Usage 迅速蒸發(fā)，用戶被鎖定等待 5 小時重置，然后這個循環(huán)再次開始。

不過，作者提到，只需給這個函數(shù)打一行補丁（讓它始終返回 true）就能修復這個問題。服務器會很樂意給你 1 小時緩存。不過更新后這個修改會被覆蓋。

除了這個核心問題，作者還列出了另外 6 個 Bug

第一個是原生安裝包的問題：官方提供的二進制安裝文件內置了一個自定義 Bun 運行時，這個運行時會在每次請求時損壞緩存前綴。解決方法是改用 npm install 安裝，并通過運行 file $(which claude) 來驗證 —— 結果應該是符號鏈接，而不是 ELF 二進制文件。

第二個 Bug 存在于 v2.1.69 到 v2.1.90 之間，長達 28 天、橫跨 20 個版本：會話恢復時會丟失關鍵的附件類型，導致每次恢復都是一次完整的緩存未命中。這個問題已在 v2.1.91 中修復。

第三個 Bug 是自動壓縮功能沒有熔斷機制，壓縮失敗后會無限重試，作者發(fā)現(xiàn)內部源碼注釋里記錄了 1279 個會話出現(xiàn) 50 次以上連續(xù)失敗的情況，這個問題已在 v2.1.89 修復。

第四個 Bug 是工具結果在客戶端被截斷：Bash 工具上限 30K 字符，Grep 工具上限 20K 字符，截斷后的殘缺內容會破壞緩存前綴。這些上限可以在本地配置文件～/.claude.json 的 cachedGrowthBookFeatures 字段中查看。

第五個就是前面說的核心 Bug。

第六個 Bug 是客戶端會在大型對話記錄中偽造假的限速錯誤，顯示 model: synthetic、token 數(shù)為零，實際上根本沒有發(fā)起任何 API 調用，截至發(fā)帖時仍未修復。

第七個 Bug 則在服務端：服務器的壓縮機制會在會話進行中悄悄刪除工具結果，不給任何通知，同樣破壞緩存，且無法從客戶端打補丁修復。截至發(fā)帖時仍未修復。

作者特別強調，這些 Bug 之間的關系是相乘而非相加。如果一個用戶同時觸發(fā)其中的 Bug 1、3、5，可能在不到兩小時內就耗盡整整一周的配額。

遇到這些問題怎么辦？

針對這些問題，作者給出了幾條建議：如果使用原生安裝包，切換到 npm 安裝；確保更新到 v2.1.91 或更高版本。如果有能力編輯壓縮后的 JS 文件，可以手動給緩存 TTL 函數(shù)打一行補丁，讓它始終申請 1 小時緩存，但每次版本更新后需要重新打。

有用戶留言證實了作者的解決方案。一位在 WSL 環(huán)境下運行 Claude Code 的高強度用戶表示，自己近期的確感覺額度燒得飛快，在聽從作者建議改用 npm 方式安裝后，額度消耗速率立刻恢復了正常。

也有幾個一直使用 npm 方式安裝的用戶跟帖表示，自己確實完全沒有遇到最近大家都在抱怨的這些 Bug。

經(jīng)過大家在評論區(qū)的比對發(fā)現(xiàn)，這些不受影響的用戶基本都是在用 VS Code 插件、電腦桌面版或直接用網(wǎng)頁版。這進一步印證了一個結論：這個吞額度 Bug 幾乎是 Claude Code CLI 原生安裝包專屬的災難。

最后，作者聲明他無法判斷 Extra Usage 時降級緩存是故意的設計還是一個疏忽，有可能是某種成本優(yōu)化但沒有考慮到連鎖反應。

值得注意的是，在最近更新的 Claude Code v2.1.92 版本中，我們發(fā)現(xiàn) Claude Code 增加了更細致的賬單透明度?，F(xiàn)在用戶運行 /cost 命令時，CLI 會展示基于每個模型以及緩存命中（Cache-hit）情況的詳細費用分解。

此外，新版本還新增了「緩存過期」的主動提醒。官方現(xiàn)在會在 Pro 用戶返回會話時，于底部狀態(tài)欄顯示一個提醒：告知當前的提示詞緩存（Prompt Cache）已經(jīng)失效，并預估下一輪對話將發(fā)送多少個未經(jīng)緩存的 Token。這在某種程度上算是一種「免責聲明」—— 它不再靜默扣費，而是明確告訴你：「接下來的這一發(fā)提問會很貴。」

之前，我們一直擔心 AI 取代程序員，現(xiàn)在我們得擔心 AI 工具一邊偷懶一邊掏空我們的錢包。

當 Anthropic 在「追求極致體驗」與「沉重推理成本」之間劇烈掙扎時，我們很難判斷哪些是真的 bug，哪些為了成本優(yōu)化而有意為之。

但有一點是確定的：開發(fā)者需要的不是一個替自己做決策的「黑盒」，而是一個透明、可預測的杠桿。 當一個工具開始在用戶看不見的地方，通過縮短緩存時長、隱藏思考邏輯來平衡自己的賬本時，它犧牲的不只是幾美金的 Token 費，更是過去積累下來的、極其珍貴的開發(fā)者信任。

參考鏈接：https://www.reddit.com/r/ClaudeAI/comments/1sbqalg/i_reverseengineered_why_claude_code_burns_through/