单源称｜OpenAI修复Codex用量浪费

这是一条低置信但信息量很高的开发工具新闻。8月30日，北京时间凌晨，OpenAI 员工 Thibault Sottiaux 在 X 发长帖称，OpenAI 正在为所有 Codex 和 ChatGPT Work 付费用户重置用量，并修复一组导致 Codex 消耗异常的后台问题。到本文写作时，本次采集没有看到 OpenAI 官方博客、状态页或帮助中心发布同等口径复盘，因此标题、摘要、claims 和正文都按“员工 X 单源称”处理。

可以确认的是，采集到的 X 长帖原文给出了具体清单：compaction 保留旧图片导致上下文膨胀，memory workers 继承 Stop hooks 后无法结束，/goal 在完成后继续运行或反复重试坏工具，automations 的部分自定义日程运行得比配置更频繁，subagents 可能选择更强助手，Computer History 会重复摘要重叠活动，rolling summaries 触发额外后台请求，MCP 工具结果可能被重复编码或重新拉取指令。原帖称这些问题已被 fixed 或 disabled。

不能确认的部分同样关键：没有正式公告说明受影响的付费计划列表、重置生效时间、历史账单是否追溯、企业管理员能否看到组织级补偿，也没有公开样本量和修复前后对照数据。OpenAI 官方 Codex README、MCP 文档和 long-running work 文档只能证明 Codex 的产品形态、MCP 和 /goal 等背景能力存在，不能证明这次用量重置本身。

对读者最直接的影响在开发者和团队采购侧。Codex 这类编码 Agent 的成本来自用户可见提问，也来自后台摘要、工具输出、自动任务、子 Agent、MCP 指令和历史压缩。当产品按周额度或团队额度销售时，计量透明度已经成为 Agent 产品能否被团队信任的核心能力。

原文措辞先核对

这条新闻最容易被写歪的地方，是把“修复浪费后可用量走得更远”写成“OpenAI再次上调用量”。原帖没有这样说。它的英文是：We are reseting usage for all paid users of Codex and ChatGPT Work. 这里的动作是重置用量，适用范围是 Codex 和 ChatGPT Work 的所有付费用户。它不是宣布一个永久的新额度档位，也不是说明所有人以后都会得到同样比例的增长。

第二个要保留的句子是：Depending on how you use Codex, you should see your usage go between 10% and 50% further than before. 这句话有两个限制。第一，改善幅度取决于 Codex 使用方式；第二，比较基准是修复前的使用体验。中文更稳妥的写法是“不同使用方式下，Codex 可比此前多跑 10%-50%”，而不是“所有用户额度提高 50%”。

原文或清单项	本文中文表述	不应写成	核查边界
reset usage for all paid users	重置Codex和ChatGPT Work付费用户用量	永久提高套餐额度	员工X单源，正式公告待确认
go between 10% and 50% further	取决于用法，可比此前多跑10%-50%	全员统一增加50%	没有公开样本和分位数
Compaction	旧图片保留导致上下文变大并再次触发压缩	模型上下文窗口扩大	只说明浪费被修复
Memory workers	后台memory workers可能继承Stop hooks并继续运行	记忆功能整体故障	员工称影响少于1%用户
Goals	/goal可能越过停止条件或重试坏工具	Goal模式不可用	个例消耗15%-70%周额度
Automations	部分自定义日程运行得比配置更频繁	所有自动化都失控	未给出影响比例
Subagents	小模型可能选择更强助手或改变fast模式	子Agent能力升级	描述的是预算和调度异常
Computer History	旧实现会重复摘要重叠活动	历史功能新增	个别案例最多约20%周额度
Rolling summaries	普通turn触发约1%额外后台请求	持续增加1%额度	原帖称已禁用
MCP	工具结果双重编码，指令被截断后再拉取	MCP全面故障	仅描述部分工具结果处理问题

发生了什么

按采集到的长帖，OpenAI 团队在处理“thousands of reports”后，发现许多小问题长期存在，并已经陆续修复。帖文把这些问题分成八类。第一类是 compaction：系统在压缩上下文时保留旧图片，部分场景会让上下文大到再次触发 compaction；对大量使用图片的用户，修复后用量下降 around 10%。第二类是 memory：后台 memory workers 可能继承 Stop hooks，如果 hook 阻止它结束，就会继续运行；员工称该问题影响少于 1% 用户，但长尾很差，见过一个 thread 检查能否停止 15000次。

第三类是 Goals，也就是 /goal 相关长任务。原帖称，在一些案例中，已经设置的 /goal 完成后仍越过预期停止条件继续走，或模型遇到坏工具后持续重试而不停止；OpenAI 看到的例子会消耗每周额度的 15%-70%。这不意味着 /goal 本身应该被避开；它说明长期运行任务必须有停止条件、工具失败退避和可审计的后台账本。

第四类是 automations：部分自定义 schedules 的执行频率超过配置。第五类是 subagents：较小模型，例如 Luna，可能在没有显式要求时选择更强的 helpers；原帖还称，当 orchestrating model 没有运行在 /fast mode 时，也可能请求 sub-agents 以 /fast 运行。第六类是 Computer History：旧实现可能反复总结重叠活动，部分案例每周消耗最高可到周额度的 one fifth，也就是约 20%。

第七类是 rolling task summaries：普通 turns 触发了额外后台请求，给 token usage 增加 about 1%。原帖说这项已经 disabled。第八类是 MCP：部分 tool results 可能被 encoded twice，也发现过 tool instructions 被 cut off 后再次 fetched。原帖最后称，团队也做了 architectural changes 来防止回归，如果发生不论如何都会 paged，并正在做直接在应用里展示用量去向的能力，让用户不必猜测。

配额问题背后的执行系统

如果只看“重置用量”四个字，它像一次客服式补偿。修复清单实际暴露的是 Agent 产品的计量问题：用户认为自己在和一个编码助手对话，系统实际运行的是多层执行体系。OpenAI 的 Codex README 把 Codex CLI 描述为运行在本机的 coding agent，并指向 IDE、desktop app 和 Codex Web；MCP 和 long-running work 文档则说明 Codex 还要处理外部工具、长任务和跨界面运行。这意味着 Codex 的成本账本天然比普通聊天复杂。

这种复杂性可以拆成三层。第一层是上下文层，compaction、Computer History 和 rolling summaries 都属于系统为了保持任务连续性而做的记录、压缩和摘要。它们提高可用性，但一旦重复、重叠或触发时机不对，就会把用户看不见的历史处理变成额度消耗。第二层是任务层，/goal、automations 和 subagents 都会让一次请求扩展成多轮、多步骤或多执行体。它们让 Agent 更像自动化工作流，也让停止条件、模型选择和执行频率必须进入预算控制。第三层是工具层，MCP 把外部工具和上下文接入 Codex；工具结果编码、指令获取和服务器说明如果处理不稳，会直接放大 token 和调用成本。

因此，“10%-50% further”不能被理解成简单的配额上调。若用户大量使用图片、MCP、长任务或后台自动化，修复浪费后确实可能感觉额度明显变耐用；若用户只是短对话写代码，改善可能接近低端。原帖的语义是不同使用形态的浪费被收敛，不是 OpenAI 把所有计划的官方 weekly allowance 增加同一比例。

对Codex产品形态的背景核查

本次新鲜事实来自员工 X 帖，但官方文档可以解释为什么这些问题集中爆发在 Codex 上。OpenAI Codex README 写明，Codex CLI 是 OpenAI 的本地 coding agent；用户可在 VS Code、Cursor、Windsurf 等编辑器中安装 IDE 体验，也可用 codex app 或 Codex Web。README 还写到推荐用 ChatGPT account 登录，把 Codex 作为 Plus、Pro、Business、Edu 或 Enterprise plan 的一部分使用。这个背景能支持“Codex 与 ChatGPT 计划绑定”的产品语境，但它不等于确认本次重置。

MCP 官方文档还说明，Model Context Protocol connects models to tools and context；ChatGPT desktop app、Codex CLI 和 IDE extension 支持 MCP servers，并共享同一个 Codex host 的 MCP 配置。它列出 STDIO servers、Streamable HTTP servers、server instructions 等支持项，并提醒 server instructions 的前 512 字符要自包含，因为 Codex 会用它来决定如何使用服务器。这与原帖中“MCP tool results 被双重编码、tool instructions 被截断后再获取”的问题直接相关：工具层信息如果重复进入上下文，就会成为账本噪音。

Long-running work 文档则说明，在 ChatGPT desktop app、Codex CLI 和 IDE extension 中都可通过 /goal 启动 Goal mode；ChatGPT web 的 hosted long-running work 则使用 ChatGPT Work，并把 outcome、constraints、review criteria 直接写进 prompt。这个背景让“/goal 完成后继续跑”更容易理解：长任务的产品价值来自持续工作，风险也来自持续工作。没有清晰停止条件、失败退避和可见账本时，后台执行就会从效率工具变成预算黑箱。

开发者和团队应怎样解读

开发者短期应把这条当作“配额体感解释”，而不是新套餐公告。如果你最近在 Codex 中大量使用图片、MCP、自动化、subagents 或长时间 /goal，这份清单能解释为什么用量掉得比预期快。若修复真的已经覆盖，未来同样任务可能会消耗更少额度。但因为公开证据仍是员工单源，团队不应基于这条 X 帖改预算模型，更不应把 10%-50% 写进采购承诺。

团队管理员更应该看的是 OpenAI 提到的下一步：直接在应用里展示 usage goes where。对企业来说，Agent 产品要被纳入研发流程，需要的不只是总额度，还要有可审计的分类账：前台用户 turn 用了多少，后台 compaction 和 summaries 用了多少，MCP 工具结果和指令用了多少，automation 是否按配置触发，subagents 调用了哪些模型，异常重试是否被熔断。没有这些字段，用户只能用“体感”判断产品是否浪费。

对工具生态来说，这条单源披露也给了一个信号：MCP、subagents、automation 和长期任务的竞争点正在从“能不能接入”变成“接入后能不能控制成本”。社区里出现 tokentab 这类读取 Claude Code、Codex 和 Gemini CLI session logs 来统计成本的工具，并不是偶然。用户正在把 Agent 当作可以长时间工作的执行系统，而执行系统必须有成本归因、失败回滚和审计日志。

接下来重点看三个信号

正式确认仍是第一道门槛。OpenAI 是否会在帮助中心、开发者博客或状态页给出复盘，确认“all paid users of Codex and ChatGPT Work”的实际范围，说明重置是一次性还是按受影响程度处理，并给出团队和企业管理员可查看的口径。如果没有正式材料，这条只能停留在员工沟通层。

应用内账本决定修复能否转化为信任。原帖说 OpenAI 正在让用户直接看到 usage goes where。真正有价值的账本需要拆开前台推理、compaction、Computer History、rolling summaries、MCP、automations、subagents、工具失败重试。只有能拆项，用户才知道该优化 prompt、关掉自动化、限制工具输出，还是申诉异常。

预算隔离会影响长任务采用。长任务和多 Agent 是 Codex 的核心卖点，但 /goal、automations 和 subagents 都需要单独的预算闸门。合理的产品形态应该允许用户给后台任务设置每次、每天、每周上限；允许团队禁止小模型自动选择更高成本 helpers；允许 MCP server instructions 和 tool results 有清晰截断策略。否则，能力越自动，账本越不可控。

这也是本文选择低置信写法的原因。新闻 peg 很新，细节很具体，但事实链仍短。OpenAI 员工帖能说明“他们声称修了什么”，官方 Codex 文档能说明“这些机制为什么存在”，二者加在一起足以构成一个值得跟踪的工程信号；它们还不足以构成对所有用户、所有套餐和未来额度政策的确定结论。