Claude Code 5 小时额度为什么几十分钟就用完?
作者 vortwang更新于
通常是因为每次请求都重发整个对话。Anthropic 成本文档列出的原因:每次请求都发送完整对话;闲置超过缓存有效期(订阅为一小时)后第一条消息重新处理全部上下文;定时任务与跨会话消息在闲置时也带完整上下文触发;agent teams 约 7 倍 token;/compact 本身就是大请求。先运行 /usage 看是哪一项。
官方文档怎么说
Claude Code sends your full conversation with every request
引自 Claude Code docs: Manage costs effectively — Why usage climbs in a long session The lifetime is an hour on a subscription and drops to five minutes once you're drawing on usage credits
引自 Claude Code docs: Manage costs effectively — Why usage climbs in a long session Agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode
引自 Claude Code docs: Manage costs effectively — Manage agent team costs (approximately 7x more tokens) Thinking tokens are billed as output tokens, and the default budget can be tens of thousands of tokens per request
引自 Claude Code docs: Manage costs effectively — Adjust extended thinking (/effort, MAX_THINKING_TOKENS) flagged when one accounts for 10% or more of recent usage
引自 Claude Code docs: Manage costs effectively — Plan usage breakdown in /usage some Claude Code sessions to spawn excessive parallel subagents, burning through usage faster than expected
引自 @ClaudeDevs on X, 2026-06-01: limits reset after a bug spawned excessive parallel subagents, "burning through usage faster than expected"
怎么算
从 /usage 开始。在 Pro、Max、Team 或 Enterprise 计划上,它显示计入计划限额的用量拆分:按 skill、subagent、插件与 MCP 服务器的归因,以及长上下文或缓存未命中等行为标记(占最近用量 10% 以上时标出)。改任何设置之前先看它对应下表哪一行。
最大的杠杆是上下文。文档说开了一整天的会话里问一句话,仍然会为整个对话消耗用量。/clear 开新会话不花额度;/context 显示窗口里装了什么;/compact 压缩对话,但压缩大上下文本身就是一次大请求。
订阅上缓存有效期很关键。闲置超过缓存有效期后的第一条消息会未命中缓存并重新处理全部上下文。有效期在订阅上是一小时,一旦开始使用用量积分则降为五分钟。Anthropic 没有公布 5 小时窗口的绝对消息数;Max 计划文章只以 Pro 为基准定义倍数。
用户报告掉得很快(例如 issue #90675:Max 5x,重置后约 23 分钟 5 小时额度用尽)。这些是用户报告,不是公布的速率。Anthropic 在 2026-06-01 确认过一个系统性原因:一个 bug 让部分 Claude Code 会话生成过多并行 subagent,把用量烧得比预期快,修复后为所有人重置。
| 原因 | 文档怎么说 | 怎么做 | 来源 |
|---|---|---|---|
| 长上下文 | 每次请求都发送完整对话;每一批工具结果又是一次带着它的请求 | /context 看窗口里装了什么;/clear 开新会话(不花额度);/compact 压缩 | [1] |
| 休息后缓存失效 | 闲置超过缓存有效期后的第一条消息重新处理全部上下文;订阅上有效期一小时,用量积分上五分钟 | 有提示时从摘要恢复;离开前别把长会话越堆越大 | [1] |
| 定时任务(/loop、/schedule) | 定时任务按间隔触发,即使闲置也每次发送完整上下文 | /usage 里每个任务一行 Loops;停掉不再需要的任务 | [1] [4] |
| 跨会话消息 | 会话闲置时作为新一轮送达,每次发送完整上下文 | 把 crossSessionInbound 设为 hold | [1] |
| agent teams 与 subagent | 队友在 plan mode 下运行时约 7 倍 token;每个队友退出前一直消耗 | 团队保持小、队友用 Sonnet、做完就关掉 | [2] |
| 扩展思考 | 思考 token 按输出计费;默认预算每次请求可达数万 | /effort 调低档位;固定预算模型用 MAX_THINKING_TOKENS | [3] [5] |
| 压缩 | /compact 要读完它所压缩的对话,压缩大上下文本身就是一次大请求 | 不需要连续性时优先 /clear | [1] |
| 公布的每 5 小时消息数 | 未公布;Max 5x 与 20x 定义为 Pro 每会话额度的 5 倍与 20 倍 | 在状态栏里盯 rate_limits.five_hour.used_percentage | [6] [9] |
常见问题
每 5 小时能发多少条消息,有公布的数字吗?
没有。Anthropic 只以 Pro 为基准定义 Max 5x 与 Max 20x(每会话额度的 5 倍与 20 倍),并说用量随消息长度、对话长度和模型而变。「23 分钟用完」之类是用户报告,不是公布的速率。
哪个命令能看出是什么耗掉了窗口?
/usage。在 Pro、Max、Team、Enterprise 上它把最近用量归因到 skill、subagent、插件和 MCP 服务器,长上下文或缓存未命中占 10% 以上时标出来,并列出最重的定时任务。按 d 或 w 在最近一天与一周之间切换。
离开吃个饭会有消耗吗?
下一条消息可能会。订阅上 prompt cache 保持一小时;休息更久之后第一条消息会重新处理全部上下文。Pro 与 Max 上,长时间离开后恢复大会话时会提示从摘要恢复,之后的请求就不用带完整历史。
subagent 和 agent teams 算进我的 5 小时额度吗?
算。每个队友有自己的上下文窗口,文档把 agent teams 在 plan mode 下的消耗定为标准会话的约 7 倍。2026-06-01 Anthropic 因一个生成过多并行 subagent 的 bug 为所有人重置了额度。
来源
- Claude Code docs: Manage costs effectively — Why usage climbs in a long session核实于 2026-09-18
- Claude Code docs: Manage costs effectively — Manage agent team costs (approximately 7x more tokens)核实于 2026-09-18
- Claude Code docs: Manage costs effectively — Adjust extended thinking (/effort, MAX_THINKING_TOKENS)核实于 2026-09-18
- Claude Code docs: Manage costs effectively — Plan usage breakdown in /usage核实于 2026-09-18
- Claude Code docs: Slash commands — full command table (/usage, /usage-credits, /rate-limit-options, /status, /cost, /stats)核实于 2026-09-18
- Claude Help Center: What is the Max plan? (session resets every five hours; weekly at a fixed time assigned to your account)核实于 2026-09-18
- anthropics/claude-code issue #90675 (2026-08-30): Max 5x, entire 5-hour usage limit exhausted ~23 minutes after reset核实于 2026-09-18
- @ClaudeDevs on X, 2026-06-01: limits reset after a bug spawned excessive parallel subagents, "burning through usage faster than expected"核实于 2026-09-18
- Claude Code docs: Status line — Rate limit usage (rate_limits.five_hour / seven_day)核实于 2026-09-18