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 轮左右
差距已经不是“小贵一点”,而是会实打实改变使用方式。
更麻烦的是,它会形成“死亡螺旋”
作者认为,最糟糕的地方还不是单次费用变高,而是这一机制会形成一个非常典型的“死亡螺旋”:
- 其他缓存相关 bug 先把计划内配额加速消耗掉
- 计划配额耗尽后,自动进入 Extra Usage
- 客户端检测到 Extra Usage,立即把缓存降为 5 分钟
- 用户只要稍微停顿,就触发一次完整重建
- Extra Usage 迅速蒸发
- 用户被迫等待 5 小时重置
- 重置后再次进入同样循环
也就是说,一旦几个 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.69 到 v2.1.90 之间,持续了整整 28 天、横跨 20 个版本。
这个问题会导致会话恢复时丢失关键附件类型,从而让每次恢复都变成一次完整缓存未命中。
这个问题后来已在 v2.1.91 中修复。
3)自动压缩失败后会无限重试
第三个 bug 是自动压缩机制没有熔断器。
一旦压缩失败,Claude Code 会进入无限重试。作者还提到,他在源码注释里发现:内部曾记录过 1279 个会话出现超过 50 次连续失败 的情况。
这个问题已在 v2.1.89 修复。
4)工具结果在客户端被截断,会破坏缓存前缀
第四个 bug 是工具结果会在客户端被截断。
比如:
- Bash 工具的上限是 30K 字符
- Grep 工具的上限是 20K 字符
一旦被截断,残缺的结果就会破坏缓存前缀,进而影响后续缓存命中。
作者表示,这些上限可以在本地配置文件 ~/.claude.json 的 cachedGrowthBookFeatures 字段里看到。
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。








评论前必须登录!
立即登录 注册