Codex 报 429 / usage_limit_reached 怎么解？（额度窗口与重试坑）

用 Codex CLI 写代码写到一半，终端突然弹出 429 Too Many Requests、usage_limit_reached，或者 "You've hit your usage limit"，整个会话卡死、自动重试也救不回来——这是订阅型 Codex 最高频的中断。这篇把这个报错拆开讲清楚：它到底是"额度真的到顶"还是"后端误判"，为什么死等重试基本没用，以及面对它你有哪几条出路。看完你能自己判断该等、该查、还是该升档。

先分清：这个 429 是哪一种

Codex 终端里看到的 429 / usage limit，来源其实不止一种，处理方式完全不同。先对号入座，再动手。

你看到的现象	大概率是哪种	核心特征
报 usage_limit_reached，或 "You've hit your usage limit"，并附一个重置时间	订阅额度窗口到顶	等窗口重置前，无论怎么重试都不会恢复
报 429 Too Many Requests，提示 "try again after N seconds"，retry 4/5 …	短时速率限制（瞬时太密）	稍等几十秒到几分钟通常自愈
接了自己的 API key / 第三方端点后报 429	模型供应方的 API 限额	和 ChatGPT 订阅额度无关，是那条 key/端点的事
/status 显示还有大量余量却照样 429，约十几分钟后自己好	窗口边界附近的后端误判	属已知偶发，等窗口翻篇即恢复

这四种里，真正的"额度到顶"（第一种）才是本文重点，也是大多数人遇到的情况。后面几节都围绕它展开；末尾的排查表会帮你把四种区分开。

Codex 的额度是"双重墙"：5 小时窗口 + 每周限额

很多人以为 Codex 只有一个额度条，其实据 OpenAI 官方帮助中心关于"用 ChatGPT 套餐使用 Codex"的说明，每个套餐都带两道用量上限，任意一道撞墙都会触发 usage limit：

滚动 5 小时窗口：这是个"滚动"窗口，不是整点清零。CLI 本地消息和云端任务共用这一池子。你 5 小时内的请求累计到上限就触顶，要等最早那批用量滑出窗口、额度才一点点回来。
每周限额：为持续高强度使用设的总闸。哪怕你每个 5 小时窗口都没打满，一周累计够多也会先撞到周限额。

所以"我刚等了 5 小时怎么还是不行"通常是撞了周限额这道墙——它不会因为 5 小时窗口重置而恢复，得等周期重置。这也是为什么"等一会儿再试"有时管用、有时完全没用：要看你撞的是哪道墙。

怎么知道自己离哪道墙更近

在 Codex CLI 会话里输入 /status，它会分别列出两道限额的剩余百分比和各自的重置时间，类似"5h limit 还剩 82%，重置于 15:18"和"Weekly limit 还剩 36%，重置于某日 03:08"。

关键一点：以 /status 或限额提示横幅里给的那个重置时间为准，别去套一个"通用的整点时刻"。滚动窗口对每个人都不一样，没有统一的公共时钟。想动手前先看一眼 /status，比盲目重试省事得多。

为什么"一直重试"基本是白费力气

Codex CLI 撞到 429 时会自动重试若干次（终端里那串 "retrying 4/5 in 1.471s"），重试光了就抛 "exceeded retry limit, last status: 429 Too Many Requests"。问题在于：

如果是真额度到顶，额度只会随时间窗口推进而恢复，请求发得再勤也不会让额度提前回来，反而可能把瞬时速率限制也一起惹出来。
据 openai/codex 社区里多个反馈，还存在一种窗口边界附近的误判：有人在 5 小时窗口快结束时收到 429，提示"slow down，60 多秒后再试"，但用量面板明明显示还剩六成余量；这种情况死等重试也没用，约十几分钟后窗口一翻篇就自己好了，本质是后端在边界上的计数偏差，不是你真用超了。
社区还记录过相反方向的怪事：周限额已经 0% 了 Codex 却还在跑、或者面板显示有余量却照样弹 limit 横幅。说明这套额度统计本身偶有滞后/错位，遇到和直觉不符的状态先用 /status 核一遍，别急着判断是自己的问题。

结论很直接：看到 usage_limit_reached，先停手别狂点。用 /status 确认是哪道墙、重置时间是几点，再决定下一步。

真到顶了，你有这几条路

确认是额度真到顶（不是误判、不是瞬时速率）后，按你的紧急程度选：

1. 等窗口重置（零成本，但要等）

撞 5 小时窗口的话，按 /status 给的重置时间等就行，滚动窗口会逐步放额度回来。撞周限额则要等周期重置，时间通常长得多。适合"不急、能等"的场景。

2. 用积分 / Credits 续上（按官方机制）

据 OpenAI 帮助中心关于"在 ChatGPT 中用 Credits 做弹性用量"的说明，部分套餐支持在用满包含额度后，用 Credits 继续跑，用量按所用模型和功能从可用 Credits 里扣。是否可用、怎么计费以你账户面板里官方实时显示为准，本文不写死数字。

3. 切到 API key 按量计费（换一种经济模型）

Codex CLI 支持把计费源从订阅切到 API：设置 OPENAI_API_KEY 环境变量后，它会改用 API 按 token 计费，没有那个滚动窗口的封顶——代价是用多少付多少。适合团队天天打满 5 小时窗口、用订阅档已经不划算的重度场景。注意这条是另一套账单逻辑，先想清楚成本再切。

4. 升档（最直接解决"档位天花板太低"）

如果你是反复撞墙，而不是偶尔一次，那大概率不是 bug，是你的套餐档位对 Codex 这种重度编程负载本来就给得不够。Codex 用的是和 ChatGPT 同一套账号会员，档位越高、Codex 的用量配额越大：

Plus（官方 $20/月）：官方定位是"日常稳定使用"最合适。适合一天里零散写写、不长时间高强度连轴转的人。
Pro（官方 $100/月）：官方明确说是"为更长、更高强度的 Codex 会话而建"。同一套账号下，Pro 的 Codex 用量配额显著高于 Plus（官方曾给过临时加量，具体倍数以官方实时为准，别当永久承诺）。

判断标准很简单：偶尔撞一次 → 等重置就好，没必要折腾；几乎天天撞、严重打断节奏 → 该考虑升档或换计费模型了。不要为一次性的额度到顶贸然升档，也别天天被 429 卡死还硬扛在低档上。关于按预算把 Codex 和 Claude Code 的档位放一起怎么选，文末有专门一篇。

一张排查表对症下药

症状	先做	怎么解
报 usage_limit_reached / "hit your usage limit"，带重置时间	/status 看是 5h 墙还是周墙	等对应重置；急 → Credits / API key / 升档
刚等了 5 小时还是不行	/status 看周限额剩多少	多半撞了周墙，等周期重置或升档/换计费
429 提示 "try again after N seconds"	停手，等几十秒到几分钟	瞬时速率限制，通常自愈，别狂重试
/status 还有大量余量却 429，约十几分钟后自己好	对一下是不是临近窗口边界	已知边界误判，等窗口翻篇即恢复
几乎每天都撞、严重影响产出	评估是不是档位本身偏低	升档（同账号 Pro 配额高于 Plus）或切 API 按量
接了自己 key / 第三方端点后 429	查那条 key/端点的限额	是供应方 API 限额，和订阅额度无关

几个常被忽略的细节

CLI 本地和云端任务共用 5 小时窗口：你在终端跑的本地消息，和云里跑的任务，扣的是同一池额度，别以为换到云端就能绕开。
单条复杂请求很吃额度：长上下文、反复编译/思考的重任务，一条就可能吃掉相当一截窗口或周额度。把任务拆小、收敛上下文，比频繁撞墙后干等更划算。
面板数字偶有滞后：社区反馈过额度统计错位的个案，看到和直觉强烈不符的状态（比如显示有余量却被拦），先以 /status 现读为准，再判断要不要等或换路子。
升降档以官方实时为准：各档对 Codex 的具体用量倍数官方会调整，本文不写成绝对承诺；下单升档前以你账户里官方当下显示为准。

一句话收尾：Codex 的 429 / usage_limit_reached，九成是"额度到顶"而非故障。先用 /status 分清是 5 小时墙还是每周墙、看准重置时间，别死等重试；偶发就等、常态化撞墙就升档或换计费模型。对症下药，比反复被卡死高效得多。