歇脚：Day 14 过半没动静，10/17 凌晨那四分钟把额度条的分母改小了
Day 14 过半仍然没有下次重置钟点，这一期是歇脚；同时把 10 月 17 日凌晨那四分钟里额度条分母被改小的原始读数、核算方法和自查步骤摊开讲清楚。
现在是歇脚。
上一次全局重置在北京时间 10 月 18 日凌晨 5:12 落地，tibo 只发了一个词「Done」1。到今天凌晨两点，官方还没有给出下一次重置的钟点。
按太平洋时间划日，Day 14 的窗口是北京 10 月 18 日 15:00 到 10 月 19 日 15:00，现在已经过半。tibo 在窗口里只发了两条，其中一条是「What's cooking today」，29.8 万次浏览、1829 条回复，没有钟点，也没有承诺2。
所以这一期不催你蹬。这一期要讲的是 10 月 17 日凌晨那四分钟，它改小的东西，重置补不回来。
为什么现在是歇脚
蹬的意思，是在下一次重置落地之前，把还没用完的额度刷完。它的前提是知道下一次什么时候重置，这个条件现在是空的。
28 天公约还欠今天一个动作：按公约原文，每天要么出一项对多数人有用、明显更好的改进，要么做一次完整重置3。公约给的是「哪一天」，从来没给过「几点」。
窗口里的另一条，是他回答欧盟用户关于 dots 的问题，说会保证跨境继续可用、dots 以后进欧盟。那条跟额度无关4。
三份旁证都只能当参考。codex-resets.com 记到 63 次重置，平均间隔 6.4 天，最长一次空了 67.7 天7。oishi-hiroyuki.org 按日本时间把下一次放在 10 月 20 日到 24 日，3 天内 60%、7 天内 82%，页面自己标着是推算8。codexradar.com 的 28 天页仍然把 Day 14 记作「待公布」9。
这三条都不能当开蹬依据。今天没有可信的下次钟点，这波蹬的时段已经结束，剩下的额度留着按你自己的节奏用。
那四分钟里，变的是分母
先看额度条是什么。它是一个分数：上面是你已经用掉的量，下面是你的周额度，屏幕只把两者相除的结果给你看。
10 月 16 日 18:08 到 18:12（UTC），也就是美西周五上午 11 点前后、北京 10 月 17 日凌晨 2 点，很多账号上的分母同时变小了。
在 openai/codex 的公开仓库里，受影响用户把本地日志翻了出来，读数精确到毫秒：
| 议题与账号 | 平台 | 跳变前后的读数 | 两次读数相隔 | 来源 |
|---|---|---|---|---|
| maiarowsky | macOS | 24% → 96%（18:08:10Z → 19:04:03Z），中间没有任何请求，只有每 15 秒一次的额度轮询 | 56 分钟 | 议题 #54704 |
| N4DH | Linux | 24.0% → 97.0%（18:08:41Z → 18:08:53Z），18:13:47Z 到 100% | 12 秒 | 议题 #54704 |
| Eunchong1276 | macOS | 62% 直接撞上限（18:09:26Z），提示「10 月 22 日 15:13 再试」（日本时间） | 同一分钟 | 议题 #54704 |
| EgorStepkin | Windows | 77% → 10%（18:10:43Z → 18:11:21Z），这段日志只多 380,821 token，其中 373,120 是缓存输入 | 38 秒 | 议题 #54677 |
| rinmay2 | Windows | 同一个会话里 57% → 0%，两次读数相隔 10.131 秒 | 10 秒 | 议题 #54718 |
前三行最说明问题。三个互不相干的账号，周重置时间戳落在同一分钟：06:13:18Z、06:13:00Z、06:13:29Z，彼此相差不到 30 秒10。跳变发生的那一刻，这几个时间戳一个都没动。
用他们自己的速率算一遍更直白。N4DH 事发前大约每 9M token 掉 1 个百分点，+73 个点对应约 650M token，那 12 秒里没有发生10。Eunchong1276 事发前每个点约 21M token，从 62% 走到 100% 需要约 800M token，一分钟里也没有10。
官方到发稿为止没有解释。这几条议题下面只有用户和一个自动机器人在回复，没有员工认领，也没有人给出核算11。状态页同样安静。
离解释最近的是两段支持回复，被一位用户转述在一篇 10 月 18 日的长文里：
「Server-side records show that the weekly allowance used to calculate your meter decreased while the amount already consumed initially stayed the same.」「Once the lower allowance took effect, the same usage represented a larger percentage of the new limit.」
翻成中文：服务端记录显示，用来计算你额度条的周额度变小了，已经消耗的量起初没变；额度降低生效之后，同样的用量占新上限的比例就变大了。
原始截图没有公开，这两句的分量停在「一位用户的转述」12。
同一篇长文里还有一个更具体的样本：一位用户 10 月 6 日从 200 美元档降到 100 美元档，额度到 10 月 16 日才跟着变，中间隔了十天，而且落在周中；支持回复说，记录里看不出为什么晚了十天12。
这层解释只覆盖降过档的账号。上面那台 Mac 整周没换过套餐，日志里的套餐标签在跳变前后完全一样10。
账不能全记在分母上
官方帮助页明写了两档加速的消耗倍率：Fast 是标准档的 2.5 倍，Astra 与 Sol 的 Ultrafast 是 8 倍13。
同一份活挂在 fast 上跑，吃掉的是标准档的 2.5 倍，这是设计如此。Ultrafast 跑一小时，账面等于标准档跑八小时。
另一种可能是服务端回溯入账：请求在别处发生，晚一些才记进来。议题里争的正是这个，用户要的是一份能对上账的核算11。
两种原因分开看，顺序可以这样走。
- 先看档位。这一小时你有没有开 fast 或 ultrafast。
- 再看分母。周重置时间没变、百分比却跳了一大截，才轮到分母。
- 最后对账。把本地
rate_limits快照和跳变时刻并排放，交给支持去核。
重置救急，救不了分母
券只处理分子。帮助页的原话是：用掉一张完整券会刷新你的 5 小时与每周 Codex 窗口，并改变你的周重置日14。
帮助页举的例子还写着：原本周五那次周重置，你也不会再拿到。
所以重置后的 100% 未必等于上周的 100%。分母小了，同样一个 100%，能干的活少一截。
有人把这个差额记了下来。一台 Linux 上的 Pro 账号从 48% 掉到 0% 用了约九分钟，按下券之后，同样的 token 排空速度快了 9 到 12 倍12。另一个账号重置后短暂显示 100%，两小时内滑回近空，周重置还被推到 10 月 24 日12。
更慢的版本来自一位 macOS 用户自己的记账：模型、推理档位、客户端版本、配置都没变，10 月 14 日每 1 个百分点能跑约 24M token，10 月 16 日约 23.6M，10 月 18 日只剩约 13.6M10。
他自己的账号在 10 月 17 日 22:28（UTC）被重置过，新的周重置时间是 10 月 24 日 22:28（UTC），也就是北京 10 月 25 日早上 6:2810。
这是单个账号的观测，条件没法完全控住，他自己也这么写。这份账单跟「分母变小」对得上，跟「服务端还在多记」也对得上。
10 月 29 日，分母会按官方口径再变一次
官方 Pro 档位页写得很清楚：9 月 22 日到 9 月 29 日太平洋时间上午 10 点之间有过有效 Pro 200 订阅的账号，可以把原来的额度用到 10 月 29 日13。
之后订阅自动切到更低的额度，每月价格仍然是 200 美元。
官方只给日期，没给钟点。按太平洋时间折算，这一步落在北京 10 月 29 日下午到 10 月 30 日下午之间。
对这批账号来说，10 月 29 日以前每过完一个周窗口，用的都还是旧分母。之后的那个 100%，能干的活会明显少一截。
今天能做的四件事
记下你的周重置时间。 打开 Settings → Usage 就能看到。落在北京 10 月 22 日 14:13 前后的，跟上面那三个账号在同一个槽位；落在 10 月 25 日早上 6:28 前后的，说明你的周窗口是 10 月 18 日那次全局重置之后重新计时的——上面那位 macOS 用户就是。
券先攥着。 它挪走原来的周重置日，补不回变小的分母。官方也写明，支持不提供手动或补偿性重置14。
要报支持就带齐四样。 公告出处、使用的日期时间与时区、Usage 页截图、Codex 客户端与模型14。再要一份变化前后的绝对额度，百分比本身回答不了任何问题。
账号里买了 credits 的还多看一眼：额度条归零之后，Codex 会开始从 credits 扣。上面那台 Linux 账号在切到券之前，被扣掉了 295.8 credits12。
下一次能算「蹬」的时刻，要么来自官方给出的钟点，要么来自你自己那个周窗口到期。今天先歇脚，等钟点。
References
- 1Tibo「Done」
x.com
- 2
- 3Tibo 的 28 天公约
x.com
- 4Tibo 回 @argofowl
x.com
- 5@OpenAIDevs 周末项目帖
x.com
- 6OpenAI Status
status.openai.com
- 7Codex Resets 历史
codex-resets.com
- 8重置间隔预报
oishi-hiroyuki.org
- 9Codex 雷达站
codexradar.com
- 10议题 #54704
github.com
- 11议题 #54718
github.com
- 12@lin_builds 的长文
x.com
- 13About ChatGPT Pro tiers
help.openai.com
- 14How banked Codex resets work
help.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.