当 Tibo 的公开重置帖开始出现在时间线上，用户通常有几个小时，偶尔更久，决定要不要把当前剩余额度跑掉。等到“重置完成”的消息出现，这一轮窗口就结束了。
多数人看见的是两条容易错过的动态。CodexRadar 把它做成了一张状态卡：有没有窗口，窗口从何时开始，最近一次持续多久，历史上发生过什么。它把这段时间叫作“速蹬窗口”。
上图是本次收录的实际产品界面截图，截图中可见的更新时间为 7 月 22 日和 7 月 23 日，不能当作当前实时读数。它让这个产品的范围更完整：上半部分的重置雷达判断一次事件是否已经落地，下面的额度雷达把不同档位的七日额度估算与变化趋势并列出来。
一条消息怎样变成一个产品
这个产品的动作很克制。
- 监看 Codex 相关公开账号的动态；
- 用 reset、rate limit、usage limit 等词筛出候选消息；
- 判断它说的是预告、执行还是完成；
- 把同一轮活动整理为一次事件；
- 输出网页、`current.json` 和 RSS。
CodexRadar 的公开雷达页面也把重置卡提醒、额度观察与社区跑测放在同一处。产品作者在介绍里强调，网页给人看，JSON 和 RSS 留给 Agent、订阅器和提醒工具。这个设计很像一个很小的事件基础设施：人类看第一张卡片决定要不要行动，程序读状态文件决定要不要提醒。
它没有替用户决定该跑什么任务。它只把一个模糊问题改写得更具体：现在的额度，是否值得立刻找任务用掉？
我们为什么会在意这段空档
研究所此前写过一篇《每次额度重置，我都后悔自己上周没多用》。它从平台一侧讨论额度重置：固定订阅价格对应动态工作负载，平台会在用户体验、模型推广、容量与真实需求之间调整供给。
用户看到的是另一件事。
当额度随时可能被重置，节省下来的用量会产生一种很奇怪的反事实损失感。人会回想昨天本来可以交给 Agent 的任务，接着开始为下一次窗口留任务、切换模型、计算是否值得购买额外 credits。工作安排被一串剩余额度改变了。
CodexRadar 让这个用户侧行为变得可见。它记录的不是 OpenAI 的内部面板。它记录公开预告何时出现，以及用户何时开始把它当成行动信号。
社区给出的几种解释
围绕额度重置，社区已经形成了很多解释：滚动窗口会怎样移动，短周期限制移除后重度用户会不会更快碰到周额度，突然重置会不会放大“未用即浪费”的压力，轻度用户和重度用户在订阅制下承担怎样不同的成本。
这些说法里有公开可观察的体验，也有大量推断。它们可以帮助提出问题，不能替代平台内部数据。
我们看不到 OpenAI 的账户余额、负载、补贴预算和决策流程。任何关于“这次重置精确节省了多少成本”或“平台刻意用它塑造哪种心理”的结论，都需要更强的证据。
雷达产品的边界
这类产品在预告已经公开时最有用。它替人持续盯住分散的信息源，减少错过窗口的概率。
它无法凭空知道下一次重置何时发生。
未来若加入“重置日期预测”，页面应该同时给出样本量、最近验证、使用的信号、历史命中率和失效条件。一个孤立的百分比很容易制造超过证据本身的确定感。
这也是 CodexRadar 最有意思的地方。它先拿一个很窄的问题做出行动价值，再把它扩展成用户共同维护的额度、质量和活动观察站。平台把额度做成一套规则，用户把规则做成了一块民间仪表盘。