Claude Code 限额：5 小时窗口、周上限、429，和撞墙之后的每一条路

限额是两块同时走的钟表

订阅制的 Claude Code 限额不是一个数字，是两个：5 小时滚动窗口，和每周上限。窗口从你开始用的时候起算，5 小时后归零重计；周上限则横跨整周，把窗口里省不下的部分一路累计。你在周二下午用掉的不只占周二的窗口，也占这一周的池子。

所以「我刚重置了怎么又满了」大多数时候不是 bug：5 小时窗口满了是一种感觉，周上限见底是另一种——后者意味着哪怕窗口刚清空，你也得等这周翻篇。/usage 能看清自己此刻在哪一种里。

• 5 小时窗口：滚动重置，决定「现在还能不能继续」；
• 周上限：累计消耗，决定「这周还剩多少总量」；
• 两者独立计量，先到的那块先挡住你。

为什么 Opus 总是先把周上限烧穿

周上限按「用量」计，而旗舰模型每一轮吃掉的用量是轻量模型的好几倍——更长的上下文、更长的输出。同样 8 小时重度会话，跑 Opus 消耗周池的速度可能数倍于 Sonnet。于是出现那个著名的不对称：一周里用了几天 Opus，周上限提前见底，哪怕 Sonnet 的专属配额还躺着——池子是共通的，专属额度救不了总池。

这不是惩罚重度用户，是定价结构使然：订阅本质上是「用量封顶的包月保险」，保险对每一笔的定价不分贵贱，但池子有底。理解了这一点，「换个模型继续跑」和「换种计费方式」就不再是玄学，而是同一道算术的两个变量。

撞上去的那一刻，机器里发生了什么

超限的表面症状是 429。它不是错误，是协议在如实告诉你「额度用完了，什么时候恢复写在响应头里」。多数客户端会把重置时间转述出来——所以撞墙时第一件事不是换工具，是把重置时间读出来，决定这一小时怎么过。

值得一提的是：撞墙只用订阅限额会发生。按量计费的 API 路径没有 5 小时窗口和周池，它的限制是另一套（每分钟吞吐、分层月支出上限），对「一个人写代码」的量级来说几乎撞不到。这不是说按量更好——它只是把「墙」换成了「表」——但这是后面所有出路的分岔点。

五条出路，按便宜和诚实的程度排

撞墙之后的选项其实墙上一直写着，只是分散在不同文档里。我把它们收拢，按「先试便宜的」排序：

1. 等待重置。5 小时窗口很快翻篇，成本为零。适合「就差一口气」的场景：把当前任务挂起，窗口重置后收尾。
2. 压上下文。/compact 或直接开新会话。长会话每一轮都在重发全部历史，压掉冗余等于每一轮都少消耗。它不恢复额度，但让剩余额度走得更远。
3. 降一档模型。模板化修改和检索用不着旗舰；把 Opus 留给真正的架构难题，周池的消耗速度立刻下来一截。这是最被低估的一条：多数人的默认模型，配不上他们的多数任务。
4. 升级套餐。如果你的形状是「每天数小时、集中在旗舰模型」，更高档位的池子确实更便宜——这是套餐设计的初衷，该用就用。
5. 切按量计费。墙消失，表开始走。适合用量多样、偶发、或分散在多个工具上的人；也适合「撞墙频率高于每月一次」的人——被墙挡掉的时间也是成本。

哪种形状的人，该停在哪条路上

前四条出路不需要这篇文章，撞过一次墙的人都会自己学会。真正值得停下来做算术的，是第 4 和第 5 条之间：升级套餐，还是切换按量。

这道题的原料是你自己的使用形状：每天专注几小时、任务强度什么档、缓存命中如何。把它们代进成本计算器，会算出「按量消费追平套餐价」的回本点小时数——低于那个数，按量更省；高于它，套餐更划算，墙就是你要付的保险费。没有万能答案，只有你自己的算术。

还有一个不对称值得知道：套餐的价格是锁定的，按量的单价跟着费率表走。选按量的人应该要求服务商给出机器可读的价目表和逐笔账单——不然「表在走」就变成「表在黑箱里走」。