如何理解 Codex 重置预测

预测是规划信号，不是时间表

Codex Reset 的预测只回答一个有限问题：根据已经审查的公开历史，未来 24 小时或 48 小时内出现公开重置的可能性有多高？ 它不会告诉你个人账号什么时候重置，也不表示 OpenAI 已经发布了固定日程。

这个区别很重要，因为公开事件和个人账号窗口可能并不是同一件事。你自己的 Codex /status 页面仍然是查看账号专属时间的权威位置。预测适合用来了解更广泛的公开动态，尤其是在多条公开报告时间接近时。

四个信号要一起看

1. 最近一次已确认重置

先看标记为“已确认”的最近事件时间。注意它使用的时区，来源可用时打开原始内容，并确认事件说的是全局重置还是较小范围的观察。事件距今多久只是估计的一个输入；过去很久没有事件，也不代表下一次一定已经到期。

2. 24 小时和 48 小时概率

两个百分比代表不同时间窗口。48 小时数值可能更高，因为它包含更长时间，但它们都不是倒计时。例如 65% 表示在模型假设下，近期结果更有可能发生；不表示事件已经排定，也不表示 65% 的账号都会获得重置。

数值会经过取整并限制范围。取整让结果更易读，限制范围可以避免少量数据制造虚假的确定感。因此，百分比应当被理解为宽泛的规划参考，而不是精确到分钟的测量。

3. 置信度

置信度说明可用的已审查历史有多少，以及这些历史对估计的支持程度。一个看起来很高的百分比，如果置信度很低，仍然属于弱证据；一个较低但有完整历史记录的数值，可能更适合谨慎安排工作。

置信度也不是准确率承诺。公开公告是不完整的观察：用户可能晚些时候才注意到变化，可能用相同词语描述不同限额，也可能没有留下来源。保留标签，是为了让这些局限始终可见。

4. 常见活跃时段

常见活跃时段总结历史事件最常出现的 UTC 时段。它可以帮助观察和安排，但不会创造一个发布窗口。运营变化可能发生在历史节奏之外，公开公告也可能晚于系统实际变化。

为什么使用近期历史

追踪器使用最近的已确认间隔，而不是把整个历史归档视为同样新鲜。产品行为发生变化时，近期观察更有参考价值；较早事件仍可以提供背景。方法会比较最近一次确认事件后的经过时间与近期中位间隔，再换算出 24 小时和 48 小时估计。

这个方法刻意保持克制。它不会假设自己知道隐藏容量、账号用量、内部运营安排或未来规则变化，也不会把社区需求当成重置已经发生的证据。需求可以说明很多人在等待，却不能验证系统事件。

三个负责任的解读例子

概率高、置信度低： 保留替代方案。近期节奏提示事件可能很快出现，但证据数量较少或不均匀。

概率低、刚发生过确认重置： 不要认为下一次已经逾期。最近事件可能让短时间内再次发生的可能性下降。

只有预告、没有确认： 继续观察来源，等待匹配证据。不要把预告描述为已经完成的重置，也不要据此断言自己的账号应该已经恢复。

一个安全的使用顺序

1. 如果问题针对自己的账号，先查看 /status。
2. 打开最近一次已确认事件，阅读来源与影响范围。
3. 把 24/48 小时估计与置信度一起看。
4. 查看历史页，比较当前间隔是否接近近期间隔。
5. 如果等待成本很高，拆分重要工作或准备另一条路径。
6. 做出更强结论前，再次核对账号状态和公开证据。

数据字段和验证规则见追踪方法论，完整公开事件见Codex 重置历史。