Claude Code 的 5 小时窗到底怎么算？重置时刻、条数区间与实测争议

2026-07-27

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

5 小时窗的计时起点是你发出的第一条 prompt，不是整点时钟。你 10:00 发第一条，这个窗就在 15:00 重置；中间发了 3 条还是 30 条，都不改变 15:00 这个时刻。搞清楚这一句，八成关于”我的额度怎么突然没了 / 怎么还没回来”的困惑就散了。

我见过太多人把它当成”每天 0 点、6 点、12 点、18 点各刷新一次”的整点制。这个误解看起来无伤大雅，实际代价不小：你会在错误的时间点等待，会在真正划算的时间点白白空转，还会把一段本可以连续推进的工作切成两半。所以这篇先把计时规则讲透，再讲能发多少条、撞了怎么办，最后诚实交代一个官方说法和第三方实测对不上的地方。

一、滚动窗：从第一条 prompt 开始计时

Claude Code 的用量限制是两层结构，底下这一层就是 5 小时滚动窗，它限制的是一个会话周期里能发多少条 prompt。

关键在”滚动”两个字。它不是挂在墙上的时钟，而是一根从你第一次开口那一刻开始跑的秒表：

你 09:20 发出当天第一条 prompt，这个窗的终点就是 14:20。
你在 09:20 到 14:20 之间无论怎么用，终点都还是 14:20，不会因为你用得多而提前、也不会因为你歇了两小时而顺延。
14:20 之后你再发第一条，新的窗从那一刻重新起算。

这个机制带来一个很实际的推论：窗的”起点”是你自己按下去的。如果你早上 07:30 顺手问了一句无关紧要的小问题，那么你真正打算干活的 10:00 到 12:30 这段时间，用的是同一个窗的余额，而这个窗 12:30 就到期了——你相当于用一条闲聊 prompt 把宝贵的窗口提前”点着”了。

所以有个特别朴素但有效的做法：把重活当成窗的第一件事。真正要连续推进的重构、大范围调试、长上下文的代码审查，尽量安排在窗刚开的时候起头，而不是在窗快到期的最后 40 分钟才动手，那样很容易做到一半被截断，重新开窗还得把上下文再喂一遍。

反过来说，也别为了”卡准窗口”把工作节奏搞得很扭曲。滚动窗的设计本意是让你连续工作，不是让你玩时间管理游戏。知道规则、避开明显的浪费就够了。

二、周限额：按账户的固定时刻重置

上面那层之上还有一层周限额。它和 5 小时窗的逻辑正好相反：周限额是按账户被分配的固定时刻每周重置的，重置日和重置时刻不随你什么时候开始用、也不随你什么时候订阅而改变，每个周期给满额度。

这个区别值得单独强调，因为两层限额的心智模型不一样：

5 小时窗 —— 你按下开始键，秒表才跑。
周限额 —— 日历上有个固定格子，到点就翻页，跟你干了什么无关。

实际用起来会出现这种情况：你的 5 小时窗明明是满的，却依然发不出去——那就是撞到了周限额这一层。这两层是叠加生效的，任何一层用尽都会挡住你。判断方法很简单，别靠猜，直接看下一节说的 /status。

三、每窗能发多少条：为什么官方只给区间

很多人希望拿到一个确切数字，比如”Pro 每窗 30 条”，好去做预算。这个数字不存在，而且它不存在是有道理的。

按第三方汇总的口径，Pro 每窗大约在 10 到 45 条 prompt 之间，Max 20x 最高可到约 900 条。这是第三方汇总口径而非官方逐字表述，具体以官方页面和你账户里实际显示的为准。

为什么是区间不是定值？因为一条 prompt 的”重量”差别极大，主要受三个因素影响：

prompt 本身的长度。一句”这行为什么报错”和一段贴了两百行日志的提问，消耗完全不是一个量级。
上下文大小。同一句问话，在刚开的干净会话里问、和在已经堆了大量文件内容的长会话里问，代价差很多——每一轮都要把已有上下文重新计入。
所选模型。不同模型的消耗速度不一样。

所以那个区间的下限和上限，本质上对应的是”每条都很重”和”每条都很轻”两种极端用法。你落在区间的哪个位置，取决于你怎么用。

由此能推出几条真正能省额度的做法，都不是玄学：

该开新会话就开新会话。一个话题聊完了还接着在同一个会话里问下一个不相干的问题，等于让新问题背着旧上下文的包袱，每一轮都在为无关内容付费。
别把整个文件夹一股脑塞进去。精确指向要看的文件，比让它自己漫无目的地读一圈便宜得多。
让它一次说清楚，而不是来回挤牙膏。把约束条件、期望输出格式、边界情况一次性写在提问里，通常比连着追问五轮更省。五轮追问是五条 prompt，而且第五轮背着前四轮的全部上下文。
简单任务不必都用最重的模型。格式转换、写点小脚本这类活，没必要动用最贵的档位。

关于上下文怎么控制，站内另有专门一篇可以配合看：Claude Code 上下文管理。

四、2026 年发生过的两次变化

如果你看到的教程是今年上半年之前写的，里面关于限额的描述可能已经不准了，因为 2026 年有两次官方层面的变动。

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

对使用者的实际影响有两条。一是同样的档位，现在每个 5 小时窗能干的事比过去多一倍。二是”高峰时段限额缩减”这件事已经取消了——所以那些教你”避开欧美白天、专挑凌晨用”的老攻略，前提条件已经不成立了。当然，你如果本来就习惯早上写代码，那继续保持就好，不用刻意改。

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

这件事本身是一次性的，不用惦记还会不会再来。但它顺带说明了一个值得留意的机制：并行子代理是会实打实吃额度的。你让它同时跑五个子任务，代价就是五份消耗。这不是 bug，bug 是当时派生的数量超出了预期。日常使用时，如果发现额度掉得异常快，回头看看是不是无意间触发了大量并行动作。子代理的写法与适用场景，站内有专门一篇：Claude Code 自定义 Subagent 怎么写。

五、诚实说一个对不上的地方

这一节是我认为对你最有价值的部分，因为它讲的是”不要相信任何一个你没验证过的周期数字”。

官方帮助文档的说法是周限额按账户固定时刻每周重置。但有一份流传较广的 GitHub gist（作者 monperrus）在 2026 年 6 月 9 日到 6 月 20 日大约 11 天里持续监测 utilization 字段，得出的结论是”周限额”实际每 72 小时重置一次，而不是每 7 天。该 gist 的评论区还显示，不同账号、不同档位观察到的重置日差异很大。

要怎么理解这个矛盾？我的建议是：

这是第三方实测与官方文档表述不一致的地方，不能把它当成官方事实来引用，也不能反过来断言官方文档写错了。监测手段、账号类型、观测窗口都可能带来偏差。
但它足以支撑一条非常实用的结论：不要把任何假定的周期长度硬写进自动化脚本里。如果你打算写个脚本按”每 7 天”或”每 72 小时”去调度批量任务、去预估什么时候能恢复，那么无论你选哪个数字，都有相当概率是错的，而且各账号表现还不一致。
正确做法是读实际状态，而不是算日历。要判断还剩多少，就去查当前状态；要判断恢复没恢复，就去看当前状态。别做算术推演。

这也是这类”限额规则”话题的通病：它变得比文档更新得快，比教程更新得快，也比任何人的记忆更新得快。任何具体数字都请以你打开官方页面当时看到的、以及你账户里实际显示的为准。

六、撞到限额了怎么办

先说一条能省你很多时间的事实：客服无法实时手动为你重置或延长配额。很多人撞墙后的第一反应是去找客服要个临时额度，这条路走不通，别把时间花在这上面。

按官方指引，可行的动作是这些：

先用 /status 查剩余额度。这是唯一靠谱的判断依据，比你自己算时间准。撞墙时第一步就该是它，先弄清楚是撞了 5 小时窗还是撞了周限额，两者的等待策略完全不同。
开启 usage credits，在超出包含额度之后继续使用。
改走 Claude Console 账号的按量付费。订阅制和按量付费是两套计费逻辑，重度使用者把两条路都备着，比死等窗口恢复更实际。这条路的计费机制可以看：Claude API 怎么收费。
升级档位。如果你是每天都撞、而不是偶尔撞，那说明档位和你的工作量确实不匹配，靠技巧省是省不回来的。

顺带说一句判断标准：偶尔撞限额其实是正常的，说明你把订阅用满了；天天撞、而且是在上午就撞，那才是需要调整的信号——要么是用法太浪费（长会话不切、上下文塞太满），要么就是该换档位了。

七、大陆访问的前提，必须先说清

限额规则讲得再细，也得建立在你能正常访问的前提上。这里如实说明：Anthropic 官方的受支持国家/地区列表不含中国大陆（anthropic.com/supported-countries），注册、控制台与 API 端点都在境外。

需要守住的边界也一并写明：本文不提供也不背书任何第三方中转渠道；客观上确实存在这类服务，但其合规性与稳定性风险由使用者自行承担。也不要相信任何”用某种方法就能官方直连”的说法。准入政策会调整，以官网当前的地区政策页为准。

八、诚实说局限

本文所有条数区间都是第三方汇总口径，官方本身给的就是区间而非定值，且随上下文浮动。任何人给你一个精确到个位数的”每窗多少条”，你都可以直接怀疑。
5 小时窗与周限额的叠加关系、以及具体档位对应的额度，最终以你账户内 /status 显示的为准，不以任何教程为准。
第五节那个 72 小时的实测结论，我如实转述但不背书。它的价值在于提醒你别写死周期，而不是给你一个新的数字去写死。
本文不涉及任何价格数字，档位定价请查官方页面。

小结

5 小时窗从你发出第一条 prompt 起算，不是整点时钟，所以把重活安排在窗刚开的时候起头是有意义的。周限额是另一层，按账户固定时刻重置，两层叠加、任一层用尽都会挡住你。每窗能发多少条只有区间没有定值，因为消耗取决于 prompt 长度、上下文大小和所选模型——这三点也正是你唯一能真正发力去省额度的地方。2026 年 5 月的官方调整永久翻倍了 5 小时限额并取消了高峰时段缩减，老攻略里的错峰技巧可以退休了。最后，有第三方实测记录到与文档不一致的重置周期且各账号表现不一，所以别把任何假定的周期写进自动化脚本，撞墙时先跑 /status 看实际状态，而不是掰着手指头算日子。