有余量还报 429？误报的排查顺序

/usage 明明显示还有一大截余量，请求却被 429 拒了回来——这种「有余量还报限流」的错位，AI 编程用户社区里有一串登记在案的实例。429 本义是服务端限流：请求频率或用量触到了限制线。但限流提示不总说真话：服务端状态错位、窗口判定 bug、第三方后端的限额，都可能让 429 出现在不该出现的时候。这篇给一条以 /usage 为起点的排查顺序：先分真限流还是误报，再按结论选等、刷还是查对方；真超额的处理见usage limit 报错一篇，两篇合看覆盖限流侧的全部分支。

429 的两种来历：真限流与误报

先把 429 的机制说清。它是通用的限流状态码：服务端发现请求超过配额或频率上限，返回它让客户端稍后再来，通用机制见429 限流一篇。Codex 场景下它有两种来历：一是真限流，窗口内用量或请求频率确实到线；二是误报，余量充足仍被拒——社区 issue 里登记过多个案例（#12776、#9135、#27970），特征是报错与 /usage 的显示自相矛盾。误报的常见来源是后端状态错位：额度数据在多台服务节点之间没有对齐，某台节点拿着旧数据把你当成超额用户拦下。这种错位多数几分钟内自愈，这正是排查顺序里「等」排在「修」前面的原因——先给系统一点对齐的时间，再谈动手。

排查顺序：先 /usage 再定夺

每一步都有明确的出口：

• 第一步，跑 /usage 核对余量与重置时间：余量见底是真超额，按 usage limit 报错一篇的五步走；余量充足，进入误报分支。
• 第二步，误报分支先等几分钟再试：状态错位常自愈，多数案例在这一步就解决了。
• 第三步，仍报错，codex logout && login 刷新本地会话状态再试；连续几个时段都出现，换个时段验证。
• 第四步，走第三方后端或中转的，429 可能来自对方：对方自有额度与频率限制，查对方的限额文档与用量面板，与 OpenAI 侧余量无关。
• 第五步，CI 或自动化脚本集中请求触发的 429 属于频率限流：请求间隔太密，拉开间隔加退避再跑，非交互场景的限额纪律见CI 非交互一篇。

第三方后端：限额在对方

排查里最容易绕错的是第三方后端这一支。接聚合平台或中转服务跑 Codex 的，429 的判定方已经换了人：限的是对方的池子、对方的频率线，你在官方侧的余量再充足也不影响它的判断。识别方法很简单：同一凭据直连官方不报错、走第三方就报错，板子就在对方。处理上没有本地手段，方向有两个：按对方文档调整并发与频率，或者换回官方直连对照验证。这一支还常与包装报错纠缠：429 被重试层包成 exceeded retry limit 之类的句子，先剥包装再看原始状态码，剥法见retry limit 分流一篇。第三方这一支的排查心法就一句：先弄清限流的决定是谁做的，再决定找谁。

等与重试的纪律

误报场景下最贵的动作是连环重试。429 之下高频手点，不但无助于状态对齐，若限流判定里含频率因素，狂点反而坐实「超频」，把几分钟的自愈拖成更长的冷却。正确姿势是退避：失败后等几十秒，仍失败翻倍再等；等待期间把 /usage 截图留存、报错时间点记下来——反复出现的误报，这些记录就是提交 issue 时的全部证据。窗口机制的底子也补一句：滚动窗口从首次消耗起算，余量随时间回补，节奏见额度窗口一篇，知道余量什么时候回来，「等多久」就有了依据。想让这套分支判断顺手，可以让 DeepSeek 把「真超额、误报、第三方限流、频率限流」四条支线画成分流图，再用豆包逐条模拟报错场景，对着图走一遍排查顺序。

429 误报速查

• 429 分真限流与误报，第一步永远是 /usage 核对
• 误报多因后端状态错位，等几分钟常自愈
• 重登录可刷新会话状态，反复出现换时段验证
• 第三方后端的 429 限在对方，直连对照即可识别
• 误报之下别连环重试，退避等待并留存证据

关于 429 误报的常见疑问

• 误报和真超额报错有什么区别？：看矛盾点。误报的特征是报错与 /usage 余量自相矛盾；真超额两边一致——余量见底、报错照来。矛盾即误报，一致即超额，判断只需一次核对。
• 等多久重试合适？：第一档等几十秒，第二档等几分钟；同一时段三次退避后仍报错，先走重登录与换时段，别继续加次数，也别缩短间隔硬试。
• 换了第三方后端后 429 变多正常吗？：常见。对方的池子小、频率线低，报错自然多；把并发与请求间隔对齐到对方的限额参数，或直连官方对照验证，是两条正路。