1.5 小时就把额度跑光了：Claude Code 的“超大上下文”，正在变成开发者的钱包黑洞？

当“高配套餐”开始像计价器一样狂跳

AI 编程工具最近两年的卖点很统一：上下文更长、代理更强、自动化更深。听起来像是从手动挡升级成辅助驾驶，开发者只需要坐进驾驶位，剩下的让 AI 去跑。可现实往往是，车是更快了，油表也掉得更快。

这次引发讨论的是 Anthropic 旗下的 Claude Code。一位用户在 GitHub 提交 issue 称，自己使用的是 Pro Max 5x 套餐，模型是 claude-opus-4-6，配备 100 万 token 上下文窗口。在额度重置之后，他并没有进行“爆肝式”开发，只是做了问答、轻量开发和一些常规工具调用，结果 1.5 小时内配额就被吃光了。

如果只是用户主观感觉“我没怎么用啊”，这类投诉其实并不新鲜。真正让这条 issue 值得看下去的，是它做了相当扎实的数据拆解：用户直接从本地 ~/.claude/projects/...jsonl 会话文件里提取了 API 返回的 usage 字段，逐条统计 cache_read_input_tokens、cache_creation_input_tokens、input_tokens 和 output_tokens。换句话说，这不是一句“你们乱扣费”的情绪宣泄，而是一份颇像工程复盘的成本审计报告。

问题可能不在“用得多”，而在“怎么算”

这份报告最核心的怀疑点是：prompt caching 的 cache_read token，可能在配额限制里按原价全额计算，而不是像用户预期那样按折扣比例计入。假设这个判断成立，那事情就有点尴尬了——缓存本来是为了降低重复上下文带来的成本，结果在速率限制或额度消耗上却没有真正起到“省钱”效果。

用户给出了一组很有代表性的数据。重置前一个 5 小时窗口里，他进行了重度开发，包括多文件实现、知识图谱流水线、multi-agent 协作，消耗上一轮配额，这可以理解；但重置后 1.5 小时里，主会话只有 222 次 API 调用，峰值上下文约 18 万 token，另外还有两个后台会话在跑，总计 691 次调用。如果把 cache read 按 1/10 的“有效输入”来算，总消耗约 1310 万 token，折合每小时 870 万，这看起来不像一个 Pro Max 5x 会轻易顶不住的量。

但如果 cache read 实际是按全额计入，那就完全是另一幅面孔：1.5 小时大约消耗 1.057 亿 token，折合每小时 7050 万。这个速度下，配额被迅速榨干就不奇怪了。也就是说，用户感觉自己“只是开着巡航”，系统内部却可能在按“地板油”收费。

这也是这条 issue 最值得行业警惕的地方：AI 产品的“价格表”与“体感账单”之间，可能存在一个巨大的认知鸿沟。你以为自己买的是包月健身卡，实际却像进门后发现跑步机、哑铃和更衣柜都另算。

100 万上下文，本来是王牌，怎么成了反噬

Claude Code 这类工具的优势之一，就是超大上下文。100 万 token 在宣传页上很漂亮，它意味着模型可以长时间记住项目状态、跨多个文件理解代码关系，还能少丢上下文、少让人重复解释需求。这对复杂工程任务确实很有吸引力。

问题在于，大上下文是有“惯性”的。用户在 issue 中提到，Claude Code 会随着会话推进不断累积上下文，并在接近阈值时触发 auto-compact。一次典型轨迹是：上下文从 3.2 万 token 长到 78.3 万，压缩；再从 3.9 万长到 96.6 万，再压缩；然后重新开始。理论上，缓存应该帮用户避免每次都为整段上下文重复付费，但如果缓存读取在额度上按全价算，那么每一次 API 调用都像在背着整本项目档案馆出门。

这会带来一个很反直觉的后果：上下文越大，产品越“聪明”；但如果计费或配额策略没跟上，产品也会越“贵”，甚至贵到让人不敢用。更麻烦的是，auto-compact 这种系统自动行为，本来是为了提升体验，结果却可能制造最昂贵的一次调用——在用户没有额外操作的情况下，系统自己把接近 100 万 token 的旧上下文打包处理掉。

这类现象不只是 Anthropic 一家会遇到。OpenAI、Google、Cursor、GitHub Copilot 乃至一批新兴 AI IDE，都在走向“代理化”和“长上下文化”：工具自动读文件、自动跑测试、自动总结、自动续写，开发者获得更少的打断，但后台 token 消耗也变得越来越不透明。过去我们衡量软件成本，靠的是 seat 数、API 次数或算力时间；现在则多了一个更难被普通用户直觉掌握的维度：上下文搬运成本。

后台会话偷偷吃额度，才是最像现实生活的那一刀

如果说 cache read 计费争议属于技术层面的“算法问题”，那后台会话共享额度，则是产品设计层面的“生活问题”。用户提到，自己并没有主动操作某些会话，但别的终端里开着的 Claude Code session 仍在持续发起调用，包括 compact、retros、hook processing 等。换句话说，你以为自己已经下班了，实际上团队里还有两个“AI 实习生”在办公室里通宵加班，而且工资从你账户里扣。

这很像今天大量 AI 代理产品的共同症状：它们越来越自主，也越来越不安静。传统软件在用户不点击的时候，大多是静止的；而代理软件在你不盯着时，可能仍在读、写、想、总结、回放和触发工具链。自主性越强，越需要“可见性”——谁在跑、跑了什么、为什么跑、跑掉了多少额度，都应该被摆在台面上。

从用户体验角度看，一个成熟的 AI 编程产品至少应该提供三层保障：第一，实时可视化的配额仪表盘，而不是等额度见底后才给你一个红字提醒；第二，后台会话的资源隔离或休眠机制，让闲置 session 不至于悄悄吞掉主会话预算；第三，把自动压缩、自动总结、自动工具调用这些“隐性高成本行为”明确标识出来，让用户知道哪里在烧 token，哪里在真正创造价值。

今天不少 AI 工具还停留在“能做很多事”的阶段，但企业级和专业开发者真正关心的，已经是“它花钱是否可预测”。可预测，往往比便宜更重要。因为团队预算最怕的不是高，而是飘。

这不只是一个 bug，而是 AI 编程进入深水区的信号

这条 GitHub issue 被打上了 area:cost、bug 和 platform:wsl 标签，目前公开页面显示仍处于开放状态。从报道角度看，我们当然不能仅凭单一用户数据，就断言 Anthropic 的配额逻辑一定存在系统性错误；也不排除 WSL、长期会话、并发 session、自动 compact 与具体模型策略叠加后，出现了用户体感与平台规则不一致的情况。

但即便把它当作一个个案，它仍然非常有代表性。原因很简单：AI 编程工具正在从“单轮问答”升级为“持续工作的软件代理”，而旧时代的计费解释框架已经不够用了。以前你问一个问题、拿一个回答，账单还算直观；现在一个请求背后，可能牵出文件读取、规则注入、缓存访问、上下文回放、自动压缩、后台总结，最后用户看见的只是屏幕上那一句轻描淡写的回复。真正的成本路径，被隐藏在一层又一层自动化之下。

这也提出了一个很值得行业思考的问题：当 AI 产品越来越强调“无感智能”时，是否也在无感地消耗用户的预算和信任？如果供应商继续把“更长上下文、更强代理、更高自动化”作为核心卖点，那就必须同步给出更透明的成本说明。否则，100 万上下文就可能从能力神话，变成使用焦虑。

站在竞争角度看，这反而是给所有 AI IDE 厂商提了个醒。接下来谁能把“性能、价格、配额、可观测性”一起做明白，谁才更有机会吃下专业开发者市场。毕竟程序员可以接受 bug，却很难接受一笔说不清楚的账。尤其当这笔账，还是在你没怎么碰键盘的时候自己长出来的。