Claude Pro Max 5x 配额在 1.5 小时内耗尽，用户质疑缓存读取计费机制
近日，Hacker News 上一则关于 Anthropic Claude 的帖子引发了广泛关注。用户 molu0219 报告称，在使用 Claude Pro Max 5x（Opus 计划） 时，尽管仅进行了“中等使用”（主要是问答和轻量开发），其配额却在 1.5 小时内 迅速耗尽。这与其在配额重置前 5 小时 的“重度开发”工作负载（消耗完上一个配额窗口）形成了鲜明对比，后者被认为是合理的，而前者则出乎意料。
问题核心：缓存读取令牌的计费争议
经过用户调查，问题的根源指向了 cache_read（缓存读取）令牌的计费方式。用户发现，在计算速率限制（quota）时，cache_read 令牌似乎被以 全额速率 计入，而非享受其本应带来的成本效益。这直接抵消了提示缓存（prompt caching）功能在配额方面的优势。
提示缓存 是大型语言模型（如 Claude）中的一项优化技术，旨在减少重复计算。当用户输入与之前缓存过的提示相似时，模型可以直接读取缓存结果，从而节省计算资源和时间。通常，读取缓存的令牌成本应远低于首次创建缓存的成本。然而，根据这份报告，在配额计算中，这种成本优势并未体现。
用户提供的详细数据
用户提供了从会话文件中提取的详细使用数据，以佐证其观点：
- 环境：计划为 Pro Max 5x，模型为 claude-opus-4-6（1M 上下文），平台为 Claude Code CLI on WSL2。
- 窗口1（重置前5小时，重度开发）：
- API 调用：2,715 次
- 缓存读取令牌：1,044M
- 缓存创建令牌：16.8M
- 输入令牌：8.9k
- 输出令牌：1.15M
- 工作负载：涉及完整功能实现、知识图谱管道和多智能体协调，上下文峰值接近 96 万令牌。
- 用户备注：此窗口的配额消耗在预期之内。
- 窗口2（重置后1.5小时，中等使用）：
- API 调用：222 次
- 缓存读取令牌：23.2M
- 缓存创建令牌：1.4M
- 输入令牌：304
- 输出令牌：91k
- 用户指出，正是这 23.2M 的缓存读取令牌 可能被全额计入配额，导致了配额的快速耗尽。
对 AI 服务定价与用户体验的启示
此事件并非孤例，它触及了当前 AI 即服务（AIaaS）领域的一个普遍痛点：计费模型的透明度和公平性。随着 Claude、GPT 等模型能力越来越强，上下文窗口不断扩大，提示缓存等优化技术对于控制用户成本至关重要。
- 技术优化与商业逻辑的错位：从技术角度看，缓存读取理应消耗更少的计算资源。但如果计费系统未将此反映在配额或费用上，用户就无法享受到技术升级带来的实际成本降低，这可能挫伤用户使用高效功能的积极性。
- 开发者体验与信任：对于依赖 Claude Code 等工具进行开发的程序员而言，可预测的成本是高效工作的基础。配额在轻量使用下意外耗尽，会直接干扰工作流程，并可能引发对服务商计费准确性的信任危机。
- 行业竞争背景：在 AI 助手市场竞争白热化的当下，除了模型能力，定价策略、计费透明度和开发者体验 已成为关键差异化因素。任何计费上的争议都可能影响开发者的工具选型。
小结与待解疑问
目前，这仍是一份用户提交的 Bug 报告。报告清晰指出了 缓存读取令牌在配额计算中可能被错误计费 的现象，并附上了详细的数据对比。这为 Anthropic 的工程团队提供了一个明确的调查方向。
对于广大 AI 服务用户和开发者而言，这一事件提醒我们：
- 在享受大模型强大能力的同时，需要密切关注其使用量和计费明细。
- 积极利用社区（如 Hacker News、GitHub Issues）反馈问题，共同推动服务优化。
- 期待 Anthropic 官方能就此问题给出明确解释，并说明其配额计算的具体逻辑，以及未来是否会调整计费方式以更好地体现缓存技术的价值。
最终，一个更透明、更公平的计费体系，将有助于整个 AI 开发生态的健康与繁荣。
