发现这些 bug 的开发者是一位 Claude Max 20x 订阅用户仅 4 月 1 日单天他就烧掉了 43% 的一周配额。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 费更是过去积累下来的、极其珍贵的开发者信任。