Codex 48小时内两次重置额度，token消耗过快的三大真相
2026/07/02 10:05阅读量 4
OpenAI Codex 因 token 额度异常快速消耗，48 小时内两次启动额度补偿重置。官方调查确认问题由自动审查过度触发、任务拆解异常、失败任务重复重试及统计偏差等多重因素叠加导致。此外，默认记忆预览功能在后台持续消耗 token，“幽灵额度”机制下失败任务仍消耗额度且无补偿，进一步加剧了用户的额度问题。
事件概述
6 月 25 日，多位开发者发现 Codex 的 token 额度异常快速消耗，仅发送一条消息即导致全部额度瞬间耗尽。6 月 27 日，Codex 产品负责人 Tibo 初步回应称可能与防滥用机制误标有关，随即首次为所有用户重置额度。6 月 30 日，官方公布正式调查结果，确认问题由多个因素在特定用户场景下叠加导致，包括自动代码审查触发频率过高、任务拆解机制异常、失败 prompt 在后台重复重试、用量统计分类偏差等。修复后再次开启额度补偿重置。
核心信息
1. 后台任务偷跑消耗 token
- 本次故障中，自动代码审查过于激进，在用户未明确触发时提前启动分析；任务拆解机制异常导致一次前台请求被拆成多个子环节，额外消耗 token。
- 今年 4 月新增的默认记忆预览功能，会持续抓取并更新屏幕上下文，即使无主动操作也会消耗 token。用户可在「个性化→记忆」中关闭该功能。
2. “幽灵额度”：失败任务反复重试无补偿
- Codex 的任务在失败后不会直接终止，而是进入反复重试和路径分叉状态。即使没有产出有效结果，这些“死亡”任务仍会真实消耗 token，且当前没有回滚补偿机制。开发者将此现象称为“幽灵额度”。
3. 额度统计偏差
- 自动审查的后台流量曾被错误归类到其他模型的使用统计中，导致用户看到的模型消耗数据错位。
- 未完成、被限流的请求也被计入“回合数”图表，造成使用曲线与实际执行情况偏差。
- 此前 Codex 曾出现 5 小时滚动额度与每周额度不成比例变化、不同模型用量错位累计等计量 bug。
值得关注
Codex 团队采用“区域联防”的激进协作模式——工程师无需等待完整 PRD 即可快速验证交互方案，设计师也可直接写代码落地设计意图。这种模式使更新速度极快，但压缩了测试窗口，导致问题常在用户使用时才暴露。2025 年底曾出现计费异常，团队重写计费与使用追踪系统底层逻辑后仍未彻底解决额度问题。目前 Codex 已推出“重置卡”机制，允许用户自主决定何时使用官方补偿的额度。