Reset Observatory额度重置专题 / 01
Codex 的 banked reset，现在该用吗？
本文目录
决定是否使用重置，核心看两件事：眼下的工作是否已被限额卡死，以及此时重置会如何改变下一次的周期刷新。现在把额度回满确实能解燃眉之急，但这绝不意味着到本期订阅结束时，你一定能多拿出一整周的可用总量。能不能等，取决于等待期间你会耽误多少关键工作，而不能只看当前余额能多跳几个百分点。
先确认：你拿到的究竟是哪一种重置？
并非所有“重置”都遵循同一套时间表。在做决定前，先明确你手头配额的性质：
- 已入账的可保留重置（banked reset）：这实质是一张“可择机使用的重置兑换券”，并不等于已经落袋、可直接调用的额度。它通常设有专属的有效期，具体须核对你的账户后台或活动说明。根据 OpenAI 官方文档，完整的 banked reset 一旦触发，会同时重置 5 小时与每周用量窗口，并同步重写后续每周的定期刷新日（具体时间需在 Usage 页面确认）。查看官方说明。
- 付费即时重置（Paid instant reset）：购买后即刻生效，无法留存备用。它全新的一周周期是从重置后的首次 Work 或 Codex 请求开始计时，下一次定期刷新在该请求的 7 天（168 小时）后，并不一定以扣款付款时刻为基准。查看付费即时重置规则。这一起算规则适用于该文所述的付费即时场景，不能直接套用到所有的 banked reset 上。
- 自动重置或全局重置（Automatic / Global reset）：由官方后台统一触发并即时生效，不会在你的账户中留下可延后使用的兑换机会。它与需要用户手动确认的 banked reset 有着本质区别。查看两类重置的官方定义。
决策前，先厘清三个关键时间节点
| 时间节点 | 核心需要确认的事项 |
|---|---|
| 重置机会到期时间 | 这次重置资格最晚能保留到何时？是否还允许你继续观望？ |
| 原定周刷新时间 | 如果现在不点重置，账户原有的额度何时会自然回满？ |
| 本期订阅到期时间 | 你的测算窗口截止到哪一天？有哪些未来的常规刷新落在该窗口内？ |
窄屏可左右滑动表格。
这三个时间维度相互独立，切忌混为一谈。重置机会明天过期，并不代表订阅明天就到期；同样，即便订阅还剩十天，也不等于重置机会还能放十天。
记录时间时务必统一核对时区。建议在同一时刻记下当前的剩余额度与原定刷新倒计时，避免拿早上的结余去匹配晚上的时钟。一旦执行了重置，刷新时间已被改写，便不能再拿重置后的新日期当作“维持现状（不重置）”的基准来对比。
为什么看到“100% 满格”，依然不能断定划算？
在本文采用的标准置换模型中，我们将一周的完整额度标准化定义为 100 单位。
若当前尚余 25 单位，执行重置使其回满至 100，眼前获得的实际净增是 100 − 25 = 75，而不是在原有 25 的基础上再叠加 100 变成 125。
这并非系统额外克扣了配额，而是在做“重置前已有结余”与“重置后全新额度”的差值对比。手头未用完的旧结余越多，重置在当下带来的实际净增就越有限。关于旧额度与新额度在水池模型中的流转关系，可参阅没用完的余额在重置后去了哪里。
明天的常规刷新，可能不再按原计划到来
为了看清时间周期的深层影响，我们可以看一个典型的条件演示模型：假设当前结余 25 单位，原定 24 小时后迎来常规刷新；此时使用了一次额外重置并立即发起调用，后续的一周周期将从此刻起按 168 小时重新计算。请注意：这是用于演示周期效应的理论推演模型，并非所有 banked reset 的固定官方规则。
在起点相同的连续 30 天观察窗口内：
- 不重置（维持现状）：以起始的 25 单位为基础，窗口内将如期迎来 5 次常规全额刷新，账面累计总额度为 525 单位。
- 现在执行重置：起始余额瞬间变为 100 单位，但因为刷新时钟被整体推迟，30 天内后续仅能再包含 4 次刷新，账面累计总额度为 500 单位。
对比之下，眼前的余额固然即刻多了 75 单位，但截至订阅到期，账面总额度反而少了 25 单位。这里减少的 25 单位，相当于一份标准周额度的 25%，并不代表订阅费直接蒸发了 25%。其根本原因在于：在这段特定的 30 天窗口内，由于刷新起点顺延，导致少收录了一次完整的周期刷新。
这里的“账面总额度”是将起始余额与未来各次完整刷新相加得出的理论供给总量，并不意味着它们能在账户中同时存在、无限囤积。完整的时间线推演可参考如何计算到订阅结束时的额度变化。
反之，如果其他参数完全相同，但本期订阅仅剩最后 12 小时，两条路径在到期前都无法再等到任何后续刷新。此时账面总额的对比就直接演变为 25 对 100，重置净赚 75 单位。这充分证明：测算结论高度依赖于你的订阅截止时刻，同时也并不保证你能在短短 12 小时内充分消耗完这 75 单位。
哪些场景建议果断重置，哪些情况不妨再等等？
| 现实场景 | 决策建议与评估考量 |
|---|---|
| 工作已被限额彻底卡死，且有无法推迟的交付任务 | 建议优先考虑使用重置。此时首先确认这次重置能否解除卡死你的那个特定用量窗口；对于关键生产力而言，解除阻断的时效价值往往远高于周期账面的微小差额。 |
| 距离常规刷新仅剩不久，当前结余足以应付手头琐碎工作 | 建议优先等待自然刷新，前提是重置机会不会在此期间过期。没有必要仅仅为了图视觉上的“满格”，就白白浪费即将到来的自然补满。 |
| 重置机会已临近有效期截止 | 核心看有效期窗口内是否有切实的用量需求。不必教条地非等到当前余额降为 0 才用，但也不要因盲目害怕“过期损失”而强行在不需要时提前触发。 |
| 本期订阅即将结束，且明确不打算续费 | 请以真实的到期时刻进行对比。到期时刻及之后的刷新不计入本次比较，重置多出来的额度能否转化成产出，依然取决于剩余时间与任务密度。 |
窄屏可左右滑动表格。
实际开发中并不存在放之四海皆准的“唯一最优解”。账面上同样是减少 25 单位，对于背负紧急交付截点的人与处于空档期的人而言，其理性决策往往截然相反。
如何借助计算器做出清晰判断？
在 Reset Observatory 中文计算器中填入你的剩余额度与原定刷新倒计时，首先看清眼前的“即刻净增”；随后填入本期订阅的真实到期时刻，对比两条路径在同一时间窗口内的账面总额差。请注意：计算器默认的月末时间仅供参考，务必以你个人的真实账单到期日为准。
计算器为你量化的是“在这组输入与特定规则下，执行重置会改变什么”，而非全自动猜度出所谓的未来最佳点击时刻。若你决定稍后再用，届时仍须重新复核当时的余额、刷新倒计时与机会有效期，切不可盲目假定等待期间外部条件一成不变。
此外，若你当前仅仅是触发了 5 小时短周期限额，周额度模型无法直接给出全貌：周额度账面虽然未变，但短窗口的及时复活对工作依然至关重要。模型并未模拟动态 5 小时限流，更不能保证回满后所有的代码并发请求都能顺畅执行。
理智重置的第一步：先看它能否解决当务之急，再算它在整个周期里到底动了谁的奶酪。