先歇脚：重置被一场投票投了出来，下次钟点还是没人给

截至北京时间 10 月 7 日 12 时，下一次重置的钟点还是没有人给。Codex 付费套餐眼下没有可以蹬的时段，这一轮继续歇脚。而这一次连等待都省了：机会已经在今天上午走完——北京时间 10 月 7 日 11:35，tibo 发帖说这一轮重置已经处理完成 1。

「能蹬」只有一个前提，就是已经知道下一次重置何时落地，于是能在它落地之前把还没用完的额度快速刷完，清掉的是旧额度那一仓。今天这个前提断在两处：重置已经落地，而下一个钟点没有人给。落地之前刷额度和落地之后刷额度是两件不同的事，前者是清旧仓，后者只是新一周的正常使用。

官方侧没有下一个钟点。 今天 11:35 那条重置帖之后，tibo 又发了一条「我们不会撤回这些改进，你可以既有蛋糕又能把它吃掉，明天见 Day 3」，再往下就是一句「晚上好」和一句回别人的闲聊，最后一条停在 11:38 2。这些帖子里没有时间、没有倒计时，也没有适用范围。官方开发者账号 @OpenAIDevs 最近一条原创停在 10 月 7 日 03:20，讲的是用语音指挥 Codex、让键盘歇一歇，同样没有额度内容 3。

社区侧没有时间。 今天社区讨论得很热闹，方向是「这次该发券还是该直接重置」，以及这张票投得对不对。没有人给出日期或时刻。能对着定闹钟的钟点，今天还是没有。

最近这一次重置已经落地。 11:35 那条帖本身就是落地确认；从那一刻起，账号里的 5 小时窗口和每周窗口都按新的周期重新开始计算。

按 tibo 10 月 5 日立下的 28 天公约，明天还有 Day 3，那一天同样可能出一项改进，也可能出一次完整重置 4。「哪天可能」换不来一个闹钟，能定闹钟的只有钟点。

这一轮真正的增量是重置的来路。北京时间 10 月 7 日 04:56，tibo 发了 Day 2 汇总帖，四项改进一次列完 5。两分钟后的 04:58，他发了一条只有一个词的帖：「Vote」，配一个二选一投票，一个选项问今天算不算够好，另一个问是不是需要一次重置 6。

05:07 他补了一句：「四项更新，或者一次重置。或者两者都要。第二天怎么样。」 7 06:02，有人写「我今天早上就已经把票投给重置了」，他回「I accept your vote」 8。06:32 他又发了一个投票，正文只有两个词：「To calibrate」 9。

到 11:35，结果出来了。他引用 Day 2 汇总帖宣布重置已经处理完成，原话是投票很清楚、社区要求一次重置；「我做了校准，看起来规则偏向重置这一边，但眼下的规则就是这样」 1。

一分钟之后他又补了一条：改进不会撤回，明天见 Day 3 10。

第三方预测站在投票进行中记到的实时读数是六万三千多票里 75.3% 选了「需要重置」；这个站同时注明，它没有把这次投票计入自己的概率计算 11。

结果出来之前，社区里已经有人算到了。MrTacticalX 说所有人都会投「需要重置」，「反正更新都会拿到，OpenAI 又不会因为你投了重置就把更新收回去」 12。markerdmann 说的是同一件事的反面：「得让投票有代价才行——投了重置就把当天发的东西收走，那才叫投票」 13。_KimKPossible 承认自己投了重置，同时说：「就算今天发的东西足够好，大家还是会投重置。」 14 tibo 那句「规则偏向重置」，说的正是这件事。

公约里「改进」那一半，第二天结算出四项。2.1 Auto-review 免费：10 月 6 日 15:13 发的，面向所有用 ChatGPT 账号登录的用户，入口在设置 → 权限 → Auto-review。打开以后，长任务里主智能体做的每一步都会被第二个智能体审一遍，目的是拦下高风险动作和跑偏的动作；这项功能现在免费，也不占套餐用量 15。

2.2 面向构建者的简化 API：只出现在汇总帖里，还没有单独的公告 5。

2.3 会议笔记：引的是 ChatGPT 官方那条——Meetings 插件替你记会议，把摘要和下一步存进 ChatGPT Space，可以选择只自己看或分享给团队；目前是 macOS 桌面端的 beta，Pro 和 Business 可用 16，tibo 的 Day 2.3 帖把这条收进了自己的更新清单 17。

2.4 Decisions API：@OpenAIDevs 说它面向所有开发者开放公开测试，让应用在近实时里挑模型、工具或动作，决策速度最高比走 Responses API 的 GPT-6 Luna 快 10 倍 18；tibo 说他们会自己用这个 API 改进体验 19。

汇总帖里说的「一些数学证明」也有出处。OpenAI 当天发了一篇博文，说用内部前沿模型产出了一批数学结果，并把 Lean 形式化证明、10 份推理摘要和算力估算一起放进了 GitHub 仓库；博文写，平均一个结果用掉的算力大致相当于 ChatGPT Pro 思考三小时 20。

四项功能加上这批数学结果，是公约「改进」那一半的第二次结算：第一天结算成提速，第二天结算成四项功能。公约原本写的是每天「要么出一个明确改进，要么补一次完整重置」，第二天的结果是两样一起给。

对读者来说，这次重置和以往那些补偿重置有一个关键差别：它是「直接重置」。官方帮助页区分过两种形态：一种是自动的、全员的，不用你操作，到点覆盖；另一种是券，存进账户，由你自己挑时间按 21。帮助页把券的规则写得很细：用掉一张完整的券会刷新你的 5 小时用量窗口和每周用量窗口，并且改变你的周重置日；这张券只在你真的刷新到至少一个窗口时才会被消耗，没有东西可重置的时候它会继续留着。

直接重置没有这些选择权，到点就覆盖。今天社区里最响的一类抱怨就来自这里。Im_IrushiK（8924 粉）在北京 12:15 写：「随机掉落的 Codex 重置？？？我刚在用，5 小时和周额度突然都回到 100%。真希望他们早点宣布，我本来会先把剩下的额度用完。」 22

LightDriver21 说的是同一件事：「我挺喜欢今天的更新，四项都出了，我以为不会再有重置，就把两张券里的一张烧了。两小时后 tibo 按下了重置键。」 23 remjxer 把诉求写得更直接：「我们等的是券，不是一次直接重置。直接重置惩罚的是周额度还没用满的人。」 24

jaesmeta 说：「该发券的。我刚用掉一张券，Pro 200 上还有 65% 以上的额度。」 25 Seefs_ 用中文写：「又把我没用的额度回收了，我还有 90 多的额度等最后两天用完，现在又给我推后一周；要不就 banked reset，要不就别重置。」这条里「推后一周」是当事人自己的说法，官方没有公布这一次直接重置对周重置日的影响 26。

也有到账快的。merckhung 在北京 11:54 说「17 分钟前收到 Codex 重置」 27，lucastohdev 说「这是我遇到的第一次按时落地的 Codex 重置」 28。

这些抱怨指向同一件事：直接重置无法预告，为它留余量没有意义。这个频道说的「蹬」是为另一种情形准备的——官方先给出钟点，你在钟点之前把额度榨干，清的是那一仓旧额度。今天没有钟点，所以没有可清仓的窗口；重置落地之后，账面反而回到了满格。手里如果还有券，眼下不急着按：按一张券换到的是一次由自己挑日期的周重置，等到下一个钟点真的出现，它才派得上用场。

上一期还挂着的两条故障，现在都结了。Work Mode 报错从北京时间 10 月 5 日 15:03 报起，状态页在 10 月 6 日 10:10 写下「所有受影响的服务已完全恢复」 29。Codex Cloud 的错误率从 10 月 6 日 01:58 报起，同日 08:01 恢复 30。

更正一处：上一期写这两条「到 10 月 6 日下午仍未关闭」，按状态页留下的记录，它们在那天上午就已经恢复。状态页此刻的抬头是「我们完全正常运行」，对 Codex 四个组件给出的 7 月至今可用率是 99.95% 31。

把故障和今天的重置放在一起看，有一点值得说清：这次重置来自投票，不是故障补偿。官方从认领故障到发布重置，全程没有把两者挂钩。

三家旁证站今天的读数放在一起，其中没有任何一家给出下一次重置的钟点。codex-resets.com 把最近一次重置记在北京时间 10 月 7 日 11:35，累计 58 次，平均间隔 6.8 天，最长一次等了 67.7 天，页面上仍然没有下一次的预测字段 32。codexradar.com 的站速览图更新到 10 月 7 日 00:38，Tibo 雷达收录到北京 00:12 那条，逐条标的是「无重置信号」；它把 Day 2 记成「4 项更新 + 已重置」，Day 3 还是「待公布」 33。oishi-hiroyuki.org 在 10 月 7 日的版本里把下一次重置的目安放在 10 月 10 日到 10 月 13 日，三天内 41%、七天内 82%；它自己注明这套数字按上一次落地是 10 月 3 日算，既没有把这次投票算进去，也没有把今天这一次重置算进去 11。频道配置里列的那个接口仍然整份停在 9 月 29 日：窗口关闭，建议动作是「等」，24 小时概率 5%，下一次重置时间为空 34。

这三家都只是旁证。开蹬与否，看的仍然是官方有没有给出那个钟点。