--- title: "Codex 48小时两次被迫重置Token额度——消耗太快的真相来了" type: raw source: wechat ingested: 2026-07-03 sha256: 3ebb1329d8bbf78e91ed0d89d384be045e189809be2c4f047c7a02834024780b --- # Codex 48小时两次被迫重置，token额度消耗太快的真相来了 # Codex 48小时两次被迫重置，token额度消耗太快的真相来了 原创 哩吧啦 哩吧啦 [ 夕小瑶科技说 ]() __ _ _ _ _ 在小说阅读器读本章 去阅读 在小说阅读器中沉浸阅读 哈喽朋友们，最近也是囤上 Codex 的重置额度了。 6 月 29 日到 30 日，Codex 连续两天宣布额度重置。 再加上我之前靠拉新活动存下的重置次数，现在账户里的额度已经多到有点离谱——真是用不完，根本用不完！ 这两次重置的直接原因，都是 Codex 最近这一轮额度异常消耗的 bug。 OpenAI 出来给补偿也不难理解。毕竟，这事前几天在开发者社区闹得还挺大。 6 月 25 日，有开发者发现了一个非常离谱的现象： 只发了一条消息，Codex 的全部额度就被瞬间烧光，5 小时限制直接掉到 0%。 更诡异的是，这并不是个例。 随着讨论不断扩散，大家对 Codex 额度透明度的质疑也越来越集中。 不少网友甚至直接 @ Codex 产品负责人 Tibo 讨说法——成功把本人炸出来了。 6 月 27 日，Tibo 开始紧急回应。 他先给出了一个初步判断，称问题可能和“防止滥用和欺诈的机制误标”有关。随后又宣布，将在几小时后为所有用户重置额度。 ** 而在 6 月 30 日，这次“额度异常”的正式调查结果终于出炉——Tibo 此前的推测居然也没中。 ** 按照 Tibo 的报告，这次并不是某一个单点 bug 把额度系统干崩了，而是多个问题在特定用户场景下叠加放大——换句话说，是“亿点点问题在一起爆了”。 简单来看，主要问题集中在几个方面： * 自动代码审查触发频率过高 * 任务拆解机制异常，导致触发更多子任务 * 失败 prompt 在后台发生重复重试 * 用量统计与分类显示出现偏差 目前，OpenAI 已经回滚了相关改动，并修复了重复生成、重复调度和异常重试的问题。 ** 当然，必不可少的，又为大家发了重置。 ** 看到这里，感觉 OpenAI 发重置已经发到不知天地为何物了：出 bug 要发，修 bug 也要发。硬重置要发，重置卡也要发。 这里顺便解释一下，什么是硬重置 （hard reset），什么又是重置卡（banked reset）。 这也是 Codex 团队贡献的一个震撼首发：以前只有 hard reset，也就是官方直接帮用户重置额度。 但这就产生了一个很尴尬的问题——有些用户的周限额马上就要自动刷新了，结果官方突然一键重置，相当于把一次补偿重置直接撞在了自然刷新前夜。 怎么说呢，不能算没给，但也确实有点浪费。 所以机智的 Codex 团队发明了 banked reset，也就是“重置卡”。官方先把一次重置额度发到你的账户里，具体什么时候用，由用户自己决定。 不过，疯狂的重置并不能讨好所有人。比如成功把 Tibo 召唤出来的那位小哥，就不是很买账。 > 重置并不是解决方案，给我们一个永久性的修复方案才是解决方案。 ** 不过，Codex 一时半会儿可能真搞不定这件事。 ** 一个关键线索，藏在 Codex 团队过于激进的协作方式里。 Andrew 把他们的协作模式称为 “zone defense”，也就是“区域联防”。 在传统公司里，通常是 PM 写需求，设计师做界面，工程师写代码，大家按流程接力推进。 ** 但在 Codex 团队里，谁离问题最近，谁就直接上手解决。 ** 工程师不再等待完整 PRD，而是在 Codex 中快速验证多个交互方案；设计师也可以直接用 Codex 写代码，把设计意图变成可运行版本。 播客传送门： https://www.youtube.com/watch?v=P3KDebPTUrw 不得不承认，这种协作模式使得 Codex 的更新速度惊人。 但也带来了极具风险的一面：产品在前面飞，bug 在后面追。 事实上，早在 2025 年底 Codex 出现计费异常时，团队就采取过一次激进修复——直接重写了计费与使用追踪系统的底层逻辑。 但即便如此，Codex 的额度问题依然没有彻底消失。 额度故障一波接一波，官方重置也一轮接一轮。 出于对 Codex 疯狂重置的好奇，我们认真研究了这次的故障报告，也翻了翻 Codex 过去和各种额度 bug 斗智斗勇的历史记录。 最后，我们扒出了三条 Codex 额度疯狂燃烧的真相。 # 真相 1：后台任务正在偷跑你的额度 后台任务在很大程度上解释了一个最直观、也最令人困惑的问题： 即使用户没有任何主动操作，Codex 的额度仍然在持续下降。 在最近这次额度异常中，后台“偷跑”任务的消耗主要来自两个方向： 其一，过度激进的代码审查机制。 原本用于辅助理解与校验代码质量的 review 流程，在某些版本中被调得更为主动，甚至会在用户未明确触发的情况下提前启动分析流程。 其二，任务拆解与子 agent 调度机制。 一个 prompt 在系统内部并不一定对应一次调用，而可能被拆成多个理解、审查、修改、验证环节，最终让一次前台请求变成一串后台动作。 除了上述在报告中的 bug 以外，默认记忆预览功能也是后台跑走 token 的大户。 今年 4 月份增加的这个功能，核心逻辑是让系统能够读取用户最近的屏幕上下文，从而“补全记忆”，让连续对话看起来更顺滑、更懂你在干什么。 所以，它的实现方式并不只是“用的时候才工作”，而是会持续抓取并更新上下文，相当于即使你没有在使用 Codex，AI 也可能在后台不断刷新你的短期记忆状态。 如果不想被这个功能浪费 token，可以在「个性化 → 记忆」里直接关闭。 # 真相2：幽灵额度，“死去”的任务反复攻击你的额度 在这次额度异常中，Tibo 也再次提到了一个更隐蔽、但更致命的问题： ** 失败情况下的 AI 反复尝试机制 ** 。 在 Codex 的执行链路里，一个任务并不是“失败就结束”，而是可能进入不断重试和分叉的状态： 子 agent 在失败重试或路径分叉时，会继续扩展调用链；在某些情况下，Codex 在后台自动生成的建议任务甚至可能被重复运行，或者因为重试机制过于激进而被多次触发。 换句话说就是：一个任务已经失败了，但 AI 还在继续“尝试救活它”。 这就直接引出了开发者社区长期在讨论的一个问题—— ** 幽灵额度（Phantom Quota） ** 。 所谓“幽灵额度”，指的是 Codex 任务在挂起、超时或失败后，虽然没有返回任何可用输出，但 token 已经被真实消耗掉的现象。 而在当前机制下，并没有一个明确的补偿路径——任务无法被取消回滚，已经消耗的 token 也不会因为“没有产出”而退回。 # 真相 3：Codex 算错数，看到的额度不属实 计算问题本身，也是 Codex 长期存在的一类“隐性问题”。 在这次额度异常的报告中，这类问题主要集中在两个方向。 ** 首先是额度显示层面的错位 ** ——自动审查（auto-review）曾经被错误地归类进 GPT-5.4 的使用统计中，导致很多用户看到的“模型消耗”，并不是真正由该模型完成的请求，而是后台审查系统的流量被混在了一起。 同时，未完成请求（中断或被限流的请求）以及速率限制请求，也曾被计入“回合数（turns）”图表中 。也就是说，即使任务没有成功执行，它仍然可能出现在使用记录里，看起来像是已经消耗了一次额度。 更关键的问题在于：这些“统计误差”并不是单点异常，而是曾在一段时间内同时存在于同一套计量体系中，使得用户看到的 usage 曲线，与实际执行行为之间产生了明显偏差。 此前，Codex 就出现过类似的 bug ，大量开发者进行过报告： 例如，在 Codex CLI v0.40.0 中，用户发现 5 小时滚动额度和每周额度并不会按比例变化。这使得当 5 小时额度增加 2% 时，每周额度只增加 1%；意味着 5 小时窗口内的高强度使用，会不成比例地影响你的每周上限； 此前，Codex 也被发现不同模型之间的 usage 会出现错位计数，甚至在切换模型后，旧模型的用量仍然持续被累积。 # 写在最后 Codex 的额度故障不是第一次，大概率也不会是最后一次。 按照 Andrew 的说法，无限的 token，意味着无限多的原型。团队可以更快试错、更快验证，也可以把几十个点子迅速推到用户面前。 在这种节奏里，品味和判断力似乎成了最后的筛选器。 但问题也在这里。 当产品跑得越来越快，测试窗口就会被压得越来越薄。很多问题不再是在发布前被拦住，而是在真实用户的额度账单里，才第一次被看见。 这或许也是 AI native 的另一面： 用户一边享受更快的产品进化，一边也不得不接受一个现实—— ** 地球最前沿的 AI 产品，将长期保持在“半成品”的状态里。 ** 参考文献 [1] ` https://inhaq.com/blog/openai-codex-draining-quota-too-fast ` [2] ` https://www.youtube.com/watch?v=P3KDebPTUrw ` 预览时标签不可点 微信扫一扫 关注该公众号 [ 知道了 ]() 微信扫一扫 使用小程序 **** [ 取消 ]() [ 允许 ]() **** [ 取消 ]() [ 允许 ]() **** [ 取消 ]() [ 允许 ]() × 分析 __ 微信扫一扫可打开此内容， 使用完整服务 ： ， ， ， ， ， ， ， ， ， ， ， ， 。 视频 小程序 赞 ，轻点两下取消赞 在看 ，轻点两下取消在看 分享 留言 收藏 听过