日志
Codex Reset：追踪 Codex 额度重置、时间线与实时预测的独立工具
||
如果你在 Codex 里遇到额度用完，最想知道的通常不是“有没有人讨论过”，而是：我自己的窗口什么时候恢复？最近有没有公开的全局重置？眼前的异常是额度问题，还是服务事故？这三个问题的答案并不在同一个地方。
我在 2026 年 7 月 29 日 读取了 Codex Reset 的英文首页、中文入口、时间线、雷达、条款、隐私页和公开 API。先说结论：它是一个面向 Codex 社区的独立追踪器，把个人倒计时、公开重置记录、服务状态和预测信号放在一起；它不是 OpenAI 官方产品，也没有权限读取你的真实额度。真正的个人额度仍应以 Codex 客户端的 /status、IDE 扩展或 ChatGPT 自己显示的结果为准。
它解决的不是一个“全局重置时间”问题很多人把“我的额度何时恢复”和“大家有没有获得一次官方重置”当成同一件事。实际上，个人使用窗口、OpenAI 服务事故、社区公开的 goodwill reset，以及网站对下一次信号的预测，属于不同证据层。
Codex Reset 的设计价值就在这里：你可以把自己的精确 reset 时间和使用率放入本地 tracker，同时在另一个区域查看公开事件和信号来源。这样做比把某个帖子里的时间当成所有账户的统一答案更稳妥，也比只看一条模糊的“快了”传言更容易复核。
个人 tracker：先从 /status 复制真实输入首页的个人部分不会自动读取你的 Codex 账户。站点要求你从 Codex 客户端的 /status 输出中复制精确的 reset 时间，再填入页面；使用率也需要根据 /status 自己滑入。之后，页面可以按你的输入估算消耗速度，显示 weekly window 是否可能撑到下一次重置。
这条边界非常重要：计时器做的是本地计算，不是账户查询。输入错一个时区、把预告时间当成实际生效时间，或者把别人的 reset 当成自己的窗口，倒计时都可能看起来很准确却没有意义。网站条款也明确写着，它无法看到你的真实 quota，计时器完全依赖你输入的时间。
除了 weekly window，页面还提供 banked reset 的记录入口、可选浏览器通知、日历导出、复制状态和清除本地数据等操作。隐私页说明，这些计时和个人设置保存在浏览器的 localStorage 中；没有账号时，换浏览器或清除站点数据就不会保留原来的个人计时。
Timeline：把公告、预告和实际生效分开想知道“过去到底发生过什么”，可以看 Codex Reset Timeline。它不只是按日期列标题，而是把事件来源、公告时间、可能的 effective time、confidence 和 preview 状态放在一起。
这套标记解决了一个常见误读：有人发帖说“接下来一小时会重置”，不等于每个账户已经在同一秒恢复。Timeline 的说明是，预告窗口会保留为 preview，只有后来有独立证据确认实际到达，才会记录成 effective；不能因为时间过去了，就自动把预测补写成事实。
对需要写日志、做自己的提醒脚本或回看历史的人来说，这个区分比一张看似整齐的日期表更有用。你可以先看 source link，再决定这条记录适合当作已发生事件、预告，还是仍需等待验证。
Radar 与 forecast：三个信号轨道，不是一个官方分数在 Codex Radar 中，站点把信号拆成三条彼此独立的轨道：
- 模型配置/运行时观测，例如 Codex Juice 页面和 /api/juice；
- OpenAI 官方服务健康，链接到 status.openai.com；
- 公开 reset、额度和限制信号，主要来自公开帖子与已核验事件。
页面明确提醒，这些是 evidence streams，不是把模型、服务和重置揉成一个“能力分数”。这点值得保留，因为服务状态正常，不代表你的个人 weekly window 已经恢复；社区出现 reset 帖子，也不代表某个账户一定在同一时间看到变化。
首页的 forecast 会展示未来 24–48 小时的概率、历史高发时段和模型置信度。它适合回答“现在有没有必要留意”，不适合回答“我几点一定恢复”。预测使用的是站点自己的跟踪模型，置信度也可能随着样本和新事件变化。尤其是 Codex Juice 的说明已经写清楚：它是社区观察到的运行时预算指纹，不是 OpenAI 的能力评分，也不是实际 reasoning token 用量；当前接口不可用时，更不能补写一个看似精确的数字。
中文入口和公开 API，适合回看与轻量自动化如果你习惯中文界面，可以直接打开 https://codex-reset.com/zh/。首页、时间线和雷达都有对应的中文路由，核心字段仍保持同一套来源和限制。
站点还公开了 /api/forecast、/api/timeline、/api/status-history、/api/feed、/api/juice 等 JSON 入口。它们适合做个人状态栏、简单的历史导出或二次提醒，但使用时要保留 updated_at、source、confidence 和 preview 等字段，不能只取一条 summary 就把它当成官方事实。API 是公开数据面，不是个人账户 API，也不会告诉你自己的真实剩余额度。
隐私边界：本地计时与服务器处理是两件事根据 Codex Reset 隐私政策，站点没有注册账号，也不设置广告或跨站 Cookie；Cloudflare Web Analytics 被描述为无 Cookie 的聚合测量。个人 reset 时间、通知偏好和计时状态留在浏览器，不会因为打开 tracker 就上传给站点。
但这不代表服务器完全看不到请求元数据。站点运行在 Cloudflare Workers 上，Cloudflare 会处理标准的 IP、User-Agent 等请求信息来提供和保护服务。另一个可选功能 /api/pray 为了限制每个 reset cycle 的提交次数，会保存最长 45 天的加盐单向 IP 哈希；隐��页说明原始 IP 不会写入应用记录、响应或公开页面。接受的祈愿还可能公开生成的化名、序号和粗粒度地点，因此如果只想使用计时器，可以不参与这类公共互动。
浏览器通知同样是可选功能，而且只在页面保持打开时触发；它不是一个后台账号推送服务。对隐私或持续提醒有要求的人，应该把这些边界和自己的浏览器权限一起考虑。
我建议按这个顺序使用- 先在 Codex 客户端运行 /status，确认你自己的 reset 时间、时区和使用率。
- 打开 Codex Reset 首页，只填入自己的数据，不要拿公开帖子的预告时间替代个人输入。
- 用 tracker 做个人倒计时、weekly/banked reset 记录，需要时再启用通知或日历导出。
- 遇到“大家是不是都重置了”的消息，去 Timeline 看 source、preview 和 confidence，再打开 Radar 对照服务状态和其他信号。
- 真正判断账户是否恢复时，回到 Codex /status 或客户端本身；不要用 forecast 概率替代账户事实。
它适合经常使用 Codex、需要一个浏览器内个人倒计时、希望回看公开 reset 记录，或想把社区信号整理进自己工作流的人。中文路由和公开 API 也让非英文用户、轻量自动化用户更容易开始。
它不适合被当作 OpenAI 官方额度查询器、服务 SLA、账户申诉凭证或保证重置时间的工具。如果你是在排查当前服务故障，应该优先看 OpenAI 官方状态页和客户端错误；如果你只想知道自己的额度，/status 已经是更直接的来源。
入口与结论一句话总结：Codex Reset 最有用的地方，是把个人 /status 输入、公开 reset 历史、服务状态和社区预测分成不同层级，再放到一个能持续回看的界面里。把它当作提醒器、资料索引和信号面板很合适；把它当作能读取真实额度或替 OpenAI 做保证的官方工具，就超出了它自己声明的边界。
