近期开发者社区频繁报告 Claude Code 及相关托管代理服务出现异常高的 token 消耗现象，部分用户的月度 API 费用在短时间内暴增数倍，更有托管代理因资源耗尽而崩溃。这一问题的核心在于系统提示词的 token 计数存在漏洞，导致本应被缓存或优化的内容被重复计入上下文，进而引发连锁反应。
问题现象与影响范围
根据多个开发者反馈，Claude Code 在处理包含系统提示词的请求时，存在几类典型的计量异常。第一类是大规模 token 泄漏问题：有用户报告在短短五小时内产生了惊人的 token 消耗量，远超正常业务逻辑所能解释的范围。第二类是每条消息的初始 token 开销异常增高 —— 即使是最简单的用户查询，也会在上下文窗口中加载大量系统提示词和工具描述，导致单次交互的成本远超预期。第三类问题涉及托管代理层面，由于代理服务需要实时监控和转发请求流量，当上游 API 的计量数据出现剧烈波动时，代理服务的资源调度和计费系统可能面临过载风险。
这些问题的影响范围不仅限于个人开发者，还波及到使用 Claude API 构建商业服务的托管代理运营商。这些运营商通常会在上游 API 之上封装一层业务逻辑，负责请求分发、流量控制和数据统计。当上游的 token 计量出现不可预期的跳动时，代理的计费模块可能出现计算错误，导致向终端用户少收费或多收费的情况。更严重的是，某些代理服务在检测到异常高的资源消耗时，会触发内置的保护机制自动断开连接，造成服务不稳定甚至全面宕机。
技术根因分析
从技术层面剖析，这一问题涉及多个层面的设计缺陷。首先是系统提示词的加载策略：Claude Code 在每次建立新对话或发送首条消息时，会将完整的系统提示词、工具描述以及 MCP 服务器配置全部加载到上下文窗口中。这些内容可能占据数千甚至上万个 token，但开发者在实际使用中往往只关心用户输入和模型输出的 token 消耗，忽略了这一固定开销的叠加效应。当系统提示词较长或包含大量工具定义时，这个初始开销会变得相当可观。
其次是缓存机制的失效或不完善。理论上，系统提示词只需要在会话开始时加载一次，后续消息可以通过缓存复用，从而避免重复计费。然而实际使用中，缓存机制可能因为多种原因失效：代理服务的重启、上下文窗口的自动压缩、以及某些特殊的错误恢复流程，都可能导致系统提示词被重新加载。更棘手的是，即便缓存正常工作，Claude 的内部实现可能仍然将缓存的提示词计入 token 总数，只是以不同的方式统计，导致开发者看到的计量数据与实际 API 消耗存在偏差。
第三类根因涉及自动压缩功能与 token 耗尽的恶性循环。当上下文窗口接近 token 上限时，Claude Code 会触发自动压缩机制来释放空间。这一机制在设计上存在一个副作用：它可能在压缩过程中错误地保留某些系统提示词的副本，同时丢弃用户认为重要的历史对话内容。结果是 token 消耗不降反升，用户为实际上已经 “消失” 的内容付费。
资金浪费的量化评估
为了更好地理解这一问题的严重性，我们可以进行定量化分析。假设一个托管代理服务每天处理十万次用户请求，平均每条消息的正常 token 消耗为五百个（包含输入和输出的典型比例）。在理想情况下，即系统提示词仅在会话开始时加载一次且后续完全缓存，单个会话的总 token 开销约为两千五百个。然而，由于上述 bug 的存在，系统提示词可能在每条消息都被重复加载或以其他方式计入总量，导致实际消耗可能达到五千甚至一万个 token。这意味着单个会话的成本可能增加两到四倍，对于月度处理数百万条消息的托管服务而言，这额外增加的成本可能是数万甚至数十万美元。
更值得关注的是，这种成本增加往往具有隐蔽性。开发者在初期可能只会注意到 API 费用的轻微上涨，将其归因于业务量的自然增长。直到收到月度账单时，才会发现费用远超预期，此时再去追溯问题根源已经变得困难。部分开发者报告称，他们在发现问题后尝试联系 Anthropic 支持团队，但得到的响应往往不够及时或详细，导致问题长期得不到解决。
工程防护策略
面对这一计量漏洞，托管代理运营商和开发者需要采取多层次的防护措施。在请求层面，建议在发送请求前自行计算并记录 token 消耗，特别是系统提示词的预估长度。通过在代理层实现 token 预算机制，可以在请求发送前检测出异常高的 token 预估值，从而触发告警或拒绝服务。例如，当检测到单条消息的输入 token 超过某个阈值（如预设上限的百分之七十）时，自动触发人工审核流程。
在监控层面，应当建立实时 token 消耗仪表盘，追踪每个会话、每个用户乃至整个服务的 token 使用趋势。当某项指标出现异常波动时，系统应当自动生成告警并记录上下文信息，供后续分析使用。建议设置多级阈值：轻度异常（如增长超过百分之二十）触发警告，严重异常（如增长超过百分之百）触发自动限流或熔断。
在架构层面，可以考虑在代理层实现 token 消耗的预计算和校验逻辑。具体做法是在向上游发送请求前，先使用本地部署的 token 计算器预估本条消息将产生的 token 数量，然后与上游返回的计量数据进行比对。如果两者存在显著差异（例如超过百分之十），则记录异常并标记该请求供后续排查。这种双向校验机制虽然会增加一定的计算开销，但能够有效捕获计量异常，避免长期累积的资金损失。
在业务层面，建议与终端用户在合同或服务条款中明确约定计量争议的处理方式。当出现异常高额的 API 费用时，托管代理应当有能力向上游追溯并申请费用减免，同时也需要有机制向终端用户解释和协商调整。此外，定期审计 API 费用与业务量的匹配度，建立费用预警机制，也是控制财务风险的有效手段。
结语
Claude 系统提示词的 token 计数漏洞揭示了 AI 服务计量层面的系统性风险。对于依赖 API 计费的托管代理服务而言，这种计量异常不仅导致直接的财务损失，还可能引发服务稳定性问题和用户信任危机。通过在请求、监控、架构和业务多个层面建立防护机制，运营商可以在一定程度上缓解这类风险。然而要从根本上解决问题，仍需 Anthropic 官方正视并修复这一计量漏洞，并在文档和 API 响应中提供更透明的 token 消耗明细。
资料来源：GitHub Anthropic Claude Code Issues 社区讨论