Codex / Claude 重置概率怎么算的？

公式（climatology）

把该产品全部历史重置间隔（按日期去重，同一天多条公告只算一次）当作样本，未来 h 天（h = 1、2、7）内重置的概率：

P(未来 h 天内重置) = #{历史间隔 g : g ≤ h} ÷ 历史间隔总数

这个数字不看你已经等了多少天——不管现在等了 1 天还是 30 天，同一次构建里这三个百分比对所有访客都一样，只有下一次构建（新公告进来，样本更新）才会变。这与 GET /api/forecast 用的是完全同一套模型（forecast.py 的 climatology_prob()），只是这里多算了一个 7 天窗口给页面用。历史间隔（去重后）少于 5 个时显示「样本不足，暂不估算」——报一个精确到个位的百分比只会误导人。

预告（scheduled，尚未真正发生的重置）和指南文章都不进这个样本——只统计已经发生、被官方确认的重置公告。

历史间隔只算额度重置（regular），不算重置卡（banked）：重置卡是官方发放、需要你自己在设置里手动使用才生效、不会自动清零额度的一次性权益，不代表「多久重置一次」的节奏。历史间隔样本、下面表格的数字，以及产品页/首页的「典型间隔」「参考日」，统一只用额度重置这一份样本。

当前样本量与概率

以上是本页最近一次构建时算出的真实数字，随新的重置公告更新，不随访问时刻变化（climatology 不按已等待天数条件化，所以没有「按当前日期重算」这一步）。实时、带小数位、可编程访问的同一套数字见 API 文档的 GET /api/forecast。

为什么不按「已经等了多少天」调整？

本站以前用的是另一种算法（stats.reset_probabilities()）：按「已经等待的天数」条件化——分母是历史上比现在等得更久的间隔个数，分子是这些间隔里又在目标天数内重置了的个数。听起来更合理（等得越久应该越快到），但公开回测（重置概率回测，真实历史、逐步前推、从不用到未来数据）证明它反而更不准——同一批检查点上，Brier 分数（越低越准）：

两个窗口，旧算法都更差（对比只算在旧算法真正给出数字、没有弃权的那部分检查点上，公平比较——完整数据见 重置概率回测）。所以 2026-09-23 起，首页/产品页改用不按等待天数调整的这个版本；旧算法（stats.reset_probabilities()）本身没有删除，仍作为回测里的候选之一留着对照，只是不再驱动页面展示。

到账时间怎么推算

宣布重置和额度真正到账不是同一件事：预告里写的时刻是“什么时候开始重置”，到账可能按套餐分批进行。本站对预告时间和到账状态只按下面这几条规则处理，不做到账时长的估算，也不给任何到账比例。

预告时间怎么写

• 原帖写了具体时刻（例如 “10am PT”）：按原话换算，页面统一写成「太平洋时间 … （PDT/PST） ／ 北京时间 …」，两地并写，24 小时制。PDT 还是 PST 按那一天的日期由时区库（America/Los_Angeles）自动判断，不照抄原文字面写的缩写——原文写 PST 但那天实际处于夏令时，我们仍显示 PDT。
• 原帖只写了日期，或只说 “by EOD”（当天结束前）这类说法：不替原帖编具体时刻，只写日期（按上游记录的日期和时区标签），并标「具体时刻待定」。

三种状态

• 只有“明确宣布”且带具体时刻的预告才会进入第二种状态。口头暗示（页面上写“可能重置”）没有可依据的时刻，不参与这个判断。
• “应已生效”只是按预告时刻做的时间推算，不是到账确认；确认以上游记录的 delivered_at 为准，没有这个字段就一直停在第二种状态，不会自己升级。
• 这个状态由浏览器按你访问时的时间切换，所以站点不用重新构建，过了预告时刻刷新页面就会看到变化；没有 JS 时按页面构建时的时间显示。
• 分批到账时你的账号可能还没恢复，请以自己账号里显示的额度和重置时间为准。

局限性

• 样本量小：目前每个产品能用的历史间隔数量有限，数字会随样本量抖动，间隔数少的产品更不稳定。
• 官方节奏会变：重置政策、发布节奏、故障处理方式都可能在没有任何预告的情况下改变，历史频率不代表未来会一样。
• 重置常和发布/故障相关，不是纯随机事件：新模型上线、故障恢复、里程碑庆祝都会触发额外重置，这些原因不会体现在纯粹的天数统计里。
• 预告不进样本：官方已经预告但还没真正发生的重置，不计入这里的历史间隔。

这不是预测模型，只是历史频率的经验统计。两家官方都从未承诺过重置节奏，请只当作参考，不要当作时间表。