英文版首发于 DEV。
声明：Codex Reset（codex-reset.com/zh）是我们做的。这篇用公开数据演示一次可复现的分析，同时说明算出来的数字能回答什么、不能回答什么。
想研究 Codex 多久重置一次，第一步不该是画图，而是确定每一行代表什么。
“预测未来可能重置”“已经发生一次重置”“账号收到一份以后可以用的存储重置”，不是同一种事件。如果直接把所有记录按时间排序，再计算相邻两行的间隔，程序可以正常运行，结果却未必是你想研究的“重置间隔”。
上一篇讲了网站首页的预测。这一篇换个问题：拿到原始记录之后，怎么保存输入、区分事件、做一个别人也能复算的统计，再决定哪里需要实时 API 或 MCP。
先决定你需要历史记录，还是当前状态
| 想回答的问题 | 入口 | 一起保存什么 |
|---|---|---|
| 历史档案里有多少次重置？ | /data/codex-resets.json 或 CSV | 原始文件、获取时间、来源 |
| 现在的预测是多少？ | /api/forecast | 更新时间、置信度，以及“预测”这个标签 |
| 让 Agent 查最近的证据？ | /mcp | 工具名、返回的时间和来源链接 |
这些接口不需要 API Key。开发者页面有当前说明。它只有英文版，不要把地址改成不存在的 /zh/developers。
历史研究可以先从导出的 JSON 开始。它只保留事件记录，而实时 timeline API 还包含背景信息；两者的行数和字段不能直接互换。
2026 年 11 月 6 日截图。开发者页面目前只有英文版。
先下载一份，不要每算一步都重新请求
在一个空目录里运行：
curl -fsS https://codex-reset.com/data/codex-resets.json \
-A 'reset-history-example/1.0 (+https://codex-reset.com/)' \
-o codex-resets.json
示例的 User-Agent 标明了项目。你做自己的集成时，换成自己的项目名和联系地址。
保存文件的意义在于固定输入。实时档案可能新增记录，也可能修正旧记录；如果昨天的计算只剩下一张图，没有当时的数据文件，今天就很难解释数字为什么变了。
这次使用的文件更新时间是 2026-11-06T07:21:49.669Z。其中有 71 条事件：59 次重置，12 次存储重置发放。最早记录是 2025 年 9 月 17 日，最新一条是 2026 年 11 月 1 日的存储重置发放。这些是这份快照的数字，不能当成永久总数。
Data Package描述了八个字段，分析前尤其要看清三个：
event_id是字符串。导入表格也保持文本类型，不要让长 ID 变成精度丢失的数字。type区分reset和banked。同一篇帖子如果同时宣布重置和发放存储重置，会贡献两个不同 ID 的事件。只按来源链接去重，会把两件事合并掉。source区分post和observed。后者来自我们自己的监测账号，没有公开帖时，post_url可以为空。不要把空链接补成某个“可能相关”的帖子。
banked_state 保存 announced、arriving、available 等状态。它说明发放记录的状态，不代表用户已经兑换了这份存储重置。
用标准库复算一次
把下面代码保存成 analyze.py，放在 JSON 旁边，运行 python3 analyze.py。不需要安装第三方 Python 包。
import hashlib
import json
from collections import Counter
from datetime import datetime
from pathlib import Path
from statistics import median
raw = Path("codex-resets.json").read_bytes()
data = json.loads(raw)
events = data["events"]
ids = [event["event_id"] for event in events]
assert all(isinstance(value, str) for value in ids)
assert len(ids) == len(set(ids)), "Duplicate event IDs"
resets = [event for event in events if event["type"] == "reset"]
times = sorted(
datetime.fromisoformat(event["announced_at"].replace("Z", "+00:00"))
for event in resets
)
gaps = [(b - a).total_seconds() / 86400 for a, b in zip(times, times[1:])]
print("sha256:", hashlib.sha256(raw).hexdigest())
print("updated_at:", data["updated_at"])
print("events:", len(events))
print("types:", dict(Counter(event["type"] for event in events)))
print("sources:", dict(Counter(event["source"] for event in events)))
print("completed intervals:", len(gaps))
if gaps:
print("median historical gap (days):", round(median(gaps), 2))
这次快照的统计输出为：
events: 71
types: {'reset': 59, 'banked': 12}
sources: {'post': 68, 'observed': 3}
completed intervals: 58
median historical gap (days): 3.56
程序还会打印文件的 SHA-256 和更新时间。公开统计时，把它们与结果一起保存，别人才能确定你用了哪一份输入。
代码先筛选 reset，再解析 UTC 时间、排序并计算间隔。59 个时间点之间有 58 个已完成间隔，算出的历史间隔中位数是 3.56 天。存储重置发放不会插入这组间隔，文件原本的排序方式也不会改变结果。
但 3.56 天不是“下一次重置还要等多久”。最后一次重置之后仍在继续的等待，没有进入这组已完成间隔。这段代码只是描述历史记录，并没有复现网站的预测模型。
时间的含义也不能省略。时间线的方法说明交代了公告与确认时间的语境。一条记录的时间，不等于所有账号收到补充额度的精确时间；你根据它算出的统计，同样带着这层限制。
2026 年 11 月 6 日英文时间线的数据说明截图。读字段之前，也要读纳入规则与修订说明。
要问“现在”，再查实时 API
保存的历史文件不能回答此刻的预测。这个问题单独查：
curl -fsS https://codex-reset.com/api/forecast \
-A 'reset-history-example/1.0 (+https://codex-reset.com/)' \
-D forecast-headers.txt \
| jq '{updated_at, confidence, last_reset_at,
p24: .probabilities.rounded_24h,
p48: .probabilities.rounded_48h}'
这段需要 curl 和 jq。展示百分比时，把 updated_at 和 confidence 一起带上，不要只留下一个看似精确的数字。
HTTP 200 只说明请求成功，不保证底层记录新到足以支持你的用途。示例把响应头另存为 forecast-headers.txt，其中 x-published-checked-at、x-published-expires-at 可以帮助判断已发布副本的新鲜程度。
开发者说明要求最多每分钟查询一次，遇到 429 则遵守 Retry-After。这次实测预测接口的缓存时间是 60 秒，服务状态历史是 300 秒；在缓存周期里不停重试，不会得到更多新证据。
别把导出文件的筛选条件原样复制到实时 timeline API。导出文件看 type；实时接口说明中的重置条件是 group == "reset" 且 announcement_state == "announced"。/api/feed 回答公告流与新鲜度的问题，/api/status-history 回答服务健康问题，都不是你的个人剩余额度。
给 Agent 一个带证据的问题
MCP 有三个只读工具：get_reset_forecast、get_reset_timeline、get_codex_status。与其让 Agent 猜“我是不是满血了”，不如让它返回最近的重置记录、时间和来源链接。
下面是针对这个服务器实测过的调用，取最近两条重置：
curl -fsS https://codex-reset.com/mcp \
-A 'reset-history-example/1.0 (+https://codex-reset.com/)' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_reset_timeline","arguments":{"group":"reset","limit":2}}}' \
| jq '.result.content[] | select(.type == "text") | .text | fromjson
| {returned, events: [.events[] | {announced_at, url}]}'
这个响应把 JSON 放在文本内容块中，因此示例先取 .text，用 fromjson 解析一次，再提取时间与链接。核对时返回的是 2026 年 10 月 28 日和 10 月 26 日的记录。
它做的是读取公开记录。调用这个工具不会兑换存储重置，也不会修改任何账号的用量。
实时源和归档快照，各有用途
Hugging Face 数据卡写明，它保存的是 2026 年 10 月 12 日快照，共 62 条事件，并非自动更新的镜像。要研究最新历史，用网站当前导出；要让一个结果长期可复算，就保留实际使用的文件。Data Package 中的资源地址可能仍指向实时 CSV，不能只存说明文件。
数据集采用 CC BY 4.0。复用时保留来源，在展示结果的位置署名，并说明做过的变换。例如：
仅统计 reset 记录；计算已完成的记录时间间隔中位数；数据获取于 2026 年 11 月 6 日。Data: codex-reset.com。
这份档案能支持一个范围明确、别人可以复核的结论：你数了哪些记录、采用哪些时间、怎么得到结果。它无法证明每个用户都收到了重置，无法读取你的个人额度，也不能凭历史间隔确定下一次重置时间。
Codex Reset 是独立社区项目，与 OpenAI 无关联。“Codex”是 OpenAI 的商标。
