用 /status 管住 Claude Code 的用量：两层限额怎么看、怎么省
数据截至 2026-07，价格与限额以各官网为准。
/status 不是一个装饰性的信息面板，它是你唯一能实时看到自己还剩多少额度的入口——把它养成每次开工前敲一遍的习惯，绝大部分”莫名其妙被卡住”的情况根本不会发生。 Claude Code 的用量由两层限额叠加构成，两层的重置逻辑完全不同，只盯着其中一层，另一层撞上来时你会毫无预警。
先说一个流传很广的误解：很多人以为 5 小时窗口是按整点走的，比如以为”到下午 3 点就统一重置”。不是这样。官方帮助中心的口径很明确，5 小时窗从你发出第一条 prompt 的那一刻开始计时。你 10:00 发了第一条，15:00 就重置，中间是发了 3 条还是 30 条，都不改变这个重置时刻。理解这一点，后面所有的节奏安排才有意义。
一、两层限额分别管什么
第一层是 5 小时滚动窗，限制的是一个会话周期内你能发出多少 prompt。它的计时锚点是”你这一轮的第一条消息”，滚动前进，不跟自然时钟对齐。
第二层是周限额。按官方帮助中心的说法，周限额是在你账户被分配的固定时刻重置的——这个重置日和时刻不随你何时开始使用、也不随你何时订阅而改变，每个周期给满额度。也就是说，它跟 5 小时窗那种”你一发消息就开始跑表”的机制完全是两套逻辑。
两层是叠加生效的：5 小时窗没满，不代表你能一直用下去；周额度见底了，哪怕当前窗口一条都没发，照样会被拦。所以看 /status 的时候不要只扫一眼数字大不大，两层都要看。
二、能用多少条，为什么官方不给准数
关于容量，第三方汇总的口径是：Pro 每个 5 小时窗大约 10 到 45 条 prompt，Max 20x 档最高约 900 条。这是第三方汇总口径而非官方逐字说法，具体以官方页面和你账户里 /status 实际显示的为准。
为什么区间跨度这么大？因为一条 prompt 的成本根本不是固定的。它取决于你这条消息的长度、当前会话累积的上下文大小、以及你选的模型。同样”发一条”，在一个空白会话里问句话，和在一个已经塞了几十个文件、跑了半小时的长会话里追问一句，消耗完全不是一个量级——后者每一轮都要把整段上下文重新算进去。
这直接推出一条最有效的省额度做法：控制会话长度。一个任务做完就开新会话，别让上下文无限膨胀到下一个不相干的任务里。这方面的具体做法可以看 Claude Code 上下文怎么管。
三、2026 年官方做过的两次调整
这两件事值得记住，因为网上很多教程还停留在调整之前的状态。
2026-05-06，Anthropic 宣布永久把 Claude Code 的 5 小时限额翻倍，覆盖 Pro、Max、Team 以及按席位计费的 Enterprise；同时取消了此前针对 Pro 和 Max 的高峰时段限额缩减。Opus 的 API 限额也在这次一并大幅上调。官方把这次放宽归因于新增算力上线，公告里提到的规模是超过 300 兆瓦、约 22 万张 NVIDIA GPU。
对你的实际影响有两个：一是如果你看到的教程还在教”避开高峰时段用”，那条建议已经过期了，高峰缩减这个机制官方已经取消；二是如果你的额度感知还停留在翻倍之前，可以重新评估一下自己的工作节奏，不必再像以前那样抠着用。
2026-06 还有一次一次性重置。 Anthropic 为全部 Pro 和 Max 用户重置了 5 小时和周限额，原因是修复了一个问题：某些 Claude Code 会话会派生过多并行子代理，比预期更快烧掉用量。
这件事本身已经过去了，但它留下的提醒仍然有效——并行子代理是额度消耗的放大器。你在主会话里发一条指令，如果它扇出成多个子代理各自跑，实际消耗会远超你的直觉。用到这类能力时，/status 更值得多敲几次。子代理的机制可以参考 Claude Code 子代理怎么用。
四、一个必须诚实说出来的矛盾
这一节可能是全文对你最有价值的部分。
有一份流传较广的 GitHub gist（作者 monperrus），在 2026-06-09 到 06-20 大约 11 天里持续监测了返回中的 utilization 字段，得出的结论是”周限额”实际上每 72 小时重置一次，而不是每 7 天。该 gist 的评论区还显示，不同账号、不同档位观察到的重置日差异很大。
必须把话说清楚：这是第三方实测与官方文档表述不一致的地方，不能当成官方事实陈述来引用。 官方文档说的是按固定时刻每周重置，实测记录到的是另一回事，两者谁更准确、是不是不同账号走不同策略，公开信息不足以下结论。
但这个矛盾给出的操作建议是明确的：不要把任何假定的周期长度硬编码进你的自动化脚本。 如果你写了个脚本，假设”每周一早上额度会满”然后自动排一堆批量任务，很可能在某个账号上完全对不上，跑到一半全部失败。要判断额度状态，就老老实实读 /status 的实时输出，别靠算日子推。
五、撞到上限之后，哪些路是通的
先说一条最容易浪费时间的：客服无法实时手动重置或延长你的配额。 很多人第一反应是去开工单请求”临时放开一下”，这条路走不通，官方指引里说得很清楚。把这个时间省下来，直接看下面几条。
第一，先敲 /status 确认到底是哪一层满了。 是 5 小时窗满了，还是周额度见底了，两者应对方式完全不同。前者最多等到窗口重置，你可以直接算出还剩多久；后者要等到账户的固定重置时刻，中间这段时间靠等是没意义的。
第二，开启 usage credits。 这是官方给出的路径之一：在超出包含额度之后继续用。适合那种”周额度还有几天才恢复，但手头这个任务不能停”的情况。
第三，改走 Claude Console 账号的按量付费。 订阅额度和 API 按量是两套计费模型，后者不受订阅侧这两层窗口的约束。如果你的用量长期稳定地超出订阅包含的范围，切到按量可能反而更好算账。两种模式的取舍可以看 Claude Code 撞到用量限制怎么办。
第四，升级档位。 最直接但也最贵，值不值得取决于你撞限额的频率。如果一个月就撞两三次，等一等比升级划算；如果每天下午都撞，那说明档位确实不匹配。
本文不写各档的具体价格，因为价格调整比文章更新快，以官方计费页当前显示的为准。
六、把 /status 变成习惯的几个具体做法
光知道有这个命令没用，得让它真的进入你的工作流。几条可以直接照做的：
- 每次开新会话前敲一次。 花不到两秒，但能让你在动手前就知道今天的预算够不够开一个大任务。
- 准备跑长任务或并行子代理之前，再敲一次。 这类操作的消耗最不可预测，事前有个基线，事后你才能大致知道它吃掉了多少。
- 撞到限额时，先看再动。 别急着重试，重试本身也在消耗。看清是哪一层满的，再决定是等还是换路径。
- 别把额度状态写进自动化判断。 前面那个 72 小时的矛盾就是理由。脚本可以读
/status的实时输出做判断，但不能靠推算日期。 - 把大任务拆到不同会话里。 上下文越长每一轮越贵，一个会话干到底看似省事，实际是最烧额度的用法。
关于更普遍的成本控制思路，Token 成本怎么优化 里讲的原则同样适用于订阅制场景——本质上都是在减少每一轮要重新计算的上下文。
七、诚实说局限
这篇能确定的东西是有边界的，几个地方必须说明白：
具体条数不要当准数用。 前面给的 Pro 和 Max 的区间是第三方汇总，不是官方逐字承诺，而且官方自己给的也是区间不是定值。你账户里 /status 显示的才算数。
周限额的真实周期存在争议。 官方文档和第三方实测对不上，本文如实呈现两边说法，但不替任何一方下结论。
准入前提要提前想清楚。 Anthropic 官方受支持地区列表不含中国大陆（anthropic.com/supported-countries），注册、控制台与 API 端点都在境外。这是准入层面的现实，不是网络快慢的问题。本文不提供也不背书任何第三方中转渠道，相关合规与稳定性风险由使用者自负；地区政策会变，以官网当前政策页为准。
限额规则本身会调整。 光 2026 年上半年就有翻倍和一次性重置两次变动。本文写的是截至 2026-07 的状态，隔一段时间该去官方页面复核一次。
小结
Claude Code 的用量是两层结构：5 小时滚动窗从你第一条 prompt 开始计时，周限额按账户固定时刻重置，两层叠加生效。/status 是唯一能看到实时剩余的入口，值得养成开工前先敲一次的习惯。2026-05-06 官方永久把 5 小时限额翻倍并取消了高峰时段缩减，很多老教程的建议已经过期。第三方实测记录到的周期与官方文档不一致，所以别把任何假定的周期长度写进自动化脚本。真撞到上限，客服无法手动重置，可走的路是 usage credits、Console 按量付费或升级档位——但更省事的做法，是把会话切短、让上下文别无限膨胀。