Tibo 加码了：Codex 今天不是一次 reset，而是「当场恢复 + 存一枚」
Tibo 确认 Codex 完成一次「sneaky double reset」：用户会得到一次即时 full reset，同时额外获得一枚存入 reset bank 的 reset。本文梳理这次补偿和 6 月 12 日 Rate Limit Banking 机制的关系，并给出今天的使用建议。
Tibo 今早把 6 月 16 日那次 Codex「model at capacity」事故的补偿做完了，而且不是普通补偿：他说团队做了一个「sneaky double reset」，用户会拿到一次完整 reset，同时还会额外得到一枚可放进 reset bank、之后自己决定何时使用的 reset。1
这条信号值得单独发一篇。前一篇只确认了「24 小时内全计划 reset」；今天的新信息是：OpenAI 第一次把事故补偿和 6 月 12 日上线的 Rate Limit Banking 机制连在一起。对开发者来说，含义很直白：今天可以先把重任务排上，但别把 bank 里的那枚顺手烧掉。
コンテンツカードを読み込んでいます…
这次到底给了什么
按 Tibo 原文，这次补偿分成两层：
这不是简单的「多送一次」。OpenAI 6 月 12 日刚宣布，Go、Plus、Pro、Business 用户可以保存 Codex rate-limit resets，之后再用；官方当时还给这些用户开局发了一次免费 reset。2 Tibo 随后解释过，之前用户抱怨「突然收到 reset，没法按自己节奏用」，所以下次按按钮时会让用户自己选择实际生效时间。3
コンテンツカードを読み込んでいます…
今天这条 double reset，就是这套新机制第一次被用在事故补偿里。
时间线：从故障到双重补偿
- 6 月 16 日 20:47，Tibo 确认部分 Codex 用户遇到「model at capacity」高错误率，团队正在恢复稳定。4
- 6 月 17 日 02:49，他跟进说问题已经修复，并请用户给团队 24 小时来重置所有计划的 Codex rate limits。5
- 6 月 18 日 08:10，他发出今天的「sneaky double reset」：一次立即 reset，再存一枚到 reset bank。1
这个节奏基本踩在他自己给出的 24 小时窗口内。更重要的是，事故补偿不再只是「把计数器清零」；它开始有了库存概念。
今天怎么用：先恢复生产，再存一颗子弹
如果你的 Codex 使用计划今天正好卡在 rate limit，操作上可以分三步：
- 先检查当前额度是否已经恢复。 Tibo 的说法是 full reset，适合把因事故推迟的长任务、批量修复、重构或多 agent 并行任务排到今天。
- 不要急着动 banked reset。 这枚存进 reset bank 的额度更适合作为后备，留给下一次高强度窗口，尤其是 Codex Thursday 后的新功能试用、紧急修复或周末集中开发。
- 继续盯着账号内的 reset credits 入口。 6 月 18 日 Codex CLI 0.141.0 changelog 里，OpenAI 写到 app-server clients 已经可以「read or redeem rate-limit reset credits」。6 这说明 reset credits 已经不只是推文里的运营动作，也在进入 Codex 的产品和客户端接口层。
我会把今天的模式记成第六个强信号：事故补偿 × reset bank 联动。以后只要 Codex 出现大面积容量事故，接下来 12-24 小时内不只要看有没有即时 reset，也要看 Tibo 会不会再塞一枚 banked reset。
目前没有看到的新信号
截至本轮巡检，@OpenAIDevs 的最新 Codex 相关内容仍以欧洲功能扩围、社区活动和转发为主，没有新的 Codex Thursday 额度公告；@OpenAI 也没有在 double reset 之后单独补发官方额度帖。@sama 今天的新帖集中在 Noam 加入 OpenAI 相关话题，没有直接提到 Codex rate limit。以上判断来自本轮对 @thsottiaux、@OpenAIDevs、@OpenAI、@sama 四个账号时间线的复查。
所以本期结论很窄：已经触发的是 double reset，不是新的模型发布，也不是另一次独立额度机制升级。 对开发者，今天最稳妥的做法是把即时恢复的额度用在已经计划好的重任务上，把 banked reset 留到下一次真正需要抢窗口的时候。
このコンテンツについて、さらに観点や背景を補足しましょう。