Claude Code Pro Max用户1.5小时耗尽配额，技术许诺背后的"文字游戏"

1.5小时，一个荒诞的现实

当你每个月为一个"Pro Max 5x"计划支付真金白银，你期待的是什么？

是充裕的配额。是"Max"应有的体面。

AI配图

但一位开发者的真实经历打破了这个幻想：

配额重置后，轻度使用（主要是问答、轻度开发），1.5小时，配额归零。

注意，这1.5小时里他没有跑什么大项目。没有多文件实现，没有知识图谱管道，没有多智能体协作。只是一个"正常用着"的Claude Code会话。

而就在5小时前，同样是这个会话，进行了5小时的重度开发——全功能实现、多智能体协调、工具密集调用——才耗尽上一个配额窗口。

一个反直觉的事实浮现：

轻度使用比重度开发耗尽配额的速度快了8倍。

问题的核心：缓存读token的"价格双标"

为什么会出现这种荒诞的倒置？

开发者在~/.claude/projects///.jsonl文件中找到了线索。问题指向一个听起来很美的东西：Prompt Caching（提示缓存）。

按照官方说法，cache_read（缓存读取）应该以1/10的价格计入配额。这是Prompt Caching存在的意义——减少重复上下文传输的成本。

但这位开发者的数据显示，如果按1/10计费：

窗口2（1.5小时）的有效token应该是13.1M，约8.7M/小时

这显然不应该耗尽Pro Max 5x的配额。毕竟窗口1在重度开发时也才消耗24.4M有效token/小时。

但如果cache_read按全价计入呢？

窗口2的总消耗变成105.7M tokens，约70.5M/小时

一切都对上了。配额确实会以这个速度耗尽。

但这意味着：Prompt Caching对配额限制完全没有意义。

一个1M上下文的"诅咒"

事情变得更讽刺了。

Anthropic大力宣传的1M上下文窗口，在这场配额游戏里成了一个诅咒。

因为每次API调用都会发送完整上下文。当上下文接近压缩阈值时，单次调用可能携带近100万tokens。

而如果cache_read按全价计入配额——

一次调用 = ~100万配额token
每小时200+次调用 = 配额在几分钟内蒸发

AI配图

更坑的是什么？

**自动压缩（Auto-compact）**会在你毫无察觉时触发。它会产生一次昂贵的调用：用完整的压缩前上下文创建新缓存。这笔开销不来自用户操作，却要从用户配额里扣除。

后台会话也是隐形杀手。

在这位开发者的例子里，token-analysis和career-ops两个会话在后台闲置，没有主动交互，却贡献了103.9M的cache_read。这些同样计入同一个配额池。

一个残酷的计算：

开着3个Claude Code会话，即使什么都不干，它们自己就能把配额消耗殆尽。

官方承认：他们知道，但解决方案是"用回旧版本"

问题上报后，GitHub上出现了官方人员的回应。

Boris（Claude Code团队成员）列出了他们发现的几类问题：

1M上下文的缓存命中率低：Claude Code使用1小时缓存窗口，如果会话闲置超过1小时，缓存几乎必然失效。官方正在考虑默认改为400k上下文，1M改为可选。
后台任务消耗惊人：拉取大量技能、运行多个智能体或后台自动化的情况比预想中更普遍。他们正在改进UX可视性，并计划更智能地调度非主任务。
排查了一堆假设：自适应思维、模型回归、推理回归——都排除了。

AI配图

但最耐人寻味的是这条评论：

"Quite scared by the fact that the original issue pointing out the actual root cause of the issue has been 'Closed as not planned' by Anthropic."

指出真正根问题的issue，被标记为**"Not Planned"**。

用户的"自救"：降级到2.1.34

官方没有快速解决方案，用户开始自救。

一位用户的做法是回退到2.1.34版本，并分享了配置：

{
  "effortLevel": "high",
  "autoUpdatesChannel": "stable",
  "minimumVersion": "2.1.34",
  "env": {
    "DISABLE_AUTOUPDATER": "1",
    "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1"
  }
}

他还额外做了这些：

删除/.local/share/claude/versions/下除2.1.34外的所有版本
将~/.local/bin/claude链接到旧版本

有人反馈这确实"修复了"配额耗尽问题。

一个付费用户要靠降级到旧版本、禁用自动更新、关闭功能，才能正常使用自己付费的服务。

这听起来像什么？像极了那个经典的互联网笑话：

"我为了用好这个产品，不得不假装它没有在更新。"

转折：不只是Anthropic的"特色"

有意思的是，评论区有人提到了一个更大的图景：

"I'm afraid the music may be slowly fading at this party..."

他指的是Google Gemini社区最近也在经历类似的**" bait and switch"**（诱饵切换）——对Pro和Ultra客户的配额预期管理引发众怒。

"We may very well look back on the last couple years as the golden era of subsidized GenAI compute."

这波AI浪潮的计算成本，可能正在从"补贴期"转向"收割期"。

一位用户直言：

"Fair transactions involve fair and transparent measurements of goods exchanged. I'm going to cancel my subscription this month."

当"公平交易"需要用户自己写代码排查、靠降级版本才能实现时，订阅的意义是什么？

尾声：谁在为"Max"买单？

写到这里，我想起Anthropic官网对Pro Max 5x的宣传：

"Maximum power for professional workflows."

"Maximum"这个词很微妙。

它可以是"最大配额"，也可以是"最大消耗"。可以是"最快速度"，也可以是"最快耗尽"。

Prompt Caching的1/10定价，对谁有效？账单上的数字，还是配额池里的计数？

当一个技术许诺（缓存节省成本）在最核心的计量系统（配额限制）里完全不生效时——

这个许诺是bug，还是feature？

我不知道答案。

但我知道一件事：1.5小时耗尽配额这种事，不应该发生在任何"Max"计划上。

【锐评】：技术许诺和实际计费是两套话语体系，当"缓存节省成本"遇上"配额全价计入"，用户就成了那个代价。

参考链接：
https://github.com/anthropics/claude-code/issues/45756