Claude Code Bug 导致 API 成本暴增 10-20 倍：你需要了解的真相

Hero

随着开发者越来越依赖 AI 辅助编程工具来加速工作流，这些工具背后的经济成本正成为一个不容忽视的关键因素。虽然生产力的提升显而易见，但将大语言模型（LLM）直接集成到开发环境中，其隐藏成本有时会让我们措手不及。

最近，关于 Anthropic 推出的基于 CLI 的 AI 编程助手 Claude Code 的一个严重问题被曝光。报告详细指出了一对缓存 Bug，它们会在暗中将 API 成本推高令人咋舌的 10 到 20 倍。对于运行自动化工作流或进行深度代码库分析的团队来说，这不仅仅是个麻烦——它正在快速消耗开发预算。

在本文中，我们将详细剖析究竟发生了什么，这些缓存机制为何失效，这对你的技术栈有何技术影响，以及如何降低收到天价 API 账单的风险。

#究竟发生了什么：双重缓存 Bug

问题的核心在于 Claude Code 如何与 Anthropic 的 API 缓存层进行交互。对于需要反复分析大型代码库的工具来说，提示词缓存（Prompt Caching）是一项至关重要的功能；它允许 API 重用之前计算过的上下文，从而大幅降低延迟和 Token 成本。

根据社区报告，Claude Code 受到了两个与此缓存机制相关的独立 Bug 的影响：

微小修改导致缓存失效： 第一个 Bug 导致整个缓存上下文被过度激进地失效。它没有高效地对比（diffing）差异或保留代码库上下文的主体，而是将微小的文件保存或琐碎的更新作为触发条件，导致缓存彻底未命中（cache miss）。这迫使 CLI 在后续的每一次提示词请求中，都要重新上传和重新处理整个工作区的上下文。
静默降级为无缓存请求： 让情况雪上加霜的是第二个问题：当缓存失效或被清除时，该工具没有向用户发出警告，也没有尝试限制请求频率。它静默降级（fallback）到了标准的、无缓存的 API 调用。由于 Claude Code 通常会传递海量上下文（通常高达数十万个 Token）以提供准确的答案，这导致每个提示词瞬间都背负上了全额、未打折的昂贵账单。

结果如何？开发者在进行标准的、迭代式的编程会话（提问、要求小范围重构、运行测试）时，在不知不觉中，对话的每一个轮次都在疯狂消耗海量的 Token。

#为什么这很重要：上下文窗口的经济学

要理解这个问题的严重性，我们必须审视现代 LLM 的经济学。像 Claude 3.5 Sonnet 这样的模型提供了庞大的上下文窗口（高达 200,000 个 Token）。这对于深度理解代码库来说令人惊叹，但它是需要付出高昂代价的。

下面是一个简化的成本飙升拆解：

正常（有缓存）运行： 你加载了一个 10 万 Token 的代码库。初始加载成本为 0.30 美元（假设输入 Token 价格为 3 美元 / 1M）。后续命中缓存的查询成本只是其中的一小部分，每个轮次大约 0.03 美元。一个 20 轮的会话可能只需花费 0.90 美元。
触发 Bug（无缓存）运行： 这个 10 万 Token 的代码库在每一个轮次都被重新处理。你问的每一个问题仅仅是输入上下文就要花费 0.30 美元。现在，同样一个 20 轮的会话成本变成了 6.00 美元。

如果你是独立开发者，6 到 20 倍的增长可能意味着账单从 5 美元变成 50 美元。但对于有几十名开发者同时运行 Claude Code 的企业团队来说，这个 Bug 会在触发下一个账单警报之前的短短几天内，静悄悄地烧掉数千美元。这种账单的不可预测性让 AI 工具的预算规划变得几乎不可能。

#技术影响：提示词缓存的脆弱性

这次事件凸显了我们在构建和使用 AI 工具时，架构上存在的一个更广泛的脆弱性。LLM API 中的提示词缓存仍是一项相对较新的技术。它依赖于前缀 Token 的精确匹配。

#前缀缓存是如何工作的

当你向支持缓存的 API（如 Anthropic 的 API）发送请求时，系统会对你提示词的开头（前缀）进行哈希处理。如果后续请求拥有完全相同的前缀，系统会直接从内存中检索预先计算好的注意力状态（attention states），而不是重新计算它们。

#它在哪里失效了

在编程助手的场景中，前缀通常由系统提示词（system prompt）紧接着代码库的内容组成。

// Simplified payload structure
{
  "system": "You are a senior developer...",
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "<file name='app.js'>...</file>" }, // Cached
        { "type": "text", "text": "Fix the bug in line 42." } // Dynamic
      ]
    }
  ]
}

如果工具重新排序了文件、修改了 <file> 块中间的哪怕一个字符，或者未能正确构造请求以最大化前缀重叠，缓存就会被破坏。Claude Code 的 Bug 表明，在快速变动、高度可变的环境中（如活动开发期间的本地文件系统）维护这种精密的的状态机是非常困难的。当状态机失效时，其降级机制必须是“故障安全（fail-safe）”的，而不是“故障即破产（fail-expensive）”的。

#应对之道：缓解措施与最佳实践

毫无疑问，Anthropic 正在努力开发补丁来修复 Claude Code 中这些特定的缓存行为。然而，这次事件给依赖高上下文 AI 工具的开发者敲响了警钟。

以下是你现在就可以采取的切实可行的步骤，以保护你的 API 预算：

设置硬性账单上限： 这是最关键的一步。前往你的 Anthropic 控制台，设置一个硬性的月度支出上限。不要仅仅依赖电子邮件警报，因为 API 突发消耗的速度可能比你查看收件箱的速度还要快。
在本地监控 Token 使用情况： 如果你在构建自定义工具或封装 Claude Code，请实现 Token 使用情况的日志记录。跟踪 cache_creation_input_tokens 与 cache_read_input_tokens 的比例。如果读取（read）Token 突然下降，这就是你的早期预警信号。
缩小上下文范围： 除非绝对必要，否则要抵制将整个代码仓库塞进上下文窗口的诱惑。使用允许你专门针对当前任务相关的文件或目录的工具。
关注更新： 保持你的 CLI 工具更新。一旦社区发现这类 Bug，修复程序通常会很快推出。

#结语

将超大上下文窗口集成到本地开发环境中是一次游戏规则的改变，但它需要成熟的基础设施来安全地支撑。Claude Code 缓存 Bug 无情地提醒我们，虽然 AI 工具可以帮我们写代码，但我们仍然需要管理支撑它们的基础设施——以及随之而来的账单。作为开发者，我们必须保持警惕，监控我们的使用情况，并在我们的工作流中构建稳健的故障安全机制，以确保我们的生产力工具不会沦为财务负担。