最近，不少 Codex 用户发现自己的额度消耗速度比以往快了不少。OpenAI Codex 负责人 Tibo Sottiaux 在排查后给出了阶段性结论：模型本身没有变化，但用户实际感受到的 usage 却在上升。原因分散在缓存命中率、长会话压缩、图片处理、会话标题生成等多个环节。
这次风波看起来是一次“额度变贵”的抱怨，实际上暴露了 Agent 产品在系统层面的成本结构。过去大家习惯了“一次提问等于一次推理”的直觉，但编码智能体本质上是一个持续运行的循环：模型判断、工具执行、结果回填、再判断，循环往复。用户只提交了一个任务，后台可能已经跑了几十次模型调用。
额度异常背后：不是模型涨价，而是系统开销显形
Tibo Sottiaux 的排查更新提到几个关键点：本周部分用户的缓存命中率低于往常；经过多次压缩的长会话在图片处理上效率不佳；Computer History 在 p95+ 场景下消耗偏高；自动生成会话标题也增加了额外开销。OpenAI 团队表示会集中修复，并为付费订阅执行 usage reset。
这些细节说明，用户感知到的 usage 并不是“模型调用价格”的简单映射。Prompt 如何组织、缓存能否复用、上下文何时压缩、工具返回多少信息，都会被计入最终消耗。换句话说，模型还是那个模型，但 Agent 跑完一次任务的系统路径，决定了用户要付多少“代价”。
同一个模型，为什么能跑出完全不同的账单？
普通聊天场景中，用户问一句，模型答一句，成本容易预估。Coding Agent 则不同：比如让 Codex 修一个 Bug，它往往要先在代码库里搜索定位，再读取相关文件，生成补丁，然后跑测试。测试一旦失败，新的报错信息会再次进入上下文，模型必须继续决策。OpenAI 在技术文档中拆解过 Codex Agent Loop，在一次 turn 内部，模型推理、工具调用、结果回填、再次推理可能反复出现，复杂任务甚至会出现几十次 Responses API 往返。
因此，两个用户即使使用同一个模型，如果任务路径不同、工具调用次数不同、上下文积累量不同，最终 usage 也会出现明显差异。同样是修 Bug，一个 Agent 只加载必要上下文，缓存命中稳定；另一个反复读取历史、工具输出不断膨胀、还要经历多次压缩，最终账单自然不同。这不是模型“变贵”，而是 Agent 的系统行为放大了资源消耗的波动。
缓存命中率与压缩：Agent 成本的新战场
长任务要面对的第一问题，就是上下文不断膨胀。Codex 会把历史消息和工具调用一并带入后续请求，导致 Prompt 越堆越长。Prompt Cache 的核心逻辑是：只要新请求的前缀与之前计算过的内容完全一致，就能复用已有结果，避免重复计算。一旦图片、工具定义或前缀结构发生变化，缓存可能失效，系统需要重新处理更多上下文。
当 Context 快要触顶时，Codex 会启动 Compaction，把已有会话压缩成更精简的状态，再接着往下跑。这个机制让 Agent 可以工作更久，但也带来了新的取舍：什么时候压缩、保留哪些信息、后续是否需要重新获取。这次排查中，“长会话 + 多次 Compaction + 图片”被确认是一类效率问题，正好说明了压缩与缓存的复杂性。
一个值得注意的结论是：更大的上下文窗口并不必然带来更高效率。关键是上下文如何进入、如何复用、如何压缩。系统设计的好坏，正在成为比模型参数更现实的成本变量。
该算的不是 Token 单价，而是任务总成本
模型价格仍然重要，但当 Agent 开始承担长任务并进入生产环境后，只看输入、输出 Token 的标价已经不够。OpenAI 对 Codex Harness 的官方描述显示，Web、CLI、IDE 和桌面端在底层共用同一套 Harness，它负责 Agent Loop、Thread 生命周期与持久化、配置与认证、工具执行和扩展。也就是说，Harness 不是模型外面的一层“壳”，而是真正决定任务如何被执行的运行系统。
优化对象因此从“选哪个模型”扩展到整条执行链：如何拆分任务、在什么时机调用模型、携带多少上下文、哪些内容可以缓存、工具结果该返回多少、何时进行压缩。最终该比较的，不是每百万 Token 的单价，而是完成一个真实任务需要消耗多少资源。
这次 Codex 额度风波，本质上是一次产品效率问题，却把 Agent 过去隐藏在后台的系统开销摆到了台面上。模型厂商还会在每百万 Token 的价格上继续竞争，Model Routing 也依然重要，但 Agent 的成本战，已经开始进入系统工程阶段。正如一句话所说：“模型决定 Agent 有多聪明；系统决定这份聪明需要被调用多少次。”