OpenAI要给Codex、ChatGPT Work付费用户集体回血了_今日精选

编辑｜Sia

就在 Cursor CEO Michael Truell 透露，OpenAI 计划在三个月后阻止 Cursor 用户继续访问其模型、双方关系突然紧张的当口，OpenAI Codex 突然放出一个新动作。

刚刚，这些付费用户突然迎来了一波额度回血——Codex 负责人Tibo 在推文宣布，将为所有 Codex 和 ChatGPT Work 付费用户重置使用额度。

(资料图片仅供参考)

这次并不是简单粗暴地多送一点。

Tibo 表示，他们最近集中处理了数千份用户反馈，把 Codex 背后的使用量计算机制几乎翻了个底朝天。结果发现，用户之前感觉额度怎么这么不经用，还真不完全是错觉。

在一系列 Bug 被修复之后，根据不同使用方式，他们预计：同样的 Codex 使用额度，现在可以比之前多撑 10%-50%。额度数字可能没变，但实际能干的活变多了。

这次公布的问题清单，几乎堪称一份《 AI Agent 是如何偷偷烧 Token 的大全》。其中一些 Bug，看起来不起眼，烧起额度来却相当凶猛。

一个任务，最多能吃掉一周 70% 的额度

OpenAI 一口气列出了 8 类已经发现并修复的问题。

第一个，就是上下文压缩（ Compaction ）。AI 编程工具运行时间一长，上下文越来越大，系统通常会把历史信息压缩一下，以便继续工作。

问题在于，Codex 此前进行上下文压缩时，会把旧图片继续留在上下文里。结果，本来压缩是为了把上下文变小，但旧图片没清掉，上下文依然很大，大到甚至可能马上再次触发一次压缩。

于是就出现了一种略显魔幻的情况：为了省上下文而进行的压缩，本身反而开始消耗更多上下文。OpenAI 修掉这个问题之后，对于那些大量使用图片的用户，相关使用量直接下降了约 10%。

但这还不是最夸张的。真正的额度杀手，来自 Codex 的任务目标机制( Goals )。

OpenAI 发现，在部分情况下，用户设定的/goal明明已经执行完成，Agent 却没有按照预期停下来，而是继续往后执行。

另一种情况是工具明明已经坏了，模型依然会不断尝试重试。任务看上去已经结束，AI 却还在后台一遍遍干活。

OpenAI 称，他们看到的一些案例中，仅仅这个问题，就能消耗掉用户每周额度的15%-70%。也就是说，极端情况下，一个异常任务，可能直接吃掉七成周额度。现在，这个问题也已经修复。

有个后台任务，甚至差点跑了 15000 遍

另一处问题出现在 Memory，也就是记忆系统。

Codex 的后台 Memory Worker 在部分情况下，会继承某些 Stop Hook。本意上，Stop Hook 是用来控制任务何时停止的。但 Bug 出现后，某些后台任务反而可能因为停止条件无法满足，一直运行下去。

这类问题影响的用户其实不到 1%。但问题在于，长尾案例异常夸张。OpenAI 提到，他们甚至发现过一个案例，系统检查某个任务是否可以结束的动作，可能执行多达 15000 次。

对绝大多数用户来说，这个 Bug 可能完全无感。但对撞上的用户来说，Token 就可能在后台悄无声息地蒸发。这种感觉大概就像电脑什么都没打开，风扇却突然开始狂转。

Subagent 也会偷偷升级配置

还有一个很有 Agent 时代特色的问题，发生在 Subagent 子智能体身上。

现在的 Codex 并不一定只靠一个模型完成任务。复杂任务可以被拆分，然后调用多个子 Agent 协同执行。问题就出在这里。

OpenAI 发现，一些能力较小的模型，比如 Luna，有时候会在用户没有明确要求的情况下，自行选择能力更强、成本也更高的辅助模型。

更离谱的是，即便负责统筹任务的主模型没有运行在/fast模式下，它也可能要求下面的子 Agent 使用/fast。

这就像老板坐经济舱，结果给几个助理偷偷买了商务舱。任务当然还是那个任务，但背后的资源消耗已经不是一回事了。目前这一问题也已经修复。

自动化任务，说好一天一次，实际可能偷偷多跑

Automations 也被抓出了问题。

OpenAI 表示，一些自定义调度任务此前可能会出现：实际执行频率，比用户设置的频率更高。比如用户原本只希望某个自动化任务定期执行，但系统可能比设定的时间更加频繁地唤醒任务。

单次看或许不多，可 Agent 的特点恰恰是——它能在没有用户操作的情况下自己运行。跑一次不贵。多跑几十次，就不一定了。这个问题目前同样已经被修复。

光是总结自己干了什么，也能吃掉 20% 周额度

另一个比较典型的问题，来自 Computer History。

为了让 Agent 理解自己之前在电脑上做过什么，系统需要保存、整理甚至总结过去的操作历史。但旧版本的实现中，Codex 可能会重复总结已经高度重叠的历史活动。相当于同一段工作日志，一遍遍重新整理。

OpenAI 称，在一些案例里，这部分额外开销可以占到用户每周总使用量的约五分之一。也就是 20% 左右。

还有一个类似的后台消耗，来自 Rolling Task Summaries。原本普通对话轮次，也可能触发额外的后台请求，用来生成滚动任务摘要。

单次开销不算大，OpenAI 估计大约增加 1% 的 Token 使用量。还是那句话：一次 1% 不多，架不住每次都来一点。OpenAI 已经直接关闭了这一机制。

MCP 也没逃过：同一份工具结果可能编码两遍

最后一类问题，发生在 MCP 工具调用上。

OpenAI 发现，部分工具返回结果可能被重复编码两次。除此之外，还有一些工具说明会被意外截断，随后系统又不得不重新获取一次。

这类问题单独看都像是工程实现里的小毛刺。但当 Agent 一天调用几十次、几百次甚至更多工具时，每一次重复传输，都意味着真实的 Token 消耗。积少成多之后，最后都会反映到用户的额度里。

一笔越来越难算的账

把这次修复放在一起看，一个很明显的变化正在出现：过去使用 ChatGPT，用户基本可以把一次对话理解成一次模型调用。

但到了 Codex 这样的 Agent 产品里，事情已经完全不同了。

你在界面上只输入了一句话，系统看到的可能是一整条 Agent 工作流，到底用了多少额度正在变得越来越难以直观理解。

有些 Token 是模型真正拿来写代码的。有些 Token 用来理解上下文。还有一些 Token，甚至只是后台系统为了维护记忆、生成摘要或者调度 Agent 而产生。这里任何一个环节出现循环、重复调用或者错误调度，用户最终感受到的就只有一件事：怎么什么都没干，额度就没了？

OpenAI 显然意识到了这个问题。除了修复上述 Bug，他们还表示已经进行了架构层面的调整，避免类似问题再次出现。如果相关异常重新发生，团队也会自动收到告警。

更重要，OpenAI 正在开发新的使用量展示功能。未来用户可以直接在应用内看到，自己的额度到底花到哪里去了，而不用再靠猜。

从这个角度来看，这次重置额度或许只是表面福利。而且，OpenAI 似乎还没打算就此收手?

关键词： 调用 上下文 付费用户 codex agent ope