Claude Code 误判与额外计费：Theo 谈 Anthropic 的信任问题

我不喜欢再做一期批评 Anthropic 的视频，但这次 Claude Code 的计费事件值得关注。一名订阅用户称，自己的每周额度还剩大部分，却产生了意外的额外费用。公司随后承认存在错误；这件事也引出了一个更大的问题：订阅限制如何影响普通开发流程。

这里要区分两种产品：订阅让个人在使用限制内访问 Claude Code，而 API 按用量收费。Anthropic 限制某些第三方工具使用订阅凭据；正是在这一政策背景下，检测机制把一次正常会话误判了。

对支付固定订阅费的开发者来说，合理的预期是套餐内使用由套餐覆盖；额外用量则是单独付费的选项。报告中的问题并非只是正常额度耗尽，而是系统把某些使用归到了额外计费路径。

最初的报告涉及 Git 上下文中出现 HERMES.md 字样。这并不说明所有同名文件都会触发收费，也不能据此断定检测逻辑的具体实现。令人担忧的是，普通项目上下文竟可能与第三方工具检测发生交互并影响计费。

我仍保留 Max 订阅用于测试。高档套餐包含的推理量可能相当可观，这也是固定价格访问为何有经济意义。正因如此，用户更需要清楚自己何时消耗订阅额度，何时会进入另一套计费方式。

服务商担心第三方工具有一个可能的原因：不同工具发送的提示词和资源使用方式不同。但潜在的经济压力不能成为限制不透明或计费错误的借口。要讨论成本，首先得了解提示词缓存。

模型处理输入 token 后生成输出。当多个请求共享很长的前缀时，提示词缓存可以复用该前缀的中间计算结果，避免每次重新处理。提示词不会改写模型权重；缓存状态只是重复推理的一种优化。

编码代理会反复发送指令、对话历史和工具结果等上下文。如果可复用的前缀保持稳定，缓存就能减少重复计算和费用；如果前面的内容变化，受影响的后续前缀可能无法命中，所以工具如何组织上下文很重要。

缓存有效期和价格同样影响结果。短期缓存可能在两次请求之间过期，创建和保留缓存状态本身也有成本。最佳选择取决于请求频率、共享前缀长度和服务商的具体条款，不能只看单一价格。

我以前就抱怨过 Claude Code 的缓存行为和变化。我在这里推测，公司可能想控制第三方工具因缓存效率较低而带来的成本。这只是我对其动机的理解，不能证明 Anthropic 的内部决策，也不能证明这次错误的具体成因。

系统提示词中位置不合适的改动可能降低缓存复用效率，工具框架的变化也可能影响用户实际感受到的行为。这些实现细节会产生真实影响：即使看不到底层机制，用户也会看到延迟、账单和回答质量的变化。

我也曾认为 Claude Code 在此前的变化中变得不那么可靠。更大的问题是，AI 产品不只有模型权重：提示词、上下文管理、缓存和工具共同构成体验。诊断退化时，应区分这些层次，而不是直接认定基础模型发生了变化。

来看 T3 Chat 的实际账单。我们通过 Anthropic API 处理大量请求，因此这是 API 支出，不是我个人的订阅费用。我们的四月用量面板显示，各模型合计约 110 亿输入 token 和 6.5 亿输出 token。

这个面板展示了规模，但 token 总量本身不足以解释账单。模型组合、输出量、缓存写入和缓存读取都会影响工作负载的成本。即使使用同一个模型，不同产品的请求模式也可能很不一样。

四月的 token 成本视图约为 39,818 美元。我说过，账单中很大一部分来自缓存写入；大约在 4 月 20 日，我们让这项工作负载停止使用缓存。观察之后的每日总额，我没有看到明显的账单下降。

这个观察让我意外，但它并不是受控实验。流量、模型组合、提示词长度和其他因素可能同时变化。它提醒我们检查自己的实际用量，而不是假定缓存必然省钱；它不能证明缓存对所有人都没有用。

我认为，限制外部工具不是解决成本问题的好办法。开发者有充分理由构建自己的工作流程，而 Claude Code 正常功能与外部集成之间的边界也可能令人困惑。计费政策需要可预测的边界和清楚的反馈。

Claude Code 本身支持通过 `claude -p` 非交互式发送提示词，也提供修改系统提示词的选项。我用这些功能说明，依据文本检测第三方工具可能很脆弱：合法命令和普通上下文也可能包含看起来像某种集成的内容。

演示中，我构造了一段包含其他代理相关文本的提示词，随后出现了额外用量提示。这展示的是我的测试结果，不能独立揭示服务器端实现，也不能证明所有类似请求都会得到同样的分类。

关闭额外用量时，我看到的是错误，而不是成功的请求。随后我打开付费选项并重复测试。这个区别很重要：演示中的付费路径需要先启用额外用量，但对于已经启用它的人来说，意外误判仍可能造成账单惊喜。

测试中，即使我调用的是 Claude Code 本身，用量似乎仍被计入了额外用量。我对此感到担忧，因为提示词中的字样不应悄悄改变客户对费用的预期。我对检测机制的推断仍然只是一个假设。

再回到最初的报告。该订阅者说，自己的每周订阅额度只用掉一小部分，却产生了约 201 美元的费用。相关文本出现在 Git 上下文中，工具又把它带进了提示词；当事人表示自己是在正常使用 Claude Code。

这里需要区分针对第三方工具的有意政策，与误伤正常使用的误报。服务商可以制定订阅条款，但客户需要知道条款内容，也需要在检测器出错时免于意外收费。

Anthropic 工程师 Thariq Shihipar 道歉并表示，错误涉及第三方工具检测与将 Git 状态引入系统提示词的方式发生交互。他说公司正在联系受影响用户，提供退款和额外一个月的额度；这个案例中额外额度为 200 美元。

公开 issue 记录了这次报告与回应：https://github.com/anthropics/claude-code/issues/53262。公司的承认支持这次具体故障的存在，但并不意味着所有可能受影响的人都已收到退款，也不证明整个问题已经解决。

向受影响客户退款并补偿额度是正确的回应。我的批评还在于：如果系统根据可能包含普通仓库数据的上下文来决定用户的计费分类，那么这类误报就是产品设计问题，而不仅仅是一条尴尬的错误信息。

我对团队的批评一直很严厉，也区分了开发产品的员工和管理层作出的决定。我感到沮丧，是因为类似问题反复出现：限制、令人困惑的变化，以及让开发者觉得正常工作受到怀疑的体验。

我对 Anthropic 管理层的态度和动机有所猜测，但这些个人判断不是已证实的事实。可以观察到的问题更具体：检测政策与 Git 上下文的交互产生了公司承认的误报，并带来了计费后果。

我更大的不满是信任问题。开发者被要求把 AI 工具深度融入工作，但规则和成本可能在底层发生变化。希望获得长期采用的公司，需要让限制易于理解，也要在系统层面解决意外故障。

我还讲到 T3 Chat 的另一次事件：Anthropic API 自动续费失败，我们的用户一度无法使用其模型。这是我对自身运营经历的描述，不能独立证明所有客户都遇到了同样的计费故障。

尽管我们在这项服务上花费很高，我仍觉得这种关系变得不必要地对立。我把自己的经历与其他服务商作比较，并解释为什么可能把更多工作转移出去。这些比较反映的是我的经验和偏好，并非对所有服务商的普遍排名。

强大的模型很有价值，但开发者平台还需要可靠的计费、清楚的政策，以及对日常工具的信任。我的结论是，公司应处理这次事件背后的激励和产品选择，不能只在用户发现费用后道歉。

我仍是一个支出可观的客户，这也正是这些故障对我重要的原因。我希望产品能服务好开发者，让他们不用担心普通项目数据会改变一次会话的价格。