You've hit your usage limit了？

任务跑到一半，Codex 弹出「You've hit your usage limit」，进度停在半截——这是 AI 编程里最常见的打断之一。这句话的字面意思是额度用完了，但实际未必：有的是窗口真滚动到了顶，有的是已知 bug 造成的提前触发，处理方式完全不同。这篇按排障文的惯例给一条能照着走的排查顺序：先核对用量、再判真伪、然后按结论选对策，最后给两条长线的省额度思路；窗口怎么滚动的，见额度窗口一篇的机制拆解。

报错在说什么：额度池见底或被误判

先理解报错背后的机制。订阅额度按滚动窗口补给，CLI、IDE、云端任务共享同一个额度池——你在别处跑的任务可能已经把池子抽低了，本机看着没事，报错照样来。真超额的情形，是窗口内的消耗确实到顶；误报的情形，是余量还在、报错先到，属于服务端状态没对齐的已知问题。两种情形的处理完全不同：前者是等或升，后者是刷新或等自愈。所以第一步先别改任何配置，先用数据判断属于哪种——这一步做错，后面全是在错误的假设上折腾。

排查顺序：五步定方向

按顺序走，每一步都有明确的出口：

• 第一步，跑 /usage 核对当前用量与窗口重置时间：余量确实见底，进入第二步；余量充足却报错，直接跳第三步。
• 第二步，确认真超额后看重置时间，等窗口滚动自动恢复；赶工期的，升级订阅档位，或按省额度打法压缩消耗，杠杆清单见省额度杠杆一篇。
• 第三步，余量充足仍报错，先等几分钟再试一次——后端状态对齐后常自愈。
• 第四步，仍不行，codex logout && login 重新登录刷新本地会话状态，再试一次。
• 第五步，以上全部无效，查官方状态页与社区 issue：提前触发误报有已登记的 bug（#12299、#11508，截至发稿版本，以官方更新日志与 issue 状态为准），等修复或按 issue 里的临时做法处理。

提前触发误报：两处已知的坑

误报不是玄学，社区里有实锤登记。一处是滚动窗口的判定 bug：窗口明明未到，报错提前出现，对应 issue #12299 与 #11508，特征是 /usage 显示的余量与报错自相矛盾——这正是第三步「先等再试」能通过的原因：部分误报由后端状态错位引起，几分钟后对齐自愈。另一处特征是重登有效：logout 之后 login，本地会话的用量缓存被清掉重建，报错消失。两条路的共同点是都不动你的配置——遇到这种报错，改代理、改模型参数都是在错误方向上使劲，先走完五步再说。与它相邻的另一类限流信号是 429，分流方法见429 误报一篇，限流的通用机制见429 限流一篇。

长线对策：让报错少来

报错处理完，还有两件长线的事。一是消耗结构：agentic 任务贵在上下文与并行，换小模型、压缩上下文、关多余工具，同一份工作的账面差距很大，具体见省额度杠杆一篇。二是档位匹配：如果 /usage 显示你长期稳定打满窗口，说明档位与用量不匹配，升级是正路——Free 与 Go 档不能单独购买 credit，用量超出档位供给时只能升档或省着用，两条计费轨道的分工见计费轨道一篇。让报错少来的顺序是先省后升：先把消耗习惯调好，调不动再升档。想把这套排查变成肌肉记忆，可以让 DeepSeek 把五步清单整理成一张故障卡存进笔记，再用豆包模拟「余量充足仍报错」的场景，对照卡片口头走一遍流程。

usage limit 速查

• 报错分两种：真超额与误报，先 /usage 核对再动手
• 五步：核对用量、等重置、等自愈、重登录、查状态页与 issue
• CLI、IDE、云端共享额度池，报错可能来自别处的消耗
• 提前触发有已知 bug（#12299/#11508），等几分钟或重登常能过
• 长期打满窗口就升档，Free/Go 档不能单独购 credit

关于 usage limit 报错的常见疑问

• 等重置要等多久？：滚动窗口从会话内首次消耗起算，窗口长度与重置时间以 /usage 页面显示为准，不用背数字，报错现场查一次就有。
• 升级档位后报错立刻消失吗？：正常即时生效；若升级后仍报错，转误报分支处理——等几分钟、重登录，或查已知 bug 的 issue 状态，两条路都在五步之内。
• 误报反复出现怎么办？：记录出现时间与 /usage 截图，到官方仓库检索或提交 issue；同一个问题多人登记，修复优先级才会靠前，等待期按五步里的等与重登先顶住。