首页 · 事件记录

重置事件记录

共 65 条。每条记录都必须能回答同一个问题：它推不推进重置时钟——如果不能，它就不该被算进「重置间隔」。

事件分类学

这张表比任何单条事件都重要。只要「不是重置」的动态被混进重置时钟，全站的推断就都废了。

类型	定义	是否计入重置	需要什么证据
已验证重置	额度或窗口确实被重置，或重置卡确实发放。	计入重置	官方公告、官方状态页，或可复现的用户侧证据三者之一。仅有传闻或第三方截图不算。
预告重置	官方明确宣告「即将」重置，但动作尚未执行。	不计入重置	官方公告中出现将来时表述（will / landing / by midnight / in the next hour 等），且无「已完成」表述。
提额	额度上限被提高，但窗口没有重置。	不计入重置	官方公告或客户端页面变化。
存储重置	云端容器、会话状态或工作区存储被清空重建，与额度无关。	不计入重置	官方状态页或官方文档说明。
非重置动态	看起来像重置、但已确认不是：储备重置、区域性补偿、误报、被大量转发的传闻、伪造截图。	不计入重置	官方否认、官方口径矛盾，或当事人撤回。
规则变更	窗口长度、计入口径、额度上限的规则发生书面变更。	不计入重置	官方文档前后差异，需保留变更前与变更后的原文。
服务事故	服务中断、容量事故等。通常是补偿性重置的前置条件，本身不是重置。	不计入重置	官方状态页事故记录。

为什么必须显式记录「不是重置」

事件分类学。这张表比任何单条事件都重要：只要「不是重置」的动态被混进重置时钟，全站的推断就废了。所以每一类都必须能回答同一个问题——它推不推进重置时钟（countsAsReset）。

下面这几条是看起来像重置、但明确不是的动态。它们被单独拎出来，就是因为一旦混进上面的主表，重置时钟立刻失真：

预告重置宣布全付费订阅全球重置（太平洋时间晚 6 点）
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
提额用量效率优化（非重置）
最容易和重置混淆的一类。用户看到「额度变多了」会当成重置，但你的窗口起点没有被重置，等待时间并没有缩短。
非重置动态（弱证据，不计入时钟）回复中的一句感叹
显式记录噪音比罗列信号更能建立信任。一条被标为「不是重置」的动态，价值等于十条被误当成重置的动态被拦下来。
预告重置 Astra 提前上线：宣布当日完成全量重置
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
预告重置部分档位未获 Astra 访问的重置卡补偿
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
预告重置 Astra 未上线期间按天发放重置卡
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
非重置动态（弱证据，不计入时钟）回复中的一句提及
显式记录噪音比罗列信号更能建立信任。一条被标为「不是重置」的动态，价值等于十条被误当成重置的动态被拦下来。
预告重置宣布重置卡发放时点（太平洋时间晚 8 点）
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
预告重置 2000 万周活：宣布向全员发放重置卡
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
预告重置 1000 万周活里程碑：宣布重置
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
预告重置宣布第二次重置（30 分钟内落地）
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
预告重置宣布全量重置（账户数小时后可见）
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
预告重置事故缓解，宣布重置将至
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
预告重置宣布即将重置（故障已稳定）
把预告当成已发生的事件计入，会让重置间隔统计整体偏短。时钟应从实际落地那一刻起算，不是从公告起算。这是本站与上游的一处明确分歧。
提额上线 mini 模型并上调 50% 额度上限
最容易和重置混淆的一类。用户看到「额度变多了」会当成重置，但你的窗口起点没有被重置，等待时间并没有缩短。
提额示例：周额度上限上调
最容易和重置混淆的一类。用户看到「额度变多了」会当成重置，但你的窗口起点没有被重置，等待时间并没有缩短。
存储重置示例：云端任务存储重置
名字里带 reset，实际动的是存储不是额度。混进来会把重置频率算高。
非重置动态示例：被大量转发的「储备重置」传闻，经核实不是重置
显式记录噪音比罗列信号更能建立信任。一条被标为「不是重置」的动态，价值等于十条被误当成重置的动态被拦下来。
规则变更示例：窗口计入口径变更
不推进重置时钟，但会改变所有后续事件的解释方式，必须记录变更前→变更后。
服务事故示例：高峰期服务事故，随后发放补偿
补偿性重置几乎都伴随事故，但事故本身不推进重置时钟，只有真正发出的补偿才算。

已核实重置事件 · 45 条

日期	工具	类型	事件
2026-09-12	Codex	已验证重置	重置全部传播完成已证实承接 09-08 宣布的全球重置。全文为「Reset all propagated」。范围：全体。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-09-12	Codex	已验证重置	质量修复后的重置并预告当日第二次已证实触发条件：修复了三类质量问题（旧模型技能误触发、上下文管理实验导致提前停止、配置不当的引擎造成质量退化，约 4000-5000 用户受影响）。范围：全员，并预告当日午夜前还有一次重置。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-09-10	Codex	已验证重置	重置卡未生效的补发已证实触发条件：部分重置卡在 ChatGPT Work 与 Codex 中使用时未完全生效。范围：受影响时间窗口内使用过的所有用户，各补发一张并发送致歉邮件。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-09-08	Codex	已验证重置	全量重置已证实范围：全部用户。全文仅「All reset for everyone」。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-31	Codex	已验证重置	2500 万周活里程碑全量重置已证实触发条件：周活达 2500 万。范围：ChatGPT Work 与 Codex 全部付费订阅。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-24	Codex	已验证重置	重置已传播并修复用量问题已证实触发条件：前一日已识别的用量问题。范围：全体账户。官方称用户应能感觉到改善。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-22	Codex	已验证重置	重置卡已到账已证实承接 08-21 的发放承诺。全文为「重置卡已到账，再说一次，重置卡已到账」。范围：全体。到账的是可在桌面端或网页自行择时使用的重置卡。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-13	Codex	已验证重置	1500 万周活里程碑重置已证实触发条件：周活达 1500 万（官方称消息滞后了几天）。范围：全员，称一小时内落地。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-11	Codex	已验证重置	极其简短的重置确认已证实全文仅「Hi. It is done.」两句。该条独立看信息量极低，靠上下文才成立——收录它是因为时间点明确，但引用时不宜单独作为依据。范围：未明说，据上下文为全量。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-09	Codex	已验证重置	为新模型可用性重置全部付费档已证实触发条件：GPT-5.6 Sol 可在更多环境使用（含第三方命令行工具）。范围：ChatGPT Work 与 Codex 全部付费用户。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-01	Codex	已验证重置	为「高效的一周」与 10 万线程演示重置已证实触发条件：庆祝一周的效率提升，并让用户周末跑 10 万个线程。范围：Codex 与 ChatGPT Work。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-28	Codex	已验证重置	全付费档额度重置已证实触发条件：未说明。范围：ChatGPT Work 与 Codex 全付费档。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-26	Codex	已验证重置	近全球性宕机后的重置已证实触发条件：凌晨 2 点至 4 点发生近乎全球性的宕机。范围：Codex 与 ChatGPT Work 全量。官方原话「我们学习，我们重置」。这也是竞品自己统计到、唯一一次明确与事故关联的重置。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-18	Codex	已验证重置	周末全付费档重置已证实触发条件：未说明，官方称「又不小心来了一次」。范围：全部付费档。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-16	Codex	已验证重置	900 万周活里程碑重置已证实触发条件：周活达 900 万（官方自嘲被工程事务绊住了）。范围：Codex 与 ChatGPT Work 全量，称数分钟内回到 100% 周额度。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-15	Codex	已验证重置	800 万周活里程碑重置已证实触发条件：周活达 800 万。范围：全量。官方同时说明暂不启用 5 小时限流，以便用户测试新模型边界。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-14	Codex	已验证重置	700 万周活里程碑：向全员发重置卡已证实触发条件：周活达 700 万。范围：全体账户。发放的是可在桌面端或网页自行择时使用的重置卡。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-13	Codex	已验证重置	向 50 万用户补发重置卡已证实触发条件：不到 10% 的用户使用重置卡时未真正生效（持续 2 小时的窗口）。官方无法精确定位受影响用户，改为向该窗口内所有按过重置键的人补发一张卡作为兜底。范围：约 50 万用户。发放的是可自行择时使用的重置卡。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-11	Codex	已验证重置	同日两次重置中的第一次已证实触发条件：GPT-5.6 Sol 与 ChatGPT Work 发布后的多点回退问题（高算力档位消耗提示不足、桌面端改版、多代理工作流回退）。范围：全量。官方明确说当天会重置两次——同一天两条记录不要合并。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-10	Codex	已验证重置	全量重置（正在传播）已证实范围：ChatGPT Work 与 Codex。官方称传播需约一小时。措辞是「正在传播」，意味着动作已执行。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-06-30	Codex	已验证重置	公布用量消耗调查报告并再重置一次已证实触发条件：调查认定并非单一问题，而是若干小问题叠加（自动评审更主动、子代理重复触发、后台建议重复生成）。范围：全量。同一条里既描述了已完成的重置，也预告了下一小时内的第二次重置。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-06-29	Codex	已验证重置	硬重置：绕过已堆积的重置卡已证实触发条件：用量异常调查中。范围：全量。官方特别说明这是「硬重置」——部分用户已堆叠最多三张重置卡，硬重置与卡是两条独立路径。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-06-18	Codex	已验证重置	双重重置：窗口全量 + 存入重置卡已证实同时做两件事：当前窗口全量重置，并额外存入一张重置卡供用户自行择时使用。范围：全量。卡的部分属于 storage-reset，窗口部分才推进时钟。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-06-04	Codex	已验证重置	24 小时内三起小事故后的补偿重置已证实触发条件：24 小时内三次独立的小型事故，影响可靠性。范围：全部付费档。官方称「三次已经太多了」。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-05-31	Codex	已验证重置	恢复至 100% 周额度与小时额度已证实触发条件：未说明。范围：全部付费订阅。这条罕见地同时说明了周窗口与小时窗口都会回到满额。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-05-24	Codex	已验证重置	修复缓存命中率退化后的重置已证实触发条件：一次优化影响了长会话压缩时的缓存命中率，导致额度消耗加快，已回滚。范围：全部账户。这是典型的「先承认退化、再补偿」流程。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-05-17	Codex	已验证重置	全付费档额度重置已证实触发条件：未说明。范围：全部付费档。官方称「周末愉快」。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-04-28	Codex	已验证重置	为庆祝「好的一周」重置全部付费档已证实触发条件：无特定事故，纯粹为庆祝并推广 GPT-5.5。范围：全部付费档。注意这类「无缘由重置」占比不低，是预测模型失效的主要原因。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-04-17	Codex	已验证重置	一周年纪念重置已证实触发条件：Codex 一周年。官方措辞是「允许 Codex 重置自己的额度」——权限下放给了模型，但动作事实相同。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-04-10	Codex	已验证重置	$100 档上线当日的重置已证实触发条件：新档位发布，且前一日的重置承诺。范围：全量。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-04-08	Codex	已验证重置	300 万周活里程碑重置并公布递增规则已证实触发条件：周活从 200 万增至 300 万。范围：全量。官方同时确立规则：此后每新增 100 万用户重置一次，直至 1000 万。这条把随机的庆祝性重置变成了可预期的节奏。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-04-01	Codex	已验证重置	主动重置：原因未查清先给额度已证实触发条件：仪表盘显示触限用户增加，官方称「不完全理解原因」，因此谨慎决定对全部档位重置。范围：全档。这是「原因未知也重置」的最清晰案例。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-03-27	Codex	已验证重置	为配合插件发布的全量重置已证实触发条件：插件功能上线，且距上次重置已有一段时间。范围：全部档位。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-03-11	Codex	已验证重置	按下重置键已证实官方原话「Reset button pressed, should see it in a bit」。动作已执行，只是尚未传播到账户。与上一条（03-10 的预告）是同一次重置的两个阶段。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-03-08	Codex	已验证重置	证据不足但仍重置（谨慎性重置）已证实官方明确说「没有找到用量异常加速的广泛证据」，但报告足够多，仍对 Plus / Pro 重置。范围：Plus / Pro。这条的价值在于它证明了重置决策不完全依赖故障确认。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-03-05	Codex	已验证重置	修复 2 倍提额未生效的补偿重置已证实触发条件：2 倍促销提额对约 9% 的 Plus / Pro 用户未生效。范围：对受影响档位重置以补偿。官方沿用了自己的拼写习惯（reseting）。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-03-03	Codex	已验证重置	误拦截事故恢复后重置已证实触发条件：一个把正常请求误判为高风险网络攻击的缺陷，导致请求被拒，约 8 分钟修复。范围：全量。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2025-12-25	Codex	已验证重置	节日重置并临时翻倍额度已证实双重动作：重置窗口，且把额度上限临时提到 2 倍，有效期至 1 月 1 日。上限翻倍是临时的，到期会回落——这类时间盒必须单独记。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2025-12-20	Codex	已验证重置	用量计费系统重写后重置已证实触发条件：重写用量追踪与计费系统。范围：全量。官方称回填历史数据太费时，不如直接送额度。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2025-12-17	Codex	已验证重置	服务中断后的重置已证实触发条件：服务中断。范围：全量。官方原话是「有段时间没这么干了，但流程你们都熟」。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2025-12-03	Codex	已验证重置	为缓解用量异常而重置已证实触发条件：团队排查到用量计费问题。范围：Codex 全量，官方称约 10 分钟内传播完成。原因是「先重置止血、再修根因」。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2025-11-23	Codex	已验证重置	美国区高延迟后的补偿性重置已证实触发条件：美国境内及周边数小时的高延迟。范围：Codex 全量。补偿性重置不受固定周期约束——这是它无法被预测的根本原因。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2025-11-06	Codex	已验证重置	全球性宕机恢复后重置额度已证实触发条件：先是 45 分钟局部故障，随后升级为 30 分钟全球性宕机。范围：Codex 全量。这是「先修故障、再谈补偿」的标准流程。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2025-09-17	Codex	已验证重置	为 gpt-5-codex 全量重置额度已证实触发条件：上线初期扩容 GPU 造成服务变慢。范围：全部用户。官方同时承诺当周持续扩容以维持速度。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
示例	Codex	已验证重置	示例：容量事故后的补偿性重置未证实格式示例。补偿性重置的特征是发放必然伴随事故，且不按固定周期出现——这正是它无法被预测的原因。写真实条目时，detail 要写清「触发条件 → 实际发放范围」，这是被引用最多的一段文字。来源：待补充官方公告链接

其余动态 · 20 条

日期	工具	类型	事件
2026-09-08	Codex	预告重置	宣布全付费订阅全球重置（太平洋时间晚 6 点）已证实触发条件：未说明具体原因，推文以歌词起头。范围：全部付费订阅，承诺太平洋时间当晚 6 点前后落地。这是预告，落地见 09-12 的两条。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-09-07	Codex	提额	用量效率优化（非重置）已证实触发条件：针对 Astra 高算力用户的用量优化。官方称长尾场景下用量消耗最多可降至 4 分之一。这是等效额度增加，不是窗口重置——混进重置统计会污染间隔。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-09-05	Codex	非重置动态	（弱证据，不计入时钟）回复中的一句感叹已证实一手仅有「@lydiahallie Wow, huge, wonder why!」一句回复，与重置无直接关系。上游据上下文将其列为一次重置。本站不采信无法从一手文本独立判定的内容。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-09-05	Codex	预告重置	Astra 提前上线：宣布当日完成全量重置已证实触发条件：Astra 提前于计划上线。范围：Plus / Pro / Business 全部档位，当日结束前落地。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-09-05	Codex	预告重置	部分档位未获 Astra 访问的重置卡补偿已证实触发条件：部分 Plus 与 Business 用户当日无法访问 Astra。范围：受影响档位，当日结束前发放，并给出太平洋时间晚 8 点的注册截止线。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-09-04	Codex	预告重置	Astra 未上线期间按天发放重置卡已证实触发条件：付费用户无法使用 Astra。规则：每缺一天发一张重置卡，当日生效，首张约 3 小时后落地。这是补偿规则而非一次性事件——它会在 Astra 迟迟不上线时持续产生条目。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-26	Codex	非重置动态	（弱证据，不计入时钟）回复中的一句提及已证实一手仅有「@dtzy_88 Ah yeah, forgot to say」一句回复，独立无法验证是否发生重置。上游据上下文将其列为一次「安静的重置」。本站不采信无法从一手文本独立判定的内容。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-22	Codex	预告重置	宣布重置卡发放时点（太平洋时间晚 8 点）已证实范围：ChatGPT Work 与 Codex 全部付费用户。官方给出明确的时点承诺（8pm PST），这是少见的带精确时间的预告。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-08-21	Codex	预告重置	2000 万周活：宣布向全员发放重置卡已证实触发条件：周活达 2000 万。范围：全体 Codex 与 ChatGPT Work 用户。措辞是「今天内发放一张可自行择时使用的重置卡」——是卡不是窗口重置，且尚未发放。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-22	Codex	预告重置	1000 万周活里程碑：宣布重置已证实触发条件：周活达 1000 万，达成 04-07 公布的递增规则终点。范围：全部付费档。措辞为「一小时内落地」——是预告，尚未执行。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-07-11	Codex	预告重置	宣布第二次重置（30 分钟内落地）已证实范围：ChatGPT Work 与 Codex 全量。这是 07-10 所预告的第二次。与 07-10 那条配对，不能各算一次。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-06-27	Codex	预告重置	宣布全量重置（账户数小时后可见）已证实触发条件：用量消耗加速的调查仍在进行，官方称未发现大规模受影响用户。范围：Codex 全量。措辞是「正在发放」，账户可见需数小时。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-04-21	Codex	预告重置	事故缓解，宣布重置将至已证实触发条件：约 10 分钟的事故已缓解。范围：全量。官方原话「rate limit reset incoming」——是预告，尚未落地。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2026-03-10	Codex	预告重置	宣布即将重置（故障已稳定）已证实触发条件：Codex 故障已完全恢复并稳定数小时。官方称「稍后重置」。这是一条预告——重置时钟应从实际落地那一刻起算，不是从公告起算。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
2025-11-08	Codex	提额	上线 mini 模型并上调 50% 额度上限已证实两件事分开记：发布 gpt-5-codex-mini（用量降至 4 分之一），以及 Plus / Edu / Team 三档额度上限上调 50%。上限变高不等于窗口重置。来源：Tibo（OpenAI Codex 负责人）在 X 的公告
示例	Codex	提额	示例：周额度上限上调未证实格式示例。提额必须和重置分开记：上限变高不等于窗口重置，等待时间没有缩短。这条如果被混进重置时钟，会让「重置间隔」的统计整体偏短。来源：待补充官方文档链接
示例	Codex	存储重置	示例：云端任务存储重置未证实格式示例。名字里带 reset，但动的是容器存储不是额度。收录时必须写清「重置的是什么」，否则读者会误读。来源：待补充
示例	Codex	非重置动态	示例：被大量转发的「储备重置」传闻，经核实不是重置未证实格式示例。这类条目要写清三件事：为什么它看起来像重置、证据是什么、官方或当事人怎么说。显式记噪音比罗列信号更能建立信任。来源：待补充
示例	Claude Code	规则变更	示例：窗口计入口径变更未证实格式示例。规则变更必须写成「变更前 → 变更后」，并保留两边的原文。任何后续事件都要按新口径重新解释。来源：待补充官方文档链接
示例	ChatGPT	服务事故	示例：高峰期服务事故，随后发放补偿未证实格式示例。事故本身不推进重置时钟；只有真正发出的补偿才按 verified-reset 另记一条。两条互相引用。来源：待补充官方状态页记录

这些数字有多少依据

已核实重置事件

已确认待核实

已排除的非重置动态

独立来源

最近一次信号置信度

09/18 23:13

给开发者：数据出口

本站的事件记录可以自由引用，JSON 格式，带类型与出处：

https://resetradar.solemountain.cn/api/v1/timeline.json

包含事件类型学（哪些计入重置）、已核实事件、被排除的动态、以及本站当前的样本量与置信度。引用时请连同 evidence 字段一起引用——单独引用一个事件数字会误导读者。

重置那一刻，第一时间知道

免费通道：邮件、Telegram、Bark 推送、企业微信群机器人。我们不预测重置，只做确认。