当前位置: 首页 » 资讯 » 新科技 » 正文

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

IP属地 中国·北京 机器之心Pro 时间:2026-04-07 22:41:22



机器之心编辑部

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/

免责声明:本网信息来自于互联网,目的在于传递更多信息,并不代表本网赞同其观点。其内容真实性、完整性不作任何保证或承诺。如若本网有任何内容侵犯您的权益,请及时联系我们,本站将会在24小时内处理完毕。