機(jī)器之心編輯部

Claude Code 負(fù)責(zé)人 Boris Cherny 最近可能很頭疼，因?yàn)檫@款神級(jí) AI 在快速更新的同時(shí)被曝出各種問題。

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

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

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

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

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

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

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

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

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

其中最嚴(yán)重的一個(gè) bug 是：Extra Usage 會(huì)悄悄關(guān)掉緩存。

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

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

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

不過，作者提到，只需給這個(gè)函數(shù)打一行補(bǔ)?。ㄗ屗冀K返回 true）就能修復(fù)這個(gè)問題。服務(wù)器會(huì)很樂意給你 1 小時(shí)緩存。不過更新后這個(gè)修改會(huì)被覆蓋。

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

第一個(gè)是原生安裝包的問題：官方提供的二進(jìn)制安裝文件內(nèi)置了一個(gè)自定義 Bun 運(yùn)行時(shí)，這個(gè)運(yùn)行時(shí)會(huì)在每次請(qǐng)求時(shí)損壞緩存前綴。解決方法是改用 npm install 安裝，并通過運(yùn)行 file $(which claude) 來驗(yàn)證 —— 結(jié)果應(yīng)該是符號(hào)鏈接，而不是 ELF 二進(jìn)制文件。

第二個(gè) Bug 存在于 v2.1.69 到 v2.1.90 之間，長達(dá) 28 天、橫跨 20 個(gè)版本：會(huì)話恢復(fù)時(shí)會(huì)丟失關(guān)鍵的附件類型，導(dǎo)致每次恢復(fù)都是一次完整的緩存未命中。這個(gè)問題已在 v2.1.91 中修復(fù)。

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

第四個(gè) Bug 是工具結(jié)果在客戶端被截?cái)啵築ash 工具上限 30K 字符，Grep 工具上限 20K 字符，截?cái)嗪蟮臍埲眱?nèi)容會(huì)破壞緩存前綴。這些上限可以在本地配置文件～/.claude.json 的 cachedGrowthBookFeatures 字段中查看。

第五個(gè)就是前面說的核心 Bug。

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

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

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

遇到這些問題怎么辦？

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

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

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

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

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

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

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

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

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

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

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