Claude Code一周份额，一天烧完一半？有人逆向工程发现了7个bug

机器之心编辑部

Claude Code 负责人 Boris Cherny 最近可能很头疼，因为这款神级 AI 在快速更新的同时被曝出各种问题。

其中闹得最凶的是最近一段时间的质量退化风波 —— 有人发现 Claude Code 的模型思考深度从今年 1 月底的约 2200 字符，到 2 月下旬骤降至 720 字符，降幅高达 67%，3 月初更进一步跌至 560 字符。这位开发者直言「Claude 已经退化到无法信任其执行复杂工程任务的程度。」

与此同时，一个名为 redact-thinking 的功能在 3 月上线，将思考过程从界面上隐藏，使得这一退化对用户变得不可见。

思考深度的削减带来了一连串连锁反应：模型不假思索就改代码、无效迭代率飙升、API 总调用成本暴涨百倍。

Boris 不得不出面解释，称 redact-thinking 只是 UI 层面的隐藏，并不影响实际推理；真正影响行为的是两处变更 ——2 月引入了让模型自主决定思考深度的「自适应思考」模式，3 月又将默认 effort 级别调为 Medium，他表示用户可以手动调回高强度模式。

目前，围绕这件事的讨论还在发酵，Claude Code 似乎正在面临一场严重的信任危机。

与此同时，我们还发现，Claude Code 可能还有其他值得关注的 bug，这些 bug 浪费的是每个用户的真金白银。

7 个 bug 叠加，一周的 token 配额一天就烧完一半

发现这些 bug 的开发者是一位 Claude Max 20x 订阅用户，仅 4 月 1 日单天，他就烧掉了 43% 的一周配额。

于是，他花了几天时间逆向分析 Claude Code 的源码，找出了 7 个叠加在一起的 Bug。截至发帖时（三天前），3 个已修复，2 个可以规避，2 个仍未修复。

其中最严重的一个 bug 是：Extra Usage 会悄悄关掉缓存。

在 Claude Code 的 cli.js 文件里，有一个函数负责决定向服务器申请多长时间的缓存 —— 要么 1 小时，要么 5 分钟。这个函数会偷偷检查你是否进入了 Extra Usage（超额付费）模式，一旦检测到，就会静默地把缓存时长降级为 5 分钟，全程不给任何提示。这意味着你只要停下来超过 5 分钟 —— 哪怕只是去趟卫生间 —— 就会触发一次完整的上下文重建，费用直接从你的 Extra Usage 余额里扣。作者验证过，服务器在被要求时是完全愿意给出 1 小时缓存的，是客户端主动停止申请的。

这个降级的代价非常具体。以 220K 的上下文为例，1 小时缓存每轮大约花费 0.22 美元，而 5 分钟缓存每轮高达 0.61 美元，贵了整整 1.8 倍。换算下来，30 美元的 Extra Usage 额度，在 1 小时缓存下大约能撑 135 轮对话，但在 5 分钟缓存下只能撑约 48 轮。

更糟糕的是，这会形成一个「死亡螺旋」：其他缓存 Bug 先把计划内配额加速耗尽，计划配额一用完就触发 Extra Usage，客户端检测到 Extra Usage 后把缓存降为 5 分钟，于是每次短暂停顿都变成一次全额重建，Extra Usage 迅速蒸发，用户被锁定等待 5 小时重置，然后这个循环再次开始。

不过，作者提到，只需给这个函数打一行补丁（让它始终返回 true）就能修复这个问题。服务器会很乐意给你 1 小时缓存。不过更新后这个修改会被覆盖。

除了这个核心问题，作者还列出了另外 6 个 Bug

第一个是原生安装包的问题：官方提供的二进制安装文件内置了一个自定义 Bun 运行时，这个运行时会在每次请求时损坏缓存前缀。解决方法是改用 npm install 安装，并通过运行 file $(which claude) 来验证 —— 结果应该是符号链接，而不是 ELF 二进制文件。

第二个 Bug 存在于 v2.1.69 到 v2.1.90 之间，长达 28 天、横跨 20 个版本：会话恢复时会丢失关键的附件类型，导致每次恢复都是一次完整的缓存未命中。这个问题已在 v2.1.91 中修复。

第三个 Bug 是自动压缩功能没有熔断机制，压缩失败后会无限重试，作者发现内部源码注释里记录了 1279 个会话出现 50 次以上连续失败的情况，这个问题已在 v2.1.89 修复。

第四个 Bug 是工具结果在客户端被截断：Bash 工具上限 30K 字符，Grep 工具上限 20K 字符，截断后的残缺内容会破坏缓存前缀。这些上限可以在本地配置文件～/.claude.json 的 cachedGrowthBookFeatures 字段中查看。

第五个就是前面说的核心 Bug。

第六个 Bug 是客户端会在大型对话记录中伪造假的限速错误，显示 model: synthetic、token 数为零，实际上根本没有发起任何 API 调用，截至发帖时仍未修复。

第七个 Bug 则在服务端：服务器的压缩机制会在会话进行中悄悄删除工具结果，不给任何通知，同样破坏缓存，且无法从客户端打补丁修复。截至发帖时仍未修复。

作者特别强调，这些 Bug 之间的关系是相乘而非相加。如果一个用户同时触发其中的 Bug 1、3、5，可能在不到两小时内就耗尽整整一周的配额。

遇到这些问题怎么办？

针对这些问题，作者给出了几条建议：如果使用原生安装包，切换到 npm 安装；确保更新到 v2.1.91 或更高版本。如果有能力编辑压缩后的 JS 文件，可以手动给缓存 TTL 函数打一行补丁，让它始终申请 1 小时缓存，但每次版本更新后需要重新打。

有用户留言证实了作者的解决方案。一位在 WSL 环境下运行 Claude Code 的高强度用户表示，自己近期的确感觉额度烧得飞快，在听从作者建议改用 npm 方式安装后，额度消耗速率立刻恢复了正常。

也有几个一直使用 npm 方式安装的用户跟帖表示，自己确实完全没有遇到最近大家都在抱怨的这些 Bug。

经过大家在评论区的比对发现，这些不受影响的用户基本都是在用 VS Code 插件、电脑桌面版或直接用网页版。这进一步印证了一个结论：这个吞额度 Bug 几乎是 Claude Code CLI 原生安装包专属的灾难。

最后，作者声明他无法判断 Extra Usage 时降级缓存是故意的设计还是一个疏忽，有可能是某种成本优化但没有考虑到连锁反应。

值得注意的是，在最近更新的 Claude Code v2.1.92 版本中，我们发现 Claude Code 增加了更细致的账单透明度。现在用户运行 /cost 命令时，CLI 会展示基于每个模型以及缓存命中（Cache-hit）情况的详细费用分解。

此外，新版本还新增了「缓存过期」的主动提醒。官方现在会在 Pro 用户返回会话时，于底部状态栏显示一个提醒：告知当前的提示词缓存（Prompt Cache）已经失效，并预估下一轮对话将发送多少个未经缓存的 Token。这在某种程度上算是一种「免责声明」—— 它不再静默扣费，而是明确告诉你：「接下来的这一发提问会很贵。」

之前，我们一直担心 AI 取代程序员，现在我们得担心 AI 工具一边偷懒一边掏空我们的钱包。

当 Anthropic 在「追求极致体验」与「沉重推理成本」之间剧烈挣扎时，我们很难判断哪些是真的 bug，哪些为了成本优化而有意为之。

但有一点是确定的：开发者需要的不是一个替自己做决策的「黑盒」，而是一个透明、可预测的杠杆。 当一个工具开始在用户看不见的地方，通过缩短缓存时长、隐藏思考逻辑来平衡自己的账本时，它牺牲的不只是几美金的 Token 费，更是过去积累下来的、极其珍贵的开发者信任。

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