OpenAI 一次性修复 Codex 8 类烧 Token Bug，付费用户集体回血

OpenAI Codex 负责人 Tibo 在社交平台宣布，将为所有 Codex 和 ChatGPT Work 付费用户重置使用额度，并一次性公开了近期集中处理的 8 类后台 Bug。根据官方测算，修复后同样的额度预计可比之前多撑 10%-50%。此次动作发生在 OpenAI 计划在三个月后阻止 Cursor 用户继续访问其模型的当口，被视为对开发者社区的一次集中回应。

上下文压缩与任务目标：额度消耗的两大重灾区

第一类问题出在上下文压缩（Compaction）机制上。当 AI 编程工具运行时间变长，系统通常会压缩历史信息以维持上下文窗口，但旧版 Codex 在压缩时并未清理旧图片，导致上下文压缩后体积依然偏大，部分情况下甚至会立刻触发下一次压缩。OpenAI 表示，对于重度使用图片的用户，仅此一项修复就让相关使用量下降约 10%。

更严重的消耗来自任务目标（Goals）机制。OpenAI 发现，部分用户设定的 /goal 在执行完成后，Agent 并没有按预期停止，而是继续往后执行；另有部分情况下，工具已经失效，模型仍在反复重试。官方披露的极端案例中，仅此一个问题就吃掉了用户每周 15%-70% 的额度。

Memory、Subagent 与自动化：藏在后台的「隐形烧 Token」

第三类问题出现在记忆系统。Codex 的后台 Memory Worker 在某些场景下会继承特定的 Stop Hook，导致任务无法满足停止条件而一直运行。受影响用户不到 1%，但长尾案例异常夸张——OpenAI 提到，有一个案例中系统反复检查任务是否可以结束，次数多达 15000 次。

第四类问题与 Subagent 子智能体有关。一些能力较小的模型（如 Luna）会在用户未明确要求的情况下，自行调用更强、成本更高的辅助模型；主模型即便未运行在 /fast 模式下，也可能要求子 Agent 使用 /fast。这一行为已被修复。

第五类是自动化任务（Automations）。部分自定义调度任务的实际执行频率高于用户设定的频率，由于 Agent 能在无操作时自行运行，累积起来消耗并不小。

历史总结、MCP 与使用量透明度

第六类问题来自 Computer History：旧版 Codex 会重复总结已经高度重叠的历史活动，OpenAI 估算这部分额外开销在一些案例中占到用户每周总使用量的约 20%。与之相关的 Rolling Task Summaries 则在普通对话轮次中额外触发后台请求，每次约增加 1% 的 Token 使用量，目前已被直接关闭。

最后一类问题发生在 MCP 工具调用上。部分工具返回结果被重复编码两次，另有部分工具说明被意外截断后又被重新拉取。单次影响有限，但 Agent 一天可能调用数十、数百次工具，积少成多后都会反映到用户额度上。

一次越来越难算的账

OpenAI 在公告中表示，除了逐一修复上述 Bug，团队还进行了架构层面的调整，并加入了异常自动告警机制。更值得关注的是，OpenAI 正在开发新的使用量展示功能，未来用户可以直接在应用内看到额度具体花在了哪里——是真正用于写代码的 Token，还是用于上下文理解、记忆维护、任务摘要或 Agent 调度的后台开销。

对 Agent 类产品而言，「用户输入一句话」和「系统执行一整条工作流」之间的差距正在拉大，Token 的去向也越来越难以直观判断。这次集中修复与其说是单纯给用户「回血」，不如说是 OpenAI 对自家 Agent 计费体系的一次系统性梳理。