多文件重构做到一半，Claude Code 停止输出，打印出类似 Claude usage limit reached. Your limit will reset at 4:00 PM. 的提示。3 个文件改了，2 个还没动，而 agent 完全不记得做到哪一步。明天回来又得从零开始。
解决办法不是”等”。Claude Code 同时管着三种独立的上限，每一种的恢复路径都不一样：
- 5 小时滚动窗口：从你发出第一条 prompt 起算，5 小时后重置。
- 周上限（滚动 7 天窗口）：叠在 5 小时窗口之上。Anthropic 于 2025 年 8 月 28 日加入。
- 单独的 Opus 周上限：Opus 4.7 可能先用光，而 Sonnet 4.6 和 Haiku 还有余量。
关键在于:这三种上限在同一账号下,会在 Claude Code、Claude.ai 网页版和 Claude Cowork 之间共享——你在浏览器里花的 token，会吃掉终端里的额度。要做的就是:先弄清是哪一种上限触发了,在浪费下一个 token 去重试之前先把状态落盘,再把以后的任务拆好,让撞上限不会一次毁掉整个 session。
一句话速览
- 先停。别急着重试——每次重试都在花你可能已经没有的额度。先写
STATUS.md并git commit。 - 跑
/usage（应用内命令）看哪条进度条满了:5 小时、周、还是 Opus 周。 - 如果只有 Opus 用光了,用
/model sonnet（或/model haiku）切过去继续干。 - 如果是 5 小时窗口满了,记下重置时间,过了再恢复。
- 如果是周上限满了,等几个小时没用——只有 7 天窗口重置才行。切模型或升级套餐。
- 在全新 session 里从
STATUS.md恢复,绝不靠 agent 的记忆。
你撞的是哪一种上限?
在 Claude Code 里跑 /usage。截至 2026 年 6 月,这是标准命令——它会在终端里为每个额度桶画一条 ASCII 进度条。(旧的 /cost 命令只显示当前花费,是给用 API key 的用户的,不适用于 Pro/Max 订阅。)对照下表判断。
错误信息 / /usage 里的症状 | 触发的上限 | 真正的解法 |
|---|---|---|
| ”resets at [今天某时刻]” 或小时级重置 | 5 小时滚动窗口 | 等重置,或切模型 tier |
| ”resets [日期]” 或天级重置 | 周上限(7 天窗口) | 切模型或升级套餐——等小时没用 |
Opus 报错但 /model sonnet 能用 | 单独的 Opus 周上限 | 把非关键活儿挪到 Sonnet/Haiku |
| ”Claude is at capacity, try again” 且无重置时间 | 服务端 429(不是你的额度) | 等 1-2 分钟再试 |
最常见的误判是把周上限当成 5 小时上限。如果 /usage 显示周进度条满了,等到你的 5 小时窗口翻篇也没用——周上限会卡住你,直到滚动的 7 天窗口清空。
常见原因(按命中率排序)
- 当前模型的 5 小时窗口耗尽。 窗口从你这一段的第一条 prompt 起算,不是固定钟点——上午 11 点发第一条,下午 4 点重置。截至 2026 年 6 月,Pro 每个窗口大约 10-45 条 prompt,Max 5x 大约 50-225,Max 20x 大约 200-900。(Anthropic 于 2026 年 5 月 6 日把这些 5 小时上限翻了倍,并取消了 Pro 和 Max 的高峰时段限流。)
- 周上限耗尽。 Pro 每周大约够 40-80 小时的 Sonnet 用量;Max 5x 大约 140-280 Sonnet 小时外加 15-35 Opus 小时;Max 20x 大约 240-480 Sonnet 小时外加 24-40 Opus 小时。Anthropic 还给周上限加了一次临时 50% 上调,持续到 2026 年 7 月 13 日。
- Opus 周上限先用光,而 Sonnet 还有余量。 这条最反直觉:Opus 4.7 有自己更小的周子上限,所以它会先停,而
/model sonnet照常工作。 - 长 session 比看上去更”重”。 一次 3-4 小时、
Read/Grep/Bash工具调用密集的 agentic 运行,烧 token 的速度远超你的消息条数所暗示的——每个工具结果都会重新喂回上下文。 - 多个并行 session 抢同一份额度。 两个 Claude Code 实例(终端 + IDE),或一个后台 agent,都从同一账号池里取。用 Task tool 启动的内部 sub-agent 也共享父 session 的额度。
- 把 429 误认成额度上限。 “Claude is at capacity, try again later” 是临时的服务端限流,不是你的额度。它没有数字级重置时间,一两分钟就会自行清除。
最短修复路径
Step 1 — 在做其他任何事之前先把状态落盘
每次重试都在花你可能已经没有的额度。先存状态。贴这段 prompt:
在做其他任何事之前,在仓库根目录写一个 STATUS.md,内容包括:
- 任务:<一句话>
- 已改文件(全路径)
- 还要改的文件(全路径)
- 已敲定的决定(如:用 REST 不用 GraphQL)
- 恢复时确切的下一步
然后执行:git add -A && git commit -m "wip: <task>"checkpoint commit 加上 STATUS.md 就是你的恢复点。如果 session 已经死了、agent 答不了话,就自己手写 STATUS.md 并从终端 commit。
Step 2 — 读 /usage,据此分流
用上面那张表。如果只有 Opus 进度条满了,你根本不用等——直接到 Step 3。如果 5 小时进度条满了,记下重置时间。如果周进度条满了,就围着 7 天窗口安排,或者考虑升级。
Step 3 — 只有某个模型被卡时,切模型 tier
/model sonnet
# 或者切到最便宜的一档:
/model haikuSonnet 4.6 能搞定绝大多数编码工作,且从更大的周额度池里取,所以只要是 Opus 上限被卡,切走 Opus 4.7 就能立刻解套。把 Opus 留给真正难的推理步骤、等它窗口恢复再用;低风险的活儿——移文件、简单编辑、读代码加总结、生成状态报告——交给 Haiku 4.5 或 Sonnet。
有一点要记住:全模型周上限是所有模型共用的,所以从 Opus 切到 Sonnet 只在单独的 Opus 那条进度条满了时才管用。如果 /usage 显示的是全模型周进度条满了,那么降到 Sonnet 或 Haiku 仍然从同一个桶里扣,等于白切。
想自动完成这种分工,可以跑 /model opusplan。它是内置别名:只在你处于 Plan 模式(用 Shift+Tab 切换,或 /plan)时用 Opus,一开始执行就切回 Sonnet 4.6。这样架构推理用 Opus、其余执行都用 Sonnet,是把 Opus 周上限撑得最久的最大杠杆。
Step 4 — 从 STATUS.md 恢复,不靠记忆
窗口恢复后,开一个全新 session,贴:
读 STATUS.md。它保存了上一个 session 的完整状态。
从 "next step" 那行开始恢复。不要重做已完成的工作。
对照 `git log` 确认哪些改动已经提交。读取书面快照的全新 session 没有记忆衰减风险,也不会重复应用磁盘上已有的改动。
Step 5 — 把以后的任务拆成约 30 分钟的 checkpoint
真正的 bug 往往不是撞上限,而是一个大任务没设 checkpoint。把活儿拆成每块约 30 分钟 agent 时间的单元:
- 单元 1:写 schema migration
- 单元 2:写 migration 测试
- 单元 3:更新 consumer 代码
- 单元 4:更新 consumer 测试每个单元之后:commit、往 STATUS.md 追加一行、然后暂停或继续。这样单元之间撞上限不会有任何损失。
Step 6 — 别在同一账号上跑并行 session
同一登录账号下的两个 Claude Code 实例会抢同一份额度池。要么一个实例顺序作业,要么用不同账号(比如分开的 Team 席位),各有各的额度。记住浏览器也算数——在另一个标签页里让 Claude.ai 或 Cowork 忙着,会消耗同样的额度桶。
怎么确认已经修好
下面三项都通过,你就真的恢复了:
/usage里挡住你的那条进度条不再是满的(5 小时窗口已翻篇、周进度条重新有了余量,或切模型后 Opus 进度条清空了)。- 一条真正的小 prompt——不是去重试那条失败的回合——能跑完,不再报
Claude usage limit reached。 git log --oneline -5里能看到你的wip:checkpoint,而且 agent 读完STATUS.md后的第一个动作是计划好的下一步,而不是重做某个已提交的文件。
如果 /usage 看着已经清空,但一发 prompt 仍然报带重置时间的 Claude usage limit reached,多半是还有第二条进度条接近满(常见的是刚重置的 5 小时窗口背后,周上限还卡着)——再跑一次 /usage,把每一条进度条都读一遍,别只看第一条。
预防建议
- 主动盯
/usage,在某条进度条填满之前、在干净的边界停下,别等满了才停。 - 按约 30 分钟切 checkpoint:每块之后 commit 加一行
STATUS.md更新。 - 反应前先分清三种上限——5 小时、周、Opus 周,三者恢复方式各不相同。
- 把 Opus 4.7 留给硬推理,常规活儿交给 Sonnet 4.6 或 Haiku 4.5,保护 Opus 的额度。最省事的自动办法就是
/model opusplan——规划时用 Opus,执行时用 Sonnet。 - 永远别在一个账号上开两个 Claude Code session,并关掉闲置的 Claude.ai / Cowork 标签页。
- 别拿假设的额度去钉死 deadline。Anthropic 的上限会变——2026 年 5 月的上调和持续到 2026 年 7 月 13 日的临时周上调都是例子。要看你当前的具体数字,查官方的 models, usage, and limits 文档 和 Pro/Max 套餐页面。
常见问题
等 5 小时能重置周上限吗?
不能。5 小时窗口和周上限互相独立。如果 /usage 显示周进度条满了,只有滚动的 7 天窗口能恢复访问——等几个小时没用。改成切模型或升级套餐。
为什么 Opus 停了,Sonnet 还能用?
Opus 4.7 有自己更小的周上限。你可能把它用光的同时,更大的周额度池还有余量,所以 /model sonnet(或 /model haiku)照常工作。把 Opus 留给真正需要它的步骤。
我在 Claude.ai 网页版的用量会算到 Claude Code 头上吗? 会。截至 2026 年 6 月,同一账号下的额度在 Claude Code、Claude.ai 网页版和 Claude Cowork 之间共享。一次长时间的浏览器 session 会耗掉你本想留给终端的额度。
“usage limit reached” 和 “Claude is at capacity” 有什么区别? 带重置时间的 “usage limit reached” 是你的个人额度——按上面那张表处理。“Claude is at capacity, try again” 没有重置时间,是临时的服务端 429,一两分钟就清除。别为了一个 429 去重排你的工作流。
每个 5 小时窗口我有多少条 prompt? 截至 2026 年 6 月,Pro 大约 10-45 条,Max 5x 大约 50-225 条,Max 20x 大约 200-900 条——Anthropic 于 2026 年 5 月 6 日把这些翻了倍。实际条数取决于每条 prompt 有多”重”:一次工具调用密集的 agentic turn,远比一行短问题占得多。
从 Opus 切到 Sonnet 能省周上限吗? 只在满的是单独的 Opus 那条进度条时才行。Max 套餐有两条周进度条:一条全模型上限,一条更紧的 Opus 上限。Opus 进度条满了时切到 Sonnet 或 Haiku 能解套,但它仍然从全模型上限里扣——所以如果满的是全模型那条,切什么模型都没用。
/model opusplan 是什么,我该用吗?
它是内置的模型别名:只在你处于 Plan 模式时跑 Opus,执行阶段自动切回 Sonnet 4.6。对于”先规划再动手”的重构和功能开发,它能让你拿到 Opus 级的规划质量,又不会把 Opus 周上限消耗在常规编辑上。要避免任务做一半撞上 Opus 上限,这是最省力的办法。
相关阅读
- Claude Code 卡在循环里
- Claude Code 中途丢了项目上下文
- Claude Code 部分执行后卡住
- Claude Code 新手入门
- Claude Code 工作流
- Claude Code 项目配置
标签: #排查 #Claude Code #排查 #使用上限