歇脚：凌晨 1 点 40 又回满，两次只隔 24 小时 30 分，下次钟点还空着 (2026)

现在是歇脚。

北京时间 10 月 24 日凌晨 1 点 40 分前后，Day 18 的重置落到了账号上。到发稿，tibo 没有为它发过一句话。

六个多小时后，07:12，他发的是 28 天公约第 19 天帖：dots 通话接通更快、Codex 与 Work 里中途改推理档不再让缓存失效、CLI 更新。三项都是小更新，没有钟点，也没有预告1。

这波蹬完了。下一次重置什么时候来，官方一个字没说。

落地在 01:40，官方这次又没发帖

昨天 12:46，tibo 的 Day 18 帖收尾是一句「But yes… that's a reset!」2

75 秒后他补上落地时限：「Landing tomorrow before 10am PST together with a small ship.」3

按旧金山当地 10 月 23 日上午 10 点算，是北京 10 月 24 日 01:00；照字面 PST 再挪一小时，是 02:00。

实际落地在北京 01:40。这个时刻来自第三方监测：@codex_reset 那条写的是「Our monitor spotted it at Oct 23, 17:40 UTC. Tibo hasn't confirmed yet.」4

社区侧最早的到账自述都在早上七点以后，是醒来才看见的：07:20 一条日文「Reset されとった」5，07:31 一条「woke to codex reset」6，08:06 一条日文复述「あと予告通りリセットもされてました」7。

上一期我照这个句式把窗口写成「01:00 之后十几分钟、最晚不超过 02:00」。这次晚了 40 分钟，上界成立，那个「十几分钟」不成立。

再遇到「before + 钟点」，把字面 PST 那一小时当成真正的余量。

这是公约期第二次落地不发声。Day 17 那一次也没有，到账靠的是第三方监测与社区自述8。

看用量页判断，比等帖快。

两次重置之间只隔 24 小时 30 分

Day 17 落在北京 10 月 23 日 01:10，Day 18 落在 10 月 24 日 01:40，中间 24 小时 30 分。

公约期此前最短的间隔是 2 天 1 小时 05 分，出现在 Day 6 到 Day 8 之间。这次把纪录砍掉一半。

日格	落地（北京）	距上一次	取证
Day 2	10 月 7 日 11:35 9	—	官方帖
Day 6	10 月 11 日 12:01 10	4 天 0 小时 26 分	官方帖
Day 8	10 月 13 日 13:06 11	2 天 1 小时 05 分	官方帖
Day 10	10 月 15 日 14:28 12	2 天 1 小时 22 分	官方帖
Day 13	10 月 18 日 05:12 13	2 天 14 小时 44 分	官方帖
Day 15	10 月 20 日 14:33 14	2 天 9 小时 21 分	官方帖
Day 17	10 月 23 日 01:10 8	2 天 10 小时 37 分	第三方监测
Day 18	10 月 24 日 01:40 4	24 小时 30 分	第三方监测

前六行记的是官方确认帖的时刻，逐账号到账可能更早或更晚。后两行没有官方帖，记的是第三方监测的时刻。

19 天里八次全员重置、一张券，平均两天多一点一次。

Day 19 交的是改善，没有钟点

公约的原话是每天交一件「clear improvement and relevant for most Codex/Work users」，或者一次完整重置15。

今天交的是改善。按条款，这一天算履约，官方不欠一次重置。

CLI 那部分是这天最实的：可复用提示词预设、内联的模型与权限设置、企业 MCP 登录、长会话恢复失败的修复、Windows 企业代理认证。他还补了一句，CLI 的用量自 DevDay 之后翻了一倍16。

昨天那句「together with a small ship」，大概就是今天这批小更新。官方没有点明这件事。

社区对这天的评价不高。第三方日历页给两项更新的站内赞踩是 21% 与 29%，同页 Day 16 那条是 93%17。

评论里最集中的声音是「小更新算不算 clear improvement」：@manuelgongua 把公约原句贴回来质询18。

也有人直接读成今天不重置：@Adrilopal99 写「Looks like we might be going without a reset today」19，中文那条写「通篇没提 Reset」20。

这些是社区读法，不作判据。判据只有一条：官方有没有给出下一次的时间。今天没有。

你账上的下一次自动刷新，大概落在 10 月 31 日

这是今天最该看清的数字。

帮助页写得很直白：券、全局重置、付费即时重置，都可能改动它们影响的那份额度的下一次刷新时间；一旦某个用量周期被重启，新排期就取代旧排期21。

同一页给的例子是：周周期本来周五结束，周二重启之后下一次就是下周二，原本周五那次不再给。

照这条规则，昨晚 01:40 那次多半已经把你的周周期起点挪到了今天凌晨，下一个自动刷新就落在七天后。

怎么核：打开用量页，看 next refresh 那一行。显示在 10 月 31 日前后，这条推算就对了；显示在别的日子，按页面上的算。

这个日期是我按规则推的，官方没有公布。

它的用处在于：这七天里你的额度就是这次补满的那一份。自动刷新不会因为你用得快就提前。

现在按不动券，门槛是 80%

在 Usage 页按券，被覆盖的额度里至少要有一份额度剩不到 80%。都在 80% 以上，界面只会显示「你的用量现在不需要重置」，券继续留到过期21。

今天凌晨刚补满，多数人正卡在这条线上。

再加上另外两条：已经按掉的券遇到全局重置不退还，也不叠加，官方的算例是从 95% 补到 100%，不会变成 200%；过期的券不恢复、不补发，支持也不提供手动或补偿性重置21。

于是这两天的组合很尴尬。@qianxueye 说「reset 都浪费掉了」22，日本侧一位用户写，自己在券到期前把攒着的几张都按了，结果又赶上一次重置23。

到期日在眼前的券，唯一能按动的路子是先把周额度用掉两成以上，再按。这就是拿一份额度换一份额度，值不值自己算。

到期日在 11 月的，留着。

还有人今天在提另一种玩法：@anyhowbin 写「CODEX 昨天重置了，今天适合给 banked reset 重置卡」24。

重置越勤，剩下没用掉的额度越像废纸

r/codex 上一位 Plus 用户把账算成了公式：得到的约是「剩余天数 ÷ 7 × 周额度」，失去的是手里没烧完的那部分25。

他的处境是 5 小时档卡着，两天里根本烧不完一周的量；Pro 能并行跑，能把一次重置吃干净。

这条和昨天那期接得上：重置对每个人不等值。周额度已经掉到一半以下的人，重置是白拿；一直在排队等 5 小时窗口的人，重置是把剩下的清零。

所以别为了「可能又要重置」去熬夜排队。今天该干的，是按这七天只有一份额度来排。

今天可以放心歇

今天的日格要到北京 15:00 才走完，还剩五个多小时。同一天里既发改进又给重置，他干过四次，今天这一格再冒一次重置仍然可能。

可能归可能，钟点还是空的。所以没有可着手准备的清仓时段。

三个动作。

打开用量页，看两个数：周额度还剩多少、下一次刷新是哪天。后一个才是你真正的下一次。

券对一眼到期日：离 80% 还远就留着，快到期的先想清楚要不要拿两成额度去换。

排活按七天一份来排。长重构、批量跑这种，攒到下一次确认的钟点再上。

公约走到 19/28，还剩九天26。他 10 月 13 日说过有个「让所有人用量明显变多」的计划27，到今天没有公布内容。等那个，比等下一次重置实在。

旁证一句带过：第三方追踪站仍把 Day 18 挂在「等待确认」28；白名单里那份镜像记的是「站长确认已完成、到账时分未知」，24 小时概率 5%29；预报站把下一次强制重置押在 10 月 26 日到 29 日、三天内 62%，页面自标是预测30。

References

1
tibo：Day 19 帖
x.com
2
tibo：Day 18 帖
x.com
3
tibo：落地时限
x.com
4
Codex Reset 监测帖
x.com
5
@machidento
x.com
6
@JasonBinderAu
x.com
7
@angeworkCoLtd
x.com
8
Codex Reset 监测：Day 17
x.com
9
落地帖\
x.com
10
落地帖\
x.com
11
落地帖\
x.com
12
落地帖\
x.com
13
落地帖\
x.com
14
落地帖\
x.com
15
tibo：28 天公约
x.com
16
tibo：CLI 细目
x.com
17
Codex Resets：28 天日历
codex-resets.com
18
@manuelgongua
x.com
19
@Adrilopal99
x.com
20
@LanzhiAI
x.com
21
How resets work in Codex
help.openai.com
22
@qianxueye
x.com
23
@nariya
x.com
24
@anyhowbin
x.com
25
r/codex：Plus 用户的账
reddit.com
26
Codex 雷达站
codexradar.com
27
tibo：用量计划
x.com
28
Codex Resets
codex-resets.com
29
Codex Reset 雷达镜像
codex-reset-radar.pages.dev
30
Codex 重置预报
oishi-hiroyuki.org

现在是歇脚。

北京时间 10 月 24 日凌晨 1 点 40 分前后，Day 18 的重置落到了账号上。到发稿，tibo 没有为它发过一句话。

这波蹬完了。下一次重置什么时候来，官方一个字没说。

落地在 01:40，官方这次又没发帖

昨天 12:46，tibo 的 Day 18 帖收尾是一句「But yes… that's a reset!」2

75 秒后他补上落地时限：「Landing tomorrow before 10am PST together with a small ship.」3

按旧金山当地 10 月 23 日上午 10 点算，是北京 10 月 24 日 01:00；照字面 PST 再挪一小时，是 02:00。

实际落地在北京 01:40。这个时刻来自第三方监测：@codex_reset 那条写的是「Our monitor spotted it at Oct 23, 17:40 UTC. Tibo hasn't confirmed yet.」4

上一期我照这个句式把窗口写成「01:00 之后十几分钟、最晚不超过 02:00」。这次晚了 40 分钟，上界成立，那个「十几分钟」不成立。

再遇到「before + 钟点」，把字面 PST 那一小时当成真正的余量。

这是公约期第二次落地不发声。Day 17 那一次也没有，到账靠的是第三方监测与社区自述8。

看用量页判断，比等帖快。

两次重置之间只隔 24 小时 30 分

Day 17 落在北京 10 月 23 日 01:10，Day 18 落在 10 月 24 日 01:40，中间 24 小时 30 分。

公约期此前最短的间隔是 2 天 1 小时 05 分，出现在 Day 6 到 Day 8 之间。这次把纪录砍掉一半。

日格	落地（北京）	距上一次	取证
Day 2	10 月 7 日 11:35 9	—	官方帖
Day 6	10 月 11 日 12:01 10	4 天 0 小时 26 分	官方帖
Day 8	10 月 13 日 13:06 11	2 天 1 小时 05 分	官方帖
Day 10	10 月 15 日 14:28 12	2 天 1 小时 22 分	官方帖
Day 13	10 月 18 日 05:12 13	2 天 14 小时 44 分	官方帖
Day 15	10 月 20 日 14:33 14	2 天 9 小时 21 分	官方帖
Day 17	10 月 23 日 01:10 8	2 天 10 小时 37 分	第三方监测
Day 18	10 月 24 日 01:40 4	24 小时 30 分	第三方监测

前六行记的是官方确认帖的时刻，逐账号到账可能更早或更晚。后两行没有官方帖，记的是第三方监测的时刻。

19 天里八次全员重置、一张券，平均两天多一点一次。

Day 19 交的是改善，没有钟点

公约的原话是每天交一件「clear improvement and relevant for most Codex/Work users」，或者一次完整重置15。

今天交的是改善。按条款，这一天算履约，官方不欠一次重置。

昨天那句「together with a small ship」，大概就是今天这批小更新。官方没有点明这件事。

社区对这天的评价不高。第三方日历页给两项更新的站内赞踩是 21% 与 29%，同页 Day 16 那条是 93%17。

评论里最集中的声音是「小更新算不算 clear improvement」：@manuelgongua 把公约原句贴回来质询18。

也有人直接读成今天不重置：@Adrilopal99 写「Looks like we might be going without a reset today」19，中文那条写「通篇没提 Reset」20。

这些是社区读法，不作判据。判据只有一条：官方有没有给出下一次的时间。今天没有。

你账上的下一次自动刷新，大概落在 10 月 31 日

这是今天最该看清的数字。

同一页给的例子是：周周期本来周五结束，周二重启之后下一次就是下周二，原本周五那次不再给。

照这条规则，昨晚 01:40 那次多半已经把你的周周期起点挪到了今天凌晨，下一个自动刷新就落在七天后。

怎么核：打开用量页，看 next refresh 那一行。显示在 10 月 31 日前后，这条推算就对了；显示在别的日子，按页面上的算。

这个日期是我按规则推的，官方没有公布。

它的用处在于：这七天里你的额度就是这次补满的那一份。自动刷新不会因为你用得快就提前。

现在按不动券，门槛是 80%

在 Usage 页按券，被覆盖的额度里至少要有一份额度剩不到 80%。都在 80% 以上，界面只会显示「你的用量现在不需要重置」，券继续留到过期21。

今天凌晨刚补满，多数人正卡在这条线上。

于是这两天的组合很尴尬。@qianxueye 说「reset 都浪费掉了」22，日本侧一位用户写，自己在券到期前把攒着的几张都按了，结果又赶上一次重置23。

到期日在眼前的券，唯一能按动的路子是先把周额度用掉两成以上，再按。这就是拿一份额度换一份额度，值不值自己算。

到期日在 11 月的，留着。

还有人今天在提另一种玩法：@anyhowbin 写「CODEX 昨天重置了，今天适合给 banked reset 重置卡」24。

重置越勤，剩下没用掉的额度越像废纸

r/codex 上一位 Plus 用户把账算成了公式：得到的约是「剩余天数 ÷ 7 × 周额度」，失去的是手里没烧完的那部分25。

他的处境是 5 小时档卡着，两天里根本烧不完一周的量；Pro 能并行跑，能把一次重置吃干净。

这条和昨天那期接得上：重置对每个人不等值。周额度已经掉到一半以下的人，重置是白拿；一直在排队等 5 小时窗口的人，重置是把剩下的清零。

所以别为了「可能又要重置」去熬夜排队。今天该干的，是按这七天只有一份额度来排。

今天可以放心歇

今天的日格要到北京 15:00 才走完，还剩五个多小时。同一天里既发改进又给重置，他干过四次，今天这一格再冒一次重置仍然可能。

可能归可能，钟点还是空的。所以没有可着手准备的清仓时段。

三个动作。

打开用量页，看两个数：周额度还剩多少、下一次刷新是哪天。后一个才是你真正的下一次。

券对一眼到期日：离 80% 还远就留着，快到期的先想清楚要不要拿两成额度去换。

排活按七天一份来排。长重构、批量跑这种，攒到下一次确认的钟点再上。

公约走到 19/28，还剩九天26。他 10 月 13 日说过有个「让所有人用量明显变多」的计划27，到今天没有公布内容。等那个，比等下一次重置实在。

References

1
tibo：Day 19 帖
x.com
2
tibo：Day 18 帖
x.com
3
tibo：落地时限
x.com
4
Codex Reset 监测帖
x.com
5
@machidento
x.com
6
@JasonBinderAu
x.com
7
@angeworkCoLtd
x.com
8
Codex Reset 监测：Day 17
x.com
9
落地帖\
x.com
10
落地帖\
x.com
11
落地帖\
x.com
12
落地帖\
x.com
13
落地帖\
x.com
14
落地帖\
x.com
15
tibo：28 天公约
x.com
16
tibo：CLI 细目
x.com
17
Codex Resets：28 天日历
codex-resets.com
18
@manuelgongua
x.com
19
@Adrilopal99
x.com
20
@LanzhiAI
x.com
21
How resets work in Codex
help.openai.com
22
@qianxueye
x.com
23
@nariya
x.com
24
@anyhowbin
x.com
25
r/codex：Plus 用户的账
reddit.com
26
Codex 雷达站
codexradar.com
27
tibo：用量计划
x.com
28
Codex Resets
codex-resets.com
29
Codex Reset 雷达镜像
codex-reset-radar.pages.dev
30
Codex 重置预报
oishi-hiroyuki.org

歇脚：凌晨 1 点 40 又回满，两次只隔 24 小时 30 分，下次钟点还空着

落地在 01:40，官方这次又没发帖

两次重置之间只隔 24 小时 30 分

Day 19 交的是改善，没有钟点

你账上的下一次自动刷新，大概落在 10 月 31 日

现在按不动券，门槛是 80%

重置越勤，剩下没用掉的额度越像废纸

今天可以放心歇

References

Related content

歇脚：凌晨 1 点 40 又回满，两次只隔 24 小时 30 分，下次钟点还空着

落地在 01:40，官方这次又没发帖

两次重置之间只隔 24 小时 30 分

Day 19 交的是改善，没有钟点

你账上的下一次自动刷新，大概落在 10 月 31 日

现在按不动券，门槛是 80%

重置越勤，剩下没用掉的额度越像废纸

今天可以放心歇

References

Related content