近两天，打开 Codex 的开发者大概率经历了同一种困惑：额度条突然回到 100%，不是自己充的，也不是周期到了，就是……莫名其妙满了。
然后过几个小时，又满了。
这不是个例。从 Linux.do 社区到 Reddit r/codex 板块，关于「额度异常重置」的帖子在 4 月 19 日至 21 日之间集中爆发，多位用户确认自己在不到 48 小时内经历了两到三次额度刷新。一位用户的原话是：「不是哥们，算下来两天重置了两次？？？刚刚一刷新又是 100%，不知道该夸还是该骂。」
该夸还是该骂，确实是个好问题。
到底发生了什么
Codex 的配额机制本身不复杂：按订阅等级（Free / Plus / Pro）分配周额度，每七天重置一次，用完等下周。这套逻辑从上线以来一直稳定运行，开发者也早就习惯了「周末通宵把额度刷完，安心睡觉等下周」的节奏。
但从 4 月 19 日开始，这个节奏被打乱了。
根据社区多个信源的交叉比对，这轮异常重置至少涉及三个触发因素：
- 宕机补偿：4 月 19 日夜间 Codex 出现了一次服务中断，OpenAI 随后对受影响用户进行了额度补偿重置。这是第一次。
- 用户里程碑活动：Codex 用户数突破 400 万，官方再次触发全量额度重置作为「庆祝」。这是第二次，距离第一次不到 24 小时。
- 疑似后台调整：部分用户报告在上述两次之外，还观察到额外的额度刷新，且 App 内显示的「额度刷新时间」一直在动态更新，暗示计费系统可能正在进行更深层的调整。
一位用户精准地总结了这种混乱：「用户数量加了 100 万又刷新额度了。昨天才刷新的，今天又刷新了。」
不是所有人都在狂欢
表面上看，额度反复重置是白捡便宜。但实际体验远没有这么简单。
首先是预期管理的崩塌。有用户本来计划通宵把 Plus 的周限额刷完再睡觉，结果刷到一半额度又满了，「这下又开始循环了」。对于那些有明确开发计划、按额度分配任务优先级的人来说，突然多出来的额度反而打乱了节奏。
更微妙的问题在于公平性。一位用户指出了一个很多人忽略的逻辑：如果在上一次集体重置完的七天后再次重置，那些已经用完额度的人等于白赚一轮，而那些还剩大量额度的人等于被「抹平」了——未使用的配额不会累积，提前重置意味着你剩余的部分直接蒸发。
这就像你办了一张月卡健身房，还剩 15 天的时候突然通知你：「恭喜，月卡重新开始计时了！」听起来是好事，但你上半个月没去的那些天，就这么没了。
还有一个更实际的问题：额度消耗的不透明。有用户反馈自己用 Codex 写了 4000 行代码，额度居然没掉。另一位 Free 用户发现请求了两次之后还剩 97%，「感觉 Free 更耐用了」。但这种「耐用」持续了大约一个小时就恢复正常，开始正常掉额度了。
这说明在重置窗口期内，计费系统本身可能处于某种不稳定状态——不是额度真的变多了，而是计量暂时失灵了。
计费机制到底在调什么
如果只是宕机补偿加用户里程碑活动，事情并不复杂。但多个迹象表明，OpenAI 可能正在对 Codex 的计费机制进行更根本性的调整。
第一个线索是刷新时间的动态变化。正常情况下，Codex App 里显示的额度刷新时间应该是一个固定的未来时间点（比如「7 天后」）。但有用户注意到这个时间「一直在更新」，这不像是简单的补偿重置能解释的行为，更像是后端在反复修改配额周期的参数。
第二个线索是不同层级用户的体验差异。Pro 用户报告额度「老自己刷新」，Plus 用户经历了明确的多次重置，Free 用户则感觉「更耐用了」。如果只是全量重置，所有层级的体验应该是一致的。差异化的表现暗示 OpenAI 可能在按层级测试不同的配额策略。
第三个线索来自 Reddit。有用户反馈在使用 GPT 5.4 Low 推理模式时，重置后的额度「瞬间耗尽」，仅仅发了大约 5 条消息就见底了。这可能意味着不同模型、不同推理强度的额度消耗权重正在被重新校准。
把这些线索拼在一起，一个合理的推测是：OpenAI 正在从固定周期的「时间制」配额，向更动态的「用量制」配额过渡，或者至少在测试这种可能性。
这并非没有先例。Claude 的 API 计费早就采用了按 token 消耗的动态模型，Google 的 Gemini API 也在免费层和付费层之间设计了复杂的速率限制梯度。Codex 作为一个代码生成工具，其单次请求的资源消耗差异极大——生成一个简单函数和重构一个完整模块，背后的计算成本可能差十倍。用固定的「次数」或「周期」来一刀切，本身就不够精细。
对开发者意味着什么
如果你是 Codex 的日常用户，短期内需要注意几件事。
别指望额度规律刷新。 至少在这轮调整稳定之前，「周末刷完额度等下周」的策略可能不再可靠。额度可能随时被重置，也可能在你不注意的时候被重新校准。建议在有重要开发任务时优先使用，而不是囤着等最后一天突击。
关注消耗速率而不是百分比。 多位用户的反馈表明，同样的操作在不同时间段的额度消耗可能不一致。如果你发现某段时间「特别耐用」，大概率不是你变强了，而是计费系统在波动。反过来，如果突然觉得额度掉得飞快，也别急着骂——可能只是权重被调高了。
Pro 用户暂时是最大受益者。 从社区反馈来看，Pro 层级在这轮异常中获得了最多的「免费」额度刷新。如果你一直在犹豫要不要从 Plus 升级，现在倒是一个观察窗口——看看 Pro 的实际可用量在调整后会稳定在什么水平。
留意官方公告。 截至发稿，OpenAI 尚未就这轮异常重置发布正式说明。但考虑到影响范围之广（Reddit、Threads、Linux.do 多个平台同时出现讨论），官方回应应该不会太远。
更大的图景
把视角拉远一点，Codex 的配额问题其实折射了整个 AI 编程工具赛道的一个核心矛盾：用户增长速度远超基础设施的承载能力。
Codex 用户数从 300 万到 400 万只用了很短的时间，而每个新增用户都意味着真实的 GPU 算力消耗。不像社交产品的用户增长主要吃带宽和存储，AI 产品的每一次推理请求都在烧显卡。当用户基数膨胀到一定程度，要么涨价，要么限量，要么在计费机制上做文章——OpenAI 显然选择了第三条路，至少目前是。
这也是为什么越来越多的开发者开始采用多模型策略，而不是把所有鸡蛋放在一个篮子里。当你的主力工具因为配额波动而不可预测时，有一个备选方案就不再是「锦上添花」，而是「刚需」。像 OpenAI Hub 这类支持多模型切换的聚合平台，在这种场景下的价值就体现出来了——Codex 额度见底的时候，切到 Claude 或 Gemini 继续干活，不用中断工作流。
当然，配额问题最终会被解决。要么 OpenAI 找到更高效的推理方案把成本打下来，要么新的计费模型跑通后给出一个稳定的预期。但在那之前，开发者需要适应一个现实：你依赖的 AI 工具，其可用性本身也是一个变量。
这大概是 2026 年做开发者最魔幻的地方——你的工具比你的代码还不稳定。
参考来源
- Codex 又刷新额度咯 - Linux.do — 用户反馈 Pro 订阅额度反复自动刷新
- Codex 又要重置额度了吗？ - Linux.do — 多位用户讨论两天内多次额度重置的异常现象
- Codex 写了 4k 行代码额度没掉？ - Linux.do — 用户发现额度消耗异常，疑似计费系统波动