Codex 又不告诉你下次何时重置——把 AI 编程额度当外部依赖来运维
你 9 点上线一批批量 agent 任务，10 点撞上 Codex 每周上限，任务跑了一半停摆。
官方不公布下次重置时间。V2EX 上，开发者们按太平洋时间互相"对表"，决定几点开工最划算——把个人排期押在一条未文档化的规则上。
如果你重度用 Codex CLI / Cursor / 桌面版，这件事不该靠"追热点"解决。正确的姿势是：把额度当成一个没有 SLA 的外部依赖来工程化——像对待数据库连接池、第三方 API 配额那样。
先搞清楚：你到底撞的是哪一层上限
Codex 的额度是两层水位，分开计算：
- 5 小时窗口：撞了它，等 5 小时自动回血
- 每周上限：撞了它，等多久都白等——只能等官方重置，或动用重置券
很多人等错层：撞的是每周上限，却在等"5 小时后恢复"——白等。
官方只给到"哪天恢复"的粒度，具体时刻要自己在 CLI 里跑 /status 看。所以第一课：撞了上限，先分清是哪层，再决定是"等 5 小时"还是"等重置"。
为什么"等官方通知"是最差策略
Codex 额度的重置规则，本质上是一条没有 SLA、没有固定时间表的规则：
- 没有公开的重置周期。第三方追踪站 codex-resets.com 记录了 35 次重置、平均间隔 8.9 天——但这是社区按 OpenAI 官方 X 公告逐条整理的推断，不是官方承诺
- 重置券（banked reset）30 天过期且不提醒。2026-06 上线的"额度重置券"，Plus/Pro 上线即送一张、邀请上限 3 张，券自发放起 30 天有效——过期了官方不在 UI 明显提醒，得自己记
- 社区里"重置后额度缩水"“到底几点重置"的讨论，都说明开发者正在为一条未文档化的规则做排期
把工作节奏押在这样一条规则上，等于把关键路径交给一个你不知道何时触发的 cron。
工程化动作一：把额度做成可观测指标
不靠刷论坛对表，把额度信息变成你系统里的指标：
- 把
/status输出、用量面板、重置券到期日，抓成内部指标或日历提醒 - 重置券到期技巧：拿到券当天就设 25 天后的提醒（“券剩 5 天”）——防 30 天过期
- 每周看一次额度趋势，而不是撞上限那天才看
可观测的前提是数据进系统，不是进脑子。
工程化动作二：流水线与 agent 编排去硬编码假设
批量任务别假设"额度永远充足”。给流水线加三样东西：
- 排队：额度不足时任务进队列，不直接失败
- 幂等重试：撞上限的任务能安全重试（不重复产生副作用）
- 降级开关：额度耗尽时降级到便宜模型/等待回血，而不是硬停
核心原则：不要把"额度充足"写进假设。它是一条随时可能耗尽、且你无法预测耗尽后何时恢复的资源——那就按"可能耗尽"设计。
工程化动作三：锁版本 + 灰度升级
Codex CLI 是 alpha 节奏——2026-09-11 一天内发了 rust-v0.155.0-alpha.3.7 → .8 → .9 三个 tag（仓库 123,630★，但 alpha 号说明非稳定发布）。
- 锁版本：固定一个已知稳定的 tag，别追每个 alpha
- 灰度升级：先在小批量任务上试新版本，验证没问题再全量
- 把"升级"变成可控变更，而不是被动跟着 tag 跑
必看的反例：什么时候这套是过度工程
- 个人低频使用、或套餐额度远大于需求时：直接
/status看两眼就行，观测层/降级开关是过度设计 - 能稳定用便宜模型兜底：降级开关收益大；否则"等重置"反而更省事
- 自建指标层的成本：这套东西本身要维护，会引入新的失败面——别为了管理额度，把系统搞复杂到需要再管理一套系统
边界：codex-resets.com 的 8.9 天是社区推断，不是官方 SLA——别把它当承诺写进排期。
一句话
Codex 额度不会因为你在论坛"对表"就变得可预测。把它当没有 SLA 的外部依赖：分清两层水位、做可观测指标、幂等重试、降级开关、锁版本灰度——这样无论官方明天动不动重置，你的流水线和 agent 编排都不会被一条未文档化的规则打挂。
明天就能做的一件事：跑一次 /status，看看自己撞的是哪层水位，然后给重置券设个 25 天提醒。
搬砖程序员带你飞，专注 Golang / AI / 后端。每天一篇，讲清楚一个技术真相。