Codex额度异常烧钱，OpenAI拉响应急警报

上周末，一批 Codex 重度用户在 X 上炸了锅：同样的编程任务，额度消耗速度比一周前快了好几倍。订阅 200 美元 Pro 套餐的开发者发现，原本能撑一周的额度，现在一天就见底。

OpenAI 的反应比想象中激烈。Codex 工程负责人 Thibault Sottiaux（蒂博·索蒂奥克斯）周日把整个团队拉进了作战室（war room），逐条核查运行日志。官方状态页同步更新，承认部分用户额度"消耗速度超出预期"，并已全面重置所有用户的额度上限。Sottiaux 在 X 上撂了句狠话："不查清根源绝不收工。"

故障是怎么浮上来的

这事最早是从开发者社区的吐槽里冒出来的。一位名叫 Adam 的软件工程师写道："系统肯定出了问题。我订阅的是 200 美元套餐，以往要整整一周高强度工作才会耗尽七天额度；但过去两天，我每天都一天就耗光整周额度，这也是我第一次不得不手动重置额度。"

类似反馈在周末迅速堆积。不同订阅档位、不同地区、不同使用强度的用户都在喊"烧得快"。一开始还有人怀疑是不是自己写的 prompt 太啰嗦、上下文太长，但随着越来越多老用户拿出对比数据——同一个仓库、同一类重构任务、同样的 agent 配置，消耗硬是翻了两三倍——大家很快意识到这不是错觉。

OpenAI 的状态页起初给出的解释是：平台的反滥用、反欺诈风控系统错误地对部分账户实施了限流。换句话说，风控模型把一批正常用户误判为可疑行为，触发了额度异常扣减。这个说法解释了"为什么是部分用户"，但没解释清楚"为什么消耗速度变快"——限流通常意味着请求被拒，而不是 token 被多扣。

真正的坑在缓存层

随着团队深入排查，问题的轮廓才逐渐清晰：根因不在风控，而在一次前不久部署的性能优化措施上。

Sottiaux 后续披露的细节里有个关键词——缓存命中率。Codex 处理长会话时，会做上下文压缩（context compaction），把历史对话压缩成更紧凑的表示以释放窗口空间。这是所有长上下文 agent 系统的标配操作。问题在于，这次优化改动了压缩路径之后，长会话场景下的 prompt cache 命中率出现了大幅下滑。

这事的连锁反应挺要命。正常情况下，Codex 在跑一个长任务时会反复复用前缀缓存——同一段系统指令、同一份代码上下文，命中缓存就只算很便宜的 cached input token 价格。一旦缓存失效，系统就得把全部历史上下文从头算一遍，token 计费按完整价格走。对于一个跑了几十轮的 agent 会话来说，这意味着每一轮新请求都在重新支付前面几十轮的上下文成本。

烧得快，就是这么烧的。

这也解释了为什么是"部分用户"——重度使用、长会话、跑 agent 任务的用户首当其冲，而只是偶尔问几句的轻度用户几乎感觉不到。订阅 200 美元 Pro 档位的工程师正好是这套机制的最大受害者，因为他们的典型用法就是连续几小时让 Codex 在大型代码库里跑重构、跑测试、跑 review。

OpenAI 怎么处理的

按 Sottiaux 给出的处置流程，团队做了三件事：

• 回滚那次性能优化，把引入缓存命中率下滑的代码移除
• 重置所有受影响账户的 Codex 额度，相当于把意外扣掉的额度还回去
• 持续监控状态页，把故障范围和恢复进度公开同步

额度重置这步算是比较厚道的处理。Codex 的额度本质是一个百分比形式的算力配额，不同订阅档对应不同上限，重度任务消耗更快。一次性全员重置意味着 OpenAI 不打算让用户去逐个申诉、提交日志证明自己被多扣了——直接全部抹平。

从工程视角看，这个故障也挺有教科书意义：一次以提升性能为目标的优化，最终在某个特定路径上把缓存语义弄坏了，而计费系统又紧密耦合在缓存命中率上。这种"性能优化反向烧钱"的事故，在分布式系统里不算罕见，但发生在一个按 token 计费的 AI agent 产品上，破坏力被直接放大成账单冲击。

为什么开发者反应这么大

几年前如果某个 IDE 插件出 bug，开发者顶多骂两句重启了事。现在 Codex 这种 agent 级编程工具出问题，反应级别完全不一样——因为它已经深度嵌进了不少团队的日常工作流。

一个细节值得留意：故障期间，X 上有开发者直接说"只能先停下手里的活，等额度重置"。这句话信息量很大。它说明：

• AI agent 已经不是"辅助工具"，而是部分开发者的主力生产工具
• 额度耗尽对他们来说不是"少了个玩具"，而是"今天活干不完"
• 一旦平台侧出故障，下游开发者几乎没有 plan B

今年 3 月 Anthropic 的 Claude 大规模宕机时，社区里就有过类似讨论——一群人吐槽"只能重新手写代码"，半开玩笑半认真。这次 Codex 事件本质上是同一种依赖关系的再次暴露，只不过表现形式从"用不了"变成了"用得起，但烧得离谱"。

行业背景：额度这件事正在变紧

把镜头拉远一点看，这次故障落在了一个微妙的时间点上。

过去一年，几乎所有头部 AI 服务商都在往收紧无限额度的方向走。Anthropic 在今年 3 月流量高峰期下调过 Claude 的额度上限；各家陆续取消或调整"不限量"档位；不少企业也开始限制员工对 AI 编程工具的使用以控制成本。算力供给增长追不上 agent 类应用爆发式的 token 消耗，这是底层矛盾。

在这种大环境下，用户对额度的敏感度是历史最高。订阅 200 美元的人不是不愿意付钱，而是他们清楚自己买的是什么——一个相对稳定可预期的算力配额。这个预期一旦被打破，就算后续重置补偿，信任成本也会留下痕迹。

OpenAI 这次响应速度算快——周日全员进作战室、状态页同步更新、负责人 X 公开发声、额度全员重置——动作幅度看得出他们也清楚这个 bug 的政治敏感性。Codex 是 OpenAI 在编程 agent 赛道对标 Claude Code、Cursor 的核心产品，正赶上市场份额争夺最激烈的阶段，任何"偷偷扣额度"的嫌疑都会被对手放大。

给开发者的几个实际启示

如果你也在重度依赖 AI 编程 agent，这次事件至少给出几个值得记下的点：

1. 盯紧用量曲线，而不是只看总额度。同样的任务消耗突然变化是最早的故障信号，比平台状态页通常还要早
2. 长会话不是免费的。即使有 prompt cache，缓存策略一旦出问题，长上下文 agent 会瞬间变成 token 黑洞。该开新会话就开新会话
3. 关键工作流要有降级方案。订阅一家平台当生产工具用，意味着你需要至少了解一下备选项的接入成本

对于第三点，多模型聚合方案是不少团队这两年开始采用的兜底思路——OpenAI Hub 这类聚合平台用一个 Key 就能调 GPT、Claude、Gemini、DeepSeek 等主流模型，兼容 OpenAI 格式、国内直连，故障切换不用改太多代码。Codex 这种产品级 agent 暂时还没法直接替代，但底层模型调用层做好抽象，至少能让你在某一家出问题时不至于完全停摆。

还没完

截至目前，OpenAI 称故障已修复、系统状态恢复正常、受影响账户额度已重置。但社区里也有人指出，"重置周（reset week）"之后又出现过新的额度异常波动，意味着这次根因排查可能还没真正告一段落。

按 Sottiaux 自己的说法，团队会继续盯日志、查残留问题。一个由"性能优化"引发的计费故障，背后其实牵涉到缓存层、计费层、风控层之间复杂的耦合关系，要彻底厘清边界并不是一天两天的事。

对开发者来说，能做的是把这次事件当成一次提醒：在 AI agent 已经接管相当一部分日常编码工作的当下，你的生产力曲线，已经和某个云端服务的工程稳定性深度绑定。这件事的好处和代价，都才刚刚开始显现。

参考来源

• OpenAI 成立"应急小组"，调查用户 Codex 额度消耗速度过快问题 - IT之家：IT之家关于本次 Codex 额度异常事件的原始报道，包含 Sottiaux 的官方表态和受影响用户反馈
• OpenAI 成立"应急小组"讨论帖 - linux.do：linux.do 社区围绕本次事件的开发者讨论，包含多位用户的实际使用反馈