Claude Code 的"周限额"没那么简单：实测与文档不一致

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

Claude Code 的限额是两层结构：一层 5 小时滚动窗，一层周限额。5 小时那层的规则相对清楚，而”周”这一层，官方文档的说法和一部分开发者的实测记录并不一致——所以最稳妥的做法不是去背某个周期数字，而是永远用 /status 看你账户当下的真实剩余，别把任何假定的重置周期写死进脚本里。

一个很常见的误解是：“周限额嘛，就是每周一清零，跟手机流量套餐一样。“这个类比听着顺，但它把两件事混在了一起：一是重置的时刻由谁决定，二是重置的间隔到底是多久。前者官方有明确说法，后者恰恰是眼下最含糊的地方。下面按这两层结构一个个拆。

第一层：5 小时滚动窗，计时从你发第一条开始

这一层限制的是”一个会话里能发多少条 prompt”。关键在于它的计时起点：从你发出第一条 prompt 的那一刻开始算，而不是按整点时钟。

举个具体的例子。你 10:00 发出今天第一条 prompt，那么这个窗口在 15:00 重置。中间你是连着发了几十条、还是发完一条就去开会了三个小时，都不影响 15:00 这个重置时刻——窗口一旦被”点着”，就按 5 小时走完。

这个机制有两个直接的实操推论：

• 别在真正要干活之前随手试一条。 很多人习惯先发一句”在吗”或者随便让它读个文件确认环境正常，这一下就把窗口点着了。等你半小时后正式开工，可用的窗口时间已经少了半小时。
• 规划长任务时，先算窗口还剩多久。 如果你知道接下来要跑一个大重构，而当前窗口只剩一小时，那要么把大任务拆开、要么干脆等窗口重置了再从头开。中途被截断比一开始就没开始更难受，因为上下文往往还得重新建立。

第二层：周限额，官方怎么说

官方帮助文档的口径是：周限额按你的账户被分配到的固定时刻每周重置。这里有个容易误会的点——这个重置时刻不随你什么时候开始使用、也不随你什么时候订阅而改变，每个周期给满额度。

换句话说，按官方表述，你不能通过”晚点再开始用”来平移自己的重置日；它是账户属性，不是使用行为的函数。这一层的存在意义，是防止某个账号在几天之内把整月的算力吃光，所以它比 5 小时窗更”钝”，日常也更不容易被感知到——直到某天你突然发现 5 小时窗明明重置了，却还是发不出去。

各档到底能发多少条？只能给区间

关于容量，第三方汇总的口径是：Pro 每个窗口大约 10-45 条 prompt，Max 20x 最高约 900 条。这个数字得先加两个限定：

第一，它是第三方汇总的说法，不是官方逐字承诺的数值，具体请以官方页面和你账户里实际显示的为准。

第二，也是更重要的一点——实际条数取决于 prompt 的长度、上下文大小和你选的模型。这就是为什么官方本身给的是区间而不是定值。同样是”一条 prompt”，在一个刚开的干净会话里问一句话，和在一个塞满了几十个文件的长会话里问同一句话，消耗完全不是一个量级。让 Claude Code 读了整个仓库之后再提问，每一轮都要把那一大坨上下文重新带进去。

所以”我这档一天能发多少条”这个问题，本身就问错了方向。真正能控制的是每条的成本，这一块的具体做法可以看 Claude Code 上下文管理：/compact 与 /context 怎么用——把上下文管住，等于把每个窗口的有效条数拉高。

2026 年的两次变化，别拿旧经验套

如果你手上的”经验值”是今年年初攒的，那它多半已经不准了，因为期间有两次公开的变化：

2026-05-06，Anthropic 宣布永久把 Claude Code 的 5 小时限额翻倍，覆盖 Pro、Max、Team 以及按席位计费的 Enterprise，同时取消了此前对 Pro 和 Max 的高峰时段限额缩减，Opus 的 API 限额也大幅上调。官方把这次调整归因于新增算力上线（公告中提到超过 300 兆瓦、约 22 万张 NVIDIA GPU）。

这条对老用户的意义是：过去那套”白天少用、避开高峰”的错峰策略，前提条件已经变了——高峰时段的额外缩减被取消了。如果你还在按半年前的直觉安排工作时间，可能是在白白让路。

2026 年 6 月，Anthropic 为全部 Pro 和 Max 用户做了一次性的限额重置（5 小时窗和周限额都重置了），原因是修复了一个问题：某些 Claude Code 会话会派生过多并行子代理，比预期更快地烧掉用量。

这条值得单独记一下。如果你重度使用并行子代理，那”用量烧得比想象快”这件事在历史上确实发生过，而且是被官方认定为缺陷并修复的。它提醒我们：用量的消耗速度不总是和你”感觉发了多少条”成正比，后台派生出去的动作同样在计费。关于子代理怎么用才不至于失控，可以参考 Claude Code 自定义 Subagent 怎么写。

最该知道的一条：实测与文档对不上

这是本文最想讲清楚的部分。

一份流传较广的 GitHub gist（作者 monperrus）在 2026-06-09 至 06-20 的约 11 天里持续监测了 utilization 字段，得出的结论是”周限额”实际上每 72 小时重置一次，而不是每 7 天。而且该 gist 的评论区里，不同账号、不同档位的用户报告的重置日差异很大。

必须把话说明白：这是第三方实测记录，不是官方事实陈述，它与官方帮助文档的表述存在不一致。我没有办法替任何一方下结论说谁对谁错——可能是不同账户批次的策略不同，可能是观测期内后台有过调整，也可能是 utilization 字段的含义和”周限额”并非严格一一对应。

但对你来说，真正有价值的不是”到底是 72 小时还是 7 天”这个答案，而是这个推论：

不要把任何假定的周期长度写进自动化脚本。

具体是指：别写”每周一凌晨自动跑批量任务，因为那时候额度肯定满了”这类逻辑；别在调度器里硬编码 168 小时的倒计时；别做一个”距离额度重置还剩 X 天”的看板然后依赖它做决策。这些东西在你的账号上可能今天准、下个月就不准了，而失败的方式往往很难受——任务跑到一半断掉，你还以为是网络问题。

正确的做法是读实际状态而不是算周期：动手前先看当下的剩余额度，按看到的数字决定这一轮做多大的事。

撞了限额怎么办：哪些路能走

• 先用 /status 查剩余额度。 这是官方给的查询方式，也是唯一可靠的信息源，比任何推算都准。
• 别找客服要求重置。 这条要说得直白些：客服无法实时手动重置或延长你的配额。很多人撞墙后的第一反应是去开工单，实际上这条路走不通，只是白白消耗时间和情绪。
• 开启 usage credits，在超出订阅包含的额度之后继续使用。
• 改走 Claude Console 账号的按量付费。如果你的用量本来就不稳定、时高时低，按量计费可能比追着订阅档位跑更合适，成本怎么算可以看 Claude API 怎么计费？按 token 算钱、各模型价格、省钱调用法。
• 升级档位。最直接但也最贵的一条，建议先确认自己撞限额是因为真的需要这么多用量，还是因为上下文管理太糟糕导致每条 prompt 都特别贵。

更完整的应对思路，之前那篇 Claude Code 撞到用量限制怎么办？计费与额度说明 讲得更细，这篇主要补的是”周”这一层的不确定性。

诚实说局限

这篇文章有几个地方我没法给你确定答案，也不打算硬给：

• 周限额到底多久重置一次，官方表述和第三方实测不一致，我只能把两边都摆出来，不替任何一方背书。
• 各档位的精确 prompt 条数，官方本身给的就是区间，且随上下文和模型浮动，任何写死的数字都会误导人。
• 限额政策变动很快——光是 2026 年上半年就有两次公开变化，这篇写下来的一切，都以你打开官方页面时看到的为准。

另外补一句准入前提：Anthropic 官方公布的受支持地区列表不含中国大陆（anthropic.com/supported-countries）。这意味着注册、控制台和服务端点都在境外。市面上确实存在第三方中转服务，但其合规性与稳定性风险由使用者自负，本文不提供也不背书任何具体渠道，也不暗示存在”官方直连”的方法。以各官网当前的地区政策页为准。

小结

Claude Code 的限额是 5 小时滚动窗加周限额的两层结构，5 小时那层从你发第一条 prompt 起算、不按整点。周这一层官方说法是按账户固定时刻每周重置，但有开发者实测记录到与文档不一致的重置周期，且各账号表现不一。因此别去背周期数字，动手前用 /status 读实际剩余，更别把假定的周期硬编码进任何自动化脚本。2026 年 5 月的永久翻倍和 6 月的一次性重置说明这套规则一直在变，旧经验需要定期作废重来。真撞上了，客服帮不了你实时重置，能走的是 usage credits、按量付费或升级档位——但在掏钱之前，先看看是不是上下文没管好。