Codex 重置概率回测：24 小时 / 48 小时，走查真实历史

方法

• 检查点：每天 00:00、06:00、12:00、18:00 UTC 四个时刻，与上述第三方基准一致。
• 目标事件：全员硬重置（含 global 与 global_paid 两种覆盖范围），不含储备重置（banked）、个人滚动窗口恢复——对应本站 event_kind() == "regular"，与该基准「qualifying public reset event」定义等价。
• 只用检查点之前已知的信息：从第 6 个历史事件之后开始（这样至少有 5 个完整间隔），每个检查点只用「该时刻之前」发生的事件建模，逐步前推模拟到今天，从不用到未来数据。
• 时间戳近似：真实数据里 0/61 条「regular」事件只记录了日期、没有具体时刻，这些事件用「当天 12:00 UTC」代替真实发生时刻。这意味着已等待天数和窗口是否命中，在这些事件附近可能有最多约 12 小时的误差——这是数据本身的限制，不是算法的限制，如实写在这里。
• 只回测 Codex：Claude 历史事件数太少（历史间隔仅个位数），回测结论对它意义不大；/api/forecast?product=claude 仍会输出概率，但不附带经过验证的 Brier 分数。

候选模型与全部结果（不藏差的）

下表是 1282 个可结算的历史检查点（2026-11-06 为止）上，每个候选模型的表现。「弃权」的模型（会员本站现有算法就是这一种）只在给出数字时才计入分数，覆盖率单独列出；其余模型从不弃权。

24h 窗口（1282 个可结算检查点）

48h 窗口（1278 个可结算检查点）

发布模型与理由

24h：发布模型是 empirical_shrunk_a10（Brier 0.1368）。 这是我们尝试的模型里，全样本 Brier 优于或等于 climatology 基线（0.1382）中最低的一个。

48h：发布模型是 empirical_shrunk_a10（Brier 0.2035）。 这是我们尝试的模型里，全样本 Brier 优于或等于 climatology 基线（0.2038）中最低的一个。

这和这次任务背景里提到的现象一致：至少有一个同类站点的「更复杂」模型（越等越该到、加暗示帖权重）实测比「每次都报一个历史平均概率」的基线还差。基线不容易打败，不代表基线就是真相，只代表这几种更复杂的写法在这份数据上没有帮上忙。

站内首页/产品页的重置概率行自 2026-09-23 起也改用该发布模型（climatology）——本页选出的模型不只是用在 /api/forecast 上，也是首页/产品页「24 小时内/48 小时内/7 天内」三个百分比的唯一来源，不再使用按已等待天数条件化的旧算法，详见 重置概率算法说明。

局限

• 样本量小：Codex 历史「regular」事件只有 1282 个可结算的 24h 检查点，48h 略少；换一段更长的历史，结论可能不同。
• 官方节奏会变：两家官方都从未承诺过重置节奏，历史频率不代表未来会一样。
• 重置常和发布/故障相关，不是纯随机事件：新模型上线、故障恢复、里程碑庆祝都会触发额外重置，这类原因不会体现在纯粹的时间间隔统计里。
• 时间戳近似（见上方「方法」）会在数据边界附近引入误差。
• 这是实验性估算，不是预测；两家官方从未承诺过重置节奏。

实时接口

GET /api/forecast（默认 Codex）与 GET /api/forecast?product=claude 用同一套发布模型，按请求时刻实时计算，返回字段：

• probabilities.raw_24h / raw_48h：0–1 之间的概率（fraction）。
• hours_since_last：距上一次「regular」重置已经过去多少小时。
• sample_n：用来估算的历史间隔个数。
• backtest：本页回测结果的精简版（仅 Codex；brier_24h/brier_48h/climatology_brier_24h/climatology_brier_48h/cases/as_of），由构建期写入，不在每次请求时重新跑回测。
• method_url：指回本页。

CORS 开放（Access-Control-Allow-Origin: *），无需密钥，响应带 X-Robots-Tag: noindex（数据接口本身不参与搜索收录，本页参与）。字段详情、curl/Python/JS 示例见 /api/ 文档页。