codex 额度重置

很多人是在赶任务的半夜被卡住的：正写得顺，Codex 突然不干活了，提示额度受限，但又不知道是等一会儿就恢复、还是要等到下个周期。这篇不讲概念，只给你一套能对着核对的顺序：先判断卡在哪一类额度，再看它的重置节奏，最后决定是等、是调用量结构，还是换个入口继续跑。

很多人是在赶任务的半夜被卡住的：正写得顺，Codex 突然不干活了，提示额度受限，但又不知道是等一会儿就恢复、还是要等到下个周期。这篇不讲概念，只给你一套能对着核对的顺序：先判断卡在哪一类额度，再看它的重置节奏，最后决定是等、是调整调用量结构，还是换个入口继续跑。

先说明一点：不同套餐、不同入口、不同客户端的口径一直在变，所以正文里不写死任何具体数字。凡是需要看数值的地方，都告诉你去站内哪个页面核对当时的实际情况，这样一篇内容过几个月也还能用。

先分清是哪一种额度被卡住

Codex 相关的限制往往分好几层：订阅套餐里的窗口额度、账号级的频率限制、以及你自备 API Key 时的账户余额。这三者触发后的恢复方式和等待时间完全不同，先定位再动手，别一上来就换号或者重装客户端。

• 把当前入口和套餐档位记下来，再去 /coding-plans 找到对应档位页面，看它的额度口径是怎么写的
• 把现象发到 /codex-radar 对照一下，看是只有你一个人遇到，还是这个时段大家都在报同样的问题
• 如果换成完全不同的入口（比如从客户端换到自备 API Key）马上就能跑，多半不是账号被整体封停，而是某一个入口的窗口额度见底
• 遇到多人共用同一席位的情况，别人跑掉的量也算在你这一格里，单人视角的判断会失真，最好先问一句谁在跑长任务

重置周期与触发条件：按滚动窗口想，而不是按整点想

大部分订阅制额度是滚动窗口制，也就是从你这一轮第一次消耗开始计时，窗口走完才逐步回血，并不是每天零点一起刷新。所以「几点重置」这个问题本身往往问错了方向，真正该问的是「我这一轮的窗口从什么时候开始、走到哪了」。

触发条件主要就两个：一是窗口内累计消耗到上限，二是短时间内请求过于密集触发频率限制。后者通常等几分钟到几十分钟就能缓过来，前者要等窗口走完。区分办法很简单：隔十几分钟再发一句极短的请求，能过就是频率限制，还是过不去就是窗口额度。

1. 记一轮时间线写下第一次被拒的大致时间，以及之后每隔十几分钟试一次的结果，连续试四五次就能看出是慢慢恢复还是完全没动。
2. 核对档位口径拿着套餐档位去 /coding-plans 对应页面，确认这个档位的窗口是怎么算的，别拿别人的时间直接套到自己身上。
3. 对照外部反馈到 /resets 看别人反馈的恢复节奏，如果多数人也是同一个时间段恢复，说明是整体节奏，不是你的账号出问题。
4. 决定等还是换时间线显示短时间内回不来，就别干等，直接走后面那套手动恢复的兜底方案。

手动恢复：能自己做的四步，按顺序试

所谓手动恢复，不是有什么隐藏按钮能立刻回血，而是把那些「你以为是额度没回来、其实是刚回一点又被吃掉」的情况排掉。按下面的顺序走，能省掉大量无效等待。

1. 先清后台停掉所有后台在跑的自动化任务和长任务，包括编辑器插件、脚本批处理，等一两分钟再试一次，确认不是回血后被后台立刻吃光。
2. 再核档位回到 /coding-plans 对应档位页，核对额度口径和是否有档位升级路径，先确认你要的是「等」还是「换档」，别凭印象做决定。
3. 看重置状态到 /resets 看当下的重置状态和恢复反馈，同时用 /codex-radar 判断是不是普遍现象，避免误判成自己账号的问题。
4. 走兜底通道如果确实等不了，切到自备 API Key 走按量计费是最直接的兜底，三条路的成本口径和取舍可参考站内 codex-quota-exhausted-paths 那篇的对比。

不适用的情形：如果账号本身处于异常状态，比如登录、付款或条款层面有问题，上面这几步都不会解决，那要走申诉渠道，不属于额度重置的范畴，别在这条路上反复折腾。

下次别撞墙：把用量结构改一改

额度见底多数不是你「模型用得多」，而是一轮任务里塞了太长的上下文、重复读同一批文件、或者让客户端自动多轮重试。这些动作看不出来在烧，但会把窗口消耗推得很快。

• 把大仓库的检索范围收窄到真要改的那几个文件，别让整库扫描变成默认动作
• 把长文档拆成多轮小任务，每轮只带必要上下文，跑完再进下一轮
• 把客户端里的自动重试次数调低，失败就停下来看原因，别让它自己刷额度
• 把最吃上下文的重活单独放到按量计费的 API 通道上，订阅额度留给日常轻任务

想量化到底烧在哪，参考站内 coding-client-token-burn 里对编程客户端 token 去向的拆解，再配合 /usage 看真实用量分布，比凭感觉省额度靠谱得多。