Codex 5.6 token消耗测试：文档误读及正确设置

背景

近期 LINUX DO · AI 板块出现了一则关于 codex 5.6 版本 token 消耗的讨论。有用户发帖称，当上下文长度超过 272k 时，额度消耗会翻倍，引发了不少关注和担忧。为了验证这一说法，原文作者进行了一系列测试和分析，并分享了实测结论以及针对子代理（ultra 子代理）高消耗问题的优化配置方案。

核心内容

原文作者指出，该说法来源于对 codex 文档的误读——原贴中的截图实际是针对 API 的情况，而非 codex 5.6 CLI（Command Line Interface）版本。codex 5.6 版本好不容易才支持了 372k 上下文长度，如果人为设置为 272k 提前触发压缩，效果只会大打折扣。

作者通过实际分析 rollout 结果（使用 codex cli pro20）证实，在 CLI 模式下额度消耗基本是恒定的，并不随上下文长度超过 272k 而翻倍。但需要注意的是，如果使用中转（proxy/relay）服务，消耗速度会更快，一旦续不上就会触发全量重放，造成更大的 token 浪费。

关于 ultra 子代理额度消耗过大的问题，作者认为这属于架构设计问题：codex 的 fork 架构默认每个子代理都会全量继承父代理的会话上下文，并且支持套娃（子代理再创建子代理）。正确的做法不是关闭 multi_agent 功能，而是在 config.toml 文件中加入如下配置：

[features.multi_agent_v2]
usage_hint_text = '子代理派发：message 必须包含目标、范围、相关文件或已知事实、验收标准和返回格式。自包含任务传 fork_turns="none"；仅依赖最近决策时传 "3"；不得省略或传 "all"。并行任务不得修改同一文件。完成时仅返回结论、证据或改动、验证和阻塞项；需要澄清用 send_message，需要继续执行用 followup_task，子代理不得调用 spawn_agent；除非父任务明确要求继续创建子代理。'

作者个人实测认为该配置效果不错，但同时也表示具体效果随缘，因人而异。

关键要点

• 272k 阈值翻倍说法是文档误读：原帖引用的文档针对 API 模式，codex 5.6 CLI pro20 版本的 token 消耗是恒定的，并不随上下文超限而翻倍。
• 中转服务消耗更快：使用中转时，若续费不及时会触发全量重放，导致 token 浪费加剧，用户需特别注意。
• ultra 子代理高消耗源于架构：fork 架构下子代理默认全量继承父代理上下文，且支持嵌套套娃，是消耗大的根本原因。
• 优化方案不关闭 multi_agent：通过 config.toml 的 [features.multi_agent_v2] 配置 usage_hint_text，可以约束子代理的任务描述、上下文继承长度（如传 "3" 表示仅继承最近 3 轮决策）和禁止子代理再 spawn_agent，从而控制 token 开销。
• 效果因人而异：作者表示该配置实测“基本美好”，但具体效果随机性较大，用户需结合自身场景测试。

意义与影响

该帖及时纠正了对 codex 5.6 token 消耗机制的误解，避免了用户因错误信息而人为缩小上下文窗口，降低了模型压缩带来的性能损失。同时，针对 ultra 子代理的高消耗问题，提供了一个不关闭 multi_agent 的优化方案，有助于用户在保持多代理协作能力的前提下控制 token 成本。对于频繁使用 codex 且关心额度的开发者，这一配置可降低实际开销，并间接引导更规范的子代理任务设计（如明确目标、范围、验收标准等），提升整体产出质量。此外，帖子也提醒了中转服务的潜在风险——续费不及时会导致全量重放，增加不必要的消耗。