Claude Code 限额在 2026 年的两次变化：翻倍、重置与那个没对上的重置周期

数据截至 2026-07，价格与限额以各官网为准。

如果你对 Claude Code 限额的印象还停留在 2026 年上半年之前，那份印象已经不准了：官方在 5 月把 5 小时限额永久翻倍并取消了高峰时段的额度缩减，6 月又因为一个会多烧用量的缺陷给所有 Pro 和 Max 用户做了一次性重置。这两件事叠在一起，意味着你从旧教程、旧帖子里抄来的”每窗大概能发多少条”的经验值，基本都要作废重估。

先承认一个很常见的误解：不少人以为 5 小时窗是按整点走的，比如”每天 0 点、5 点、10 点各刷新一次”，于是掐着点等重置。这个理解是错的，后面第一节会专门讲清楚——它是从你发出第一条 prompt 那一刻开始计时的滚动窗，跟墙上的钟没关系。搞错这一点，你等的那个”重置时刻”可能根本不存在。

变化一：5 月 6 日，5 小时限额永久翻倍

2026 年 5 月 6 日，Anthropic 宣布永久把 Claude Code 的 5 小时限额翻倍，覆盖 Pro、Max、Team 以及按席位计费的 Enterprise。同一次公告里还有两件相关的事：此前对 Pro 和 Max 施加的高峰时段限额缩减被取消，Opus 的 API 限额也做了大幅上调。

官方把这次调整归因于新增算力上线，公告里给出的数字是超过 300 兆瓦、约 22 万张 NVIDIA GPU。这个背景值得留意的地方不在于数字本身，而在于它说明了一件事：这类限额并不是一条写死的产品规则，而是跟供给能力挂钩的动态参数。供给宽裕时可以放，供给紧张时也可能收——所以任何”我记得额度是多少”的经验，保质期都有限。

对日常使用的实际影响有两层。第一层是显性的：同样一段工作时间里，你能发出的 prompt 条数比翻倍前多。第二层容易被忽略——高峰时段缩减的取消，意味着”错峰使用”这条老策略的收益变小了。翻倍前很多人会刻意避开白天的忙时，把重活挪到深夜跑；取消缩减之后，这套时间安排带来的额度优势不再明显，你更该按自己的工作节奏安排，而不是迁就一个已经不存在的规则。

变化二：6 月的一次性额度重置，以及它暴露的问题

2026 年 6 月，Anthropic 为全部 Pro 和 Max 用户重置了 5 小时与周限额。这是一次性动作，不是常规机制，所以别指望它会再来。

真正值得读进去的是重置的原因：官方修复了一个缺陷——某些 Claude Code 会话会派生过多并行子代理，比预期更快地烧掉用量。重置是对这段时间内被误伤用户的补偿。

这条信息对你有直接的操作价值。它等于官方承认了一件事：并行子代理是用量的放大器。一个会话如果在后台同时铺开好几个 agent，各自都在读文件、跑工具、来回对话，用量的消耗速度跟你肉眼看到的”我才发了几条消息”完全对不上。如果你平时会写 subagent 或者用并行工作流，撞限额时值得先怀疑这一层，而不是先怀疑自己聊得太多。关于 subagent 本身怎么配置和什么时候该用，可以看 Claude Code 自定义 Subagent 怎么写。

两层限额到底怎么计时

把结构讲清楚，比记住任何一个数字都有用。Claude Code 的限额是两层叠加的。

5 小时滚动窗，限制的是一个会话里能发多少 prompt。关键在于计时从你发出第一条 prompt 开始，而不是整点时钟。举个例子：你 10:00 发出当窗第一条，那么 15:00 重置，中间你是发了 3 条还是 30 条，都不改变 15:00 这个重置时刻。理解这一点之后，有一个很实用的推论——如果你打算做一件重活，别在正式开工前先随手问一句闲话，那一句闲话就已经把窗口的计时起点提前了，等你真正进入状态时，可用窗已经被消耗掉一段。

周限额是第二层。官方帮助中心的说法是：按账户被分配的固定时刻每周重置，重置日与时刻不随你什么时候开始使用、什么时候订阅而改变，每个周期给满额度。也就是说，你的”周一”未必是别人的”周一”，这是账户维度的分配，不是全平台统一时刻。

至于每窗到底能发多少条——第三方汇总的口径是 Pro 每窗大约 10 到 45 条，Max 20x 最高约 900 条。这组数字是第三方汇总口径而非官方逐字表述，具体以官方页面和你账户里实际显示的为准。区间跨度这么大也不是含糊其辞：实际条数取决于 prompt 的长度、上下文的大小和你选的模型。同样是”一条 prompt”，在一个塞满了长文件的上下文里发出去，跟在干净会话里发出去，代价差得很远。这也是为什么上下文管理直接就是额度管理，具体做法可以看 Claude Code 上下文管理：/compact 与 /context 怎么用。

一个必须诚实说出来的矛盾：周限额真的是每周吗

这一节可能是全文最该看的。

有开发者（GitHub 上一份流传较广的 gist）在 2026 年 6 月 9 日到 6 月 20 日、约 11 天时间里持续监测账户的 utilization 字段，得出的结论是”周限额”实际上大约每 72 小时重置一次，而不是每 7 天。更值得注意的是，该 gist 的评论区显示，不同账号、不同档位观察到的重置日差异很大。

必须把话说明白：这是第三方实测记录，与官方文档的表述不一致，不能当成官方事实来引用。我不知道差异的成因是什么——可能是官方对不同账户的分配策略本就不同，可能是监测口径与官方定义不是一回事，也可能中间还有别的变量。把它写进来不是为了给出一个”真实答案”，而是为了给你一条更稳的行为建议：

不要把任何假定的周期长度写死进你的自动化脚本。 如果你写了个脚本，逻辑是”每 7 天的某个时刻自动开始跑批量任务，反正额度刚重置”，那么一旦实际周期跟你的假设对不上，脚本会在额度已经见底的时候持续撞墙，而你可能要过很久才发现。稳妥的做法是让脚本去读实际状态再决策，而不是靠算日历。

撞了限额之后，哪些路能走、哪条走不通

先说那条走不通的，因为它是最多人的第一反应：客服无法实时手动为你重置或延长配额。写工单、催客服、在社群里 at 官方账号，都不会让额度提前回来。把这个期待放下，能省下不少焦躁的时间。

能走的路有这么几条：

• 先用 /status 看清楚现状。撞限额时最要紧的是搞明白你撞的是 5 小时窗还是周限额——前者等一等就恢复，后者等一等基本没用，两种情况的应对完全不同。别凭感觉猜，先看命令输出。
• 开启 usage credits，在包含额度用完之后继续使用。
• 改走 Claude Console 账号的按量付费。订阅额度和 API 按量是两套不同的计费逻辑，按量付费没有滚动窗这一层，代价是花的是实打实的 token 钱。关于 token 怎么算钱、怎么用缓存和批处理压成本，可以看 Claude API 怎么计费？按 token 算钱、各模型价格、省钱调用法。
• 升级订阅档位。这条最直接，但也最该放在最后考虑——先确认你的消耗结构是不是合理的，如果问题出在上下文没收拾干净或者并行子代理开太多，升档只是把撞墙的时间往后推一点。

关于撞限额后的日常应对和省额度技巧，站内另有一篇更偏操作的 Claude Code 撞到用量限制怎么办？计费与额度说明，那篇讲两种计费模型的分辨和省额度的具体手法，跟这篇的时间线视角互补。

中国大陆使用的前提，先说在前面

上面所有关于限额、档位、按量付费的讨论，都建立在一个前提上：你能合规地使用官方服务。这一点需要诚实说明——Anthropic 官方公布的受支持国家/地区列表不含中国大陆（anthropic.com/supported-countries），注册、控制台与 API 端点都在境外。

市面上确实存在第三方中转类服务，但本文不提供也不背书任何具体渠道，这类服务的合规性与稳定性风险由使用者自行承担，并且用它们的时候，本文讨论的官方限额规则未必适用——中转方有自己的配额和计费口径。准入政策也会变，以各官网当前的地区政策页为准。

局限与不确定的部分

有几件事我没法替你确定，说出来免得你按错误的预期行动：

• 每档具体能发多少条 prompt，官方本身给的就是区间，且随上下文和模型浮动，任何一个精确数字都不该被当成承诺。
• 上面提到的两次变化是 2026 年内的官方公告；这类参数跟算力供给挂钩，之后还会不会再调，无从预判。
• 周限额的实际重置周期存在实测与文档不一致的情况，本文只如实呈现这个分歧，不给出结论。

小结

2026 年 5 月 6 日的翻倍加上高峰时段缩减的取消，让 Claude Code 的可用量明显宽松，也让”错峰使用”这套老策略的收益变小了。6 月那次针对全体 Pro 和 Max 用户的一次性重置是缺陷补偿，不会再来，但它暴露的问题——并行子代理会比你感觉到的更快烧掉用量——是长期有效的排查线索。5 小时窗从你的第一条 prompt 开始计时而不是按整点，所以正式开工前别先随手闲聊一句。周限额的实际重置周期存在第三方实测与官方文档对不上的情况，因此别把任何假定周期写死进自动化脚本，让脚本读实际状态再决策。撞了限额先用 /status 分清是哪一层，然后在 usage credits、按量付费、升档之间选，唯独别指望客服帮你手动重置。