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

Claude Code 负责人 Boris Cherny 最近可能有点头疼。

这款一度被很多开发者视为“神级 AI 编程工具”的产品,在快速更新的同时,被持续曝出各种问题。前脚是复杂工程任务上的质量退化争议,后脚又有重度用户站出来说:它不仅可能变得没以前那么稳定,还可能悄悄把你的配额烧得飞快。

机器之心编辑部注意到,最近围绕 Claude Code 的讨论已经不只是“好不好用”,而是逐渐升级成了一个更现实的问题:它到底值不值得信任。

先是“变笨”争议,现在又被曝出“吞额度”问题

其中闹得最凶的,是最近一段时间的质量退化风波。

有人发现,Claude Code 的模型思考深度从今年 1 月底的约 2200 字符,到 2 月下旬骤降至 720 字符,降幅高达 67%;到了 3 月初,又进一步跌至 560 字符。这位开发者甚至直言:Claude 已经退化到无法信任其执行复杂工程任务的程度。

配图

与此同时,一个名为 redact-thinking 的功能也在 3 月上线。这个功能会把思考过程从界面上隐藏,使得这种退化对用户来说变得更难观察。

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

对此,Boris 不得不出面解释。他表示,redact-thinking 只是 UI 层面的隐藏,并不会影响实际推理;真正影响行为的,是两处变更:

  • 2 月引入了让模型自主决定思考深度的“自适应思考”模式
  • 3 月又将默认 effort 级别调成了 Medium

他也补充说,用户仍然可以手动把强度调回更高档位。

配图

配图

目前,围绕这件事的讨论还在继续发酵,Claude Code 正在面临一场明显的信任危机。

但问题还没完。

有人一天烧掉 43% 周配额,于是去逆向了 Claude Code

除了“质量退化”这件事,还有开发者发现:Claude Code 可能还存在一些更直接影响钱包的 bug。

发现这些问题的是一位 Claude Max 20x 订阅用户。仅仅 4 月 1 日这一天,他就烧掉了自己一周配额的 43%

配图

这显然不正常。

于是,他花了几天时间逆向分析 Claude Code 的源码,并最终找出了 7 个叠加在一起的 bug。截至发帖时:

  • 3 个已经修复
  • 2 个可以规避
  • 2 个仍未修复

在他看来,这些 bug 不是简单地“各出一点问题”,而是会层层叠加,最后把用户的额度和额外付费快速吞掉。

最严重的问题:Extra Usage 会悄悄把缓存降到 5 分钟

他认为最严重的一个 bug 是:只要进入 Extra Usage,Claude Code 就会悄悄关掉长缓存。

在 Claude Code 的 cli.js 文件里,有一个函数专门负责决定向服务器申请多长时间的缓存:

  • 要么 1 小时
  • 要么 5 分钟

问题在于,这个函数会偷偷检查你是否进入了 Extra Usage(超额付费)模式。一旦检测到,就会静默把缓存时长降级为 5 分钟,而且整个过程没有任何提示。

这意味着什么?

只要你停下来超过 5 分钟——哪怕只是去个洗手间、看一会儿文档、切去处理别的事情——下一次继续用 Claude Code 时,就会触发一次完整的上下文重建,而这笔费用会直接从你的 Extra Usage 余额里扣。

作者还专门验证过:服务器本身在被请求时,完全愿意提供 1 小时缓存。 也就是说,不是服务端不给,而是客户端主动不再申请。

这个降级有多贵?差不多贵了 1.8 倍

这个问题的代价并不是抽象的。

作者举了一个很具体的例子:如果上下文大小是 220K,那么:

  • 1 小时缓存时,每轮大约花费 0.22 美元
  • 5 分钟缓存时,每轮大约花费 0.61 美元

也就是说,后者大约贵了 1.8 倍

继续换算的话:

  • 30 美元的 Extra Usage 额度,在 1 小时缓存下,大约能撑 135 轮对话
  • 但在 5 分钟缓存下,只能撑 48 轮左右

差距已经不是“小贵一点”,而是会实打实改变使用方式。

更麻烦的是,它会形成“死亡螺旋”

作者认为,最糟糕的地方还不是单次费用变高,而是这一机制会形成一个非常典型的“死亡螺旋”:

  1. 其他缓存相关 bug 先把计划内配额加速消耗掉
  2. 计划配额耗尽后,自动进入 Extra Usage
  3. 客户端检测到 Extra Usage,立即把缓存降为 5 分钟
  4. 用户只要稍微停顿,就触发一次完整重建
  5. Extra Usage 迅速蒸发
  6. 用户被迫等待 5 小时重置
  7. 重置后再次进入同样循环

也就是说,一旦几个 bug 叠在一起,Claude Code 不是“慢慢变贵”,而是会把你直接拖进一个很难脱身的高消耗循环里。

作者提到,这个问题理论上其实很好修:只需要给那个缓存 TTL 函数打一行补丁,让它始终返回 true,客户端就会持续申请 1 小时缓存。服务器也会照常给。

不过问题是,这种修改在每次更新后都会被覆盖。

除了这个核心问题,他还列了另外 6 个 bug

除了 Extra Usage 降缓存这个核心问题之外,作者还列出了 6 个相关 bug。

1)原生安装包自带的 Bun 运行时会损坏缓存前缀

他指出,官方提供的原生二进制安装包里内置了一个自定义 Bun 运行时,而这个运行时会在每次请求时破坏缓存前缀。

给出的解决方法是:改用 npm install 安装,而不是继续使用官方原生安装包。

他还提供了一个简单的验证方式:运行 file $(which claude)。如果结果显示的是符号链接,那基本说明你在用 npm 安装版本;如果显示的是 ELF 二进制文件,那说明你仍在使用原生安装包。

2)v2.1.69 到 v2.1.90 之间,会话恢复会丢失附件类型

第二个 bug 出现在 v2.1.69v2.1.90 之间,持续了整整 28 天、横跨 20 个版本。

这个问题会导致会话恢复时丢失关键附件类型,从而让每次恢复都变成一次完整缓存未命中。

这个问题后来已在 v2.1.91 中修复。

3)自动压缩失败后会无限重试

第三个 bug 是自动压缩机制没有熔断器。

一旦压缩失败,Claude Code 会进入无限重试。作者还提到,他在源码注释里发现:内部曾记录过 1279 个会话出现超过 50 次连续失败 的情况。

这个问题已在 v2.1.89 修复。

4)工具结果在客户端被截断,会破坏缓存前缀

第四个 bug 是工具结果会在客户端被截断。

比如:

  • Bash 工具的上限是 30K 字符
  • Grep 工具的上限是 20K 字符

一旦被截断,残缺的结果就会破坏缓存前缀,进而影响后续缓存命中。

作者表示,这些上限可以在本地配置文件 ~/.claude.jsoncachedGrowthBookFeatures 字段里看到。

5)第五个 bug,就是前面那个 Extra Usage 降缓存

也就是上文提到的核心问题:一进入超额付费模式,客户端就静默把缓存 TTL 降到 5 分钟。

6)客户端会伪造大型对话中的“假限速错误”

第六个 bug 是:在大型对话记录里,客户端有时会伪造一种假的限速错误。

错误里会显示:

  • model: synthetic
  • token 数为 0

但实际上,根本没有发起任何 API 调用。

截至发帖时,这个问题仍未修复。

7)服务端压缩机制会悄悄删除工具结果

第七个 bug 出现在服务端。

作者称,服务器端的压缩机制会在会话进行过程中悄悄删除工具结果,而且不会给出任何通知。这样同样会破坏缓存,并且这个问题无法通过客户端补丁修复。

截至发帖时,这个问题也仍未修复。

这些 bug 不是相加关系,而是相乘关系

作者特别强调,这些 bug 之间的关系不是“一个问题加一个问题”,而是乘法效应

比如说,如果某个用户同时触发了 Bug 1、Bug 3 和 Bug 5,那么有可能在不到两小时内,就把整整一周的额度烧光。

这也是为什么很多人最近的真实体验不是“怎么感觉贵了一点”,而是:额度像漏水一样往外掉。

如果遇到这些问题,他给了几条实用建议

针对这些问题,作者也给出了一些相对务实的建议:

  • 如果你在使用原生安装包,优先切换到 npm 安装
  • 确保版本至少更新到 v2.1.91 或更高
  • 如果你有能力编辑压缩后的 JS 文件,可以手动给缓存 TTL 函数打一行补丁,让它始终申请 1 小时缓存
  • 但要注意,每次版本更新之后,这个补丁都需要重新打一次

评论区里,已经有人验证了这套说法

有用户在评论区现身说法,证实了作者给出的解决方案确实有效。

一位在 WSL 环境下高强度使用 Claude Code 的用户表示,自己最近确实感觉额度烧得特别快,而在听从建议改用 npm 安装方式后,额度消耗速度很快就恢复正常了。

配图

另外,也有一些一直使用 npm 安装的用户跟帖表示,自己几乎没有遇到最近大家集中抱怨的这些 bug。

配图

随后,评论区里大家做了进一步比对,发现这些“基本不受影响”的用户,大多都在使用:

  • VS Code 插件
  • 桌面版
  • 网页版

这也进一步强化了一个结论:这个“吞额度”问题,很可能主要集中在 Claude Code CLI 的原生安装包上。

配图

官方也不是完全没动作,新版本开始提高账单透明度

文章最后还提到,作者并不能完全判断:Extra Usage 时降级缓存,到底是有意设计,还是工程疏忽。也有可能是某种成本优化策略,只是没有充分考虑连锁反应。

不过,有一个值得注意的新变化是:在最近更新的 Claude Code v2.1.92 版本里,官方已经开始加强账单透明度。

现在用户运行 /cost 命令时,CLI 会展示基于不同模型以及缓存命中(Cache-hit)情况的详细费用拆解。

除此之外,新版本还增加了“缓存过期”的主动提醒。

也就是说,当 Pro 用户返回某个会话时,底部状态栏现在会直接提示:

  • 当前 Prompt Cache 已经过期
  • 下一轮对话预计会发送多少未经缓存的 Token

某种意义上,这也算是一种“事先声明”——它不再像之前那样静默扣费,而是提前告诉你:接下来的这次提问可能会很贵。

配图

真正让开发者不安的,不只是贵,而是黑盒感

之前很多开发者担心的是:AI 会不会取代程序员。

但现在,一个越来越现实的问题变成了:AI 工具会不会一边偷懒,一边掏空我们的钱包。

当 Anthropic 在“追求极致体验”和“沉重推理成本”之间来回拉扯时,外界已经越来越难判断,到底哪些是真 bug,哪些是为了控制成本而做的隐性优化。

但有一点是清楚的:开发者真正需要的,不是一个替自己偷偷做决策的黑盒,而是一个透明、可预测、可验证的工具。

当一个产品开始在用户看不见的地方,通过缩短缓存时长、隐藏思考逻辑来平衡自己的账本时,它损耗的不只是几美元的 Token 费用,更是长期积累下来的开发者信任。

如果你担心的是账单和封号这类不可控因素,国内还有一种省心的用法:通过 Code80 调 Claude API。它用真实 Claude 订阅帐号转 API,和官方接口完全兼容,换个 endpoint 就能接进 Claude Code,支持国内支付,省去自己注册和海外付费的环节。想了解可以看 code.ai80.vip

C code80.ai · AI 编码 API 聚合 Claude / GPT 多模型统一接入,稳定不限速,按量计费,几行配置接入 Claude Code。 了解一下 ›

抢沙发

评论前必须登录!

立即登录   注册