额度一定会回来。但「怎么回来」取决于发生了三件事里的哪一件,而其中只有一件遵循你能算的规则。
分不清这一点,代价很具体:你会拿等去解决一个只能靠花钱或厂商决定才能解决的问题,也会买下一个其实再等一会儿就自己好了的东西。
先给结论
| 类型 | 谁决定 | 能预测吗 | 你该做什么 |
|---|---|---|---|
| 窗口释放 | 算术 | 能,按你自己的用量算 | 算出时间点,据此安排 |
| 厂商重置 | 厂商 | 不能 | 尽量早地被通知 |
| 预存重置 | 你 | 你决定什么时候花 | 有意地花,别顺手花掉 |
下面是把这三行拆开讲。
一、窗口释放:可以算的那部分
Codex 用的是滚动窗口,不是每日配额。官方文档和产品内的用量面板描述的是两个窗口并行:一个以小时计的短窗口,一个以周计的长窗口(OpenAI 定价与用量文档)。两者相互独立——短窗口恢复了,不会给周窗口回血;反过来也一样。
最容易被误读的是第二个窗口。当用量面板显示短窗口还很健康、工具却依然拒绝你的时候,你几乎总是撞在周上限上,当天再等多久都不会变。
因为窗口是滚动的、不在固定整点重置,「什么时候恢复」并不是一个被公布的数值,而是你自己消费时间的函数。用量面板里那个重置时间点,是厂商服务器随每次用量报告下发的绝对时间戳,不是你本地算出来的——所以以你客户端实际打印的那一行为准,不要按日历猜。
实际推论:这是三种重置里唯一值得做算术的一种,而算术的对象是你自己的使用历史,不是厂商的时间表。
二、厂商重置:谁也算不出来的那部分
厂商重置是一个决定。有人决定提前解除上限,应用到他挑选的一批账户上。这不是假想——OpenAI 在 2026 年 9 月 7 日给全球 Plus、Pro 和 Business 账户发放过一次即时重置,同一篇帮助文档还记录了 9 月 3 日、4 日分批发给符合条件的新老账户的重置(OpenAI 帮助中心:Codex 预存重置的运作方式)。
注意那篇文档里没有的东西:时间表。这里没有规律可学,因为触发它的是商业决定——算力空闲、上一个体验太差的周期、一次模型发布。厂商重置也是唯一一种「不需要你做任何事,约束就变了」的事件,这正是它值得订阅一个通知的原因。
任何声称能预测下一次重置的东西,都是在用自信的排版遮住自己在猜。你只能被告知「已经重置了」,不可能被告知「快要重置了」。
三、预存重置:你决定的那部分
三种里最新的一种,是厂商发给你但不替你使用的重置。它躺在你的账户里,直到被你花掉或过期,而且是主动花掉、不会自动生效。
关于它有两个细节特别容易搞错:
- 它会一次性回满两个窗口。 用掉一次完整的预存重置,会同时重置短窗口和每周周期,并且改变你后续每周重置的日期。所以在额度还有余量时用它,既浪费了一部分,又把整个节奏往前挪。
- 不是任何时候都能用。 只有当确实有符合条件的用量周期被重置时,它才会被消耗。如果当时没有任何可重置的项目,这次预存重置仍然保留在你的账户里。
所以它不算第四个需要盯着的约束。它只是一个你只有一次机会做的决定,而唯一真正糟糕的结果,是在一个「再等一小时窗口自己就恢复了」的日子里顺手把它花掉。
三者为什么总被混为一谈
因为它们呈现出来的是同一块屏幕。一次被拒绝的请求,看起来完全一样——不管原因是算术、是厂商的决定,还是你账户里躺着一个没花的重置。
最快的判读顺序:
- 用量面板里短窗口在恢复吗? 是,说明你在周上限上。别等了,把今天的活重新排一遍。
- 面板显示还有余量,工具却依然拒绝? 先看有没有可用的预存重置,再去怀疑是 bug,最后查厂商状态页。
- 没有任何操作、也没过多久,限制自己松开了? 那是厂商重置。和你做过什么无关,你做什么也换不来下一次。
最后一条是最不舒服的地方,也是我们做通知而不是做计算器的原因。计算器只能作用于三种里的第一种——而第一种,恰好是你自己就能算出来的那种。
常见问题
Codex 的额度多久恢复? 如果撞的是短窗口,额度会随着较早的用量逐步释放,所以「部分恢复」可能远早于「完全恢复」。如果撞的是周上限,那么只有整周向前滚动,或者一次厂商重置,才会改变它。
有人能预测下一次 Codex 重置吗? 不能。厂商重置跟随的是商业决定而不是时间表,OpenAI 从未公布过。你在网上看到的估计值,是对过去事件的事后重建,不是预测。
拿到预存重置就该马上用吗? 不该。在你确实被卡住的时候用,或者在周上限即将让你损失一整天工作的时候用。在还有余量时用掉,只会平白重置你的每周周期。
撞在周上限时,短窗口恢复有帮助吗? 没有。两个窗口相互独立,短窗口恢复不会给周上限补任何额度。
ResetRemind 会在你订阅的那些套餐(Codex、Claude Code、Grok、Gemini)真的发生重置时给你发一封邮件。免费,不用注册,一键退订。