编辑|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 似乎还没打算就此收手?
本文来自微信公众号 “机器之心”(ID:almosthuman2014),作者:关注科学AI的
