Codex CLI 的推理强度配置如何影响 Token 开销和执行速度？

Codex CLI 的推理强度越高，模型通常会在给出答案或执行操作前投入更多推理计算，因此可能消耗更多 reasoning token，并增加首个有效结果出现前的等待时间。反过来，降低推理强度通常有助于减少推理 token 和缩短响应时间。不过，这只是方向性的关系，不是固定倍率：从 medium 调到 high，并不意味着 token 或耗时必然增加某个确定百分比。

真正影响一次 Codex 任务成本与速度的因素不止一个。模型版本、输入上下文长度、缓存命中、工具调用次数、命令执行时间、网络状态、输出篇幅和任务是否返工，都会改变最终结果。因此，推理强度应当被视为质量、延迟与资源消耗之间的调节器，而不是一个可以脱离任务测量的“性能倍增开关”。

推理强度具体控制什么

Codex CLI 使用顶层配置键 model_reasoning_effort 控制模型的推理投入。常见档位包括 minimal、low、medium、high 和 xhigh，但具体模型支持哪些值，应以当前模型能力为准。未显式设置时，Codex 会采用模型或产品提供的默认值。

model_reasoning_effort = "medium"

推理 token 是模型在生成最终可见答案之前用于内部推理的输出 token。更高的 effort 通常允许模型进行更多分解、检查和路线比较。对于跨文件修改、复杂调试或存在多个约束的任务，这可能提高一次完成的概率；对于查找符号、修改文案或运行明确命令等简单任务，额外推理则可能没有可见收益。

需要区分三个相邻但不同的配置：model_reasoning_effort 控制推理投入，model_reasoning_summary 控制是否以及如何呈现推理摘要，model_verbosity 控制最终回答的详细程度。把回答写得更短，不等于模型使用了更少推理；显示详细摘要，也不能直接证明内部推理 token 按相同比例增长。

为什么更高档位通常更慢

一次 Codex 运行可能经历理解请求、形成计划、调用工具、读取结果、继续推理和生成答复等阶段。提高 effort 后，模型可能在工具调用之前进行更充分的分析，也可能在收到工具结果后做更多验证。即使最终可见答案同样长，前面的推理阶段也可能更久。

但墙上时钟时间不能全部归因于模型推理。测试、构建、下载依赖、浏览网页和等待外部服务，往往占据大量时间。例如两个任务分别使用 low 和 high，如果后者恰好命中了缓存、少跑了一次失败测试，它反而可能更早完成。只看一次运行的总秒数，无法得出稳定结论。

评估速度时至少应拆开以下指标：

• 从提交请求到首次出现有用文本或工具调用的时间；
• 模型思考与生成阶段的持续时间；
• 外部命令、测试和网络工具占用的时间；
• 从开始到任务达到验收标准的总时间；
• 首次结果失败后返工所增加的时间。

对真实开发工作而言，“达到验收标准的总时间”通常比“首次输出速度”更重要。低 effort 可能更快给出第一版，但若遗漏边界条件并导致多轮返工，整个任务反而更慢。

Token 开销应该怎么看

输入 token、缓存输入 token、可见输出 token 和 reasoning token 的含义不同。推理强度主要直接影响 reasoning token 的预算倾向，但它也可能间接改变工具调用数量、上下文累积和最终输出。一次代理任务会进行多轮模型调用，所以不能只看最后一条消息的长度。

在提供细分用量的接口或日志中，可以关注输出 token 明细里的 reasoning token。若使用的是 Codex 产品套餐，还应查看产品实际显示的用量或额度，而不能直接拿 API 单价乘 token，假定两种结算方式完全相同。API 计费、Codex 订阅额度和组织策略是不同层面的规则。

更高 effort 也不保证每次都使用更多 token。模型可能在较高档位更早发现正确路径，避免无效搜索；低档位也可能因为方向错误而反复读取文件和修改代码。因此，需要比较一批同类型任务的中位数和分位数，而不是依据单个样本。

各档位适合什么任务

minimal 或 low

适合边界明确、结果容易验证、失败代价较低的任务，例如查找定义、执行已知命令、调整格式、修改少量文案、进行机械性替换或回答简短事实问题。此类工作通常不需要长计划，降低 effort 更容易获得低延迟。

如果任务包含工具调用，即使看起来简单，也要确认所用模型在较低档位下仍能稳定调用工具。不要把另一个模型支持的最低档位直接套到当前模型。

medium

medium 通常适合作为团队基线。它适用于常规功能实现、范围清楚的缺陷修复、测试补充和中等规模重构。先以 medium 收集质量、延迟和 token 数据，再决定哪些任务可以下降到 low，哪些任务值得上调到 high。

high

high 更适合跨模块排错、复杂状态推演、安全敏感修改、数据迁移、并发问题或要求严格验证的任务。它的价值不在于“答案更长”，而在于允许模型投入更多推理来比较方案、检查假设和发现遗漏。

xhigh

xhigh 应保留给最困难、可异步等待且质量收益经过评测证明的任务。该档位并非所有模型都支持。即使模型接受它，也不代表所有任务都会优于 high；开放式任务还可能出现搜索过度、迟迟不收敛或做出不必要修改的情况。

如何在 Codex CLI 中切换并比较

长期默认值可以写入用户配置：

# ~/.codex/config.toml
model_reasoning_effort = "medium"

一次性比较时，使用命令行覆盖比反复编辑配置文件更清楚：

codex --config 'model_reasoning_effort="low"'
codex --config 'model_reasoning_effort="medium"'
codex --config 'model_reasoning_effort="high"'

命令行参数的优先级高于配置文件，适合临时实验。测试前应通过状态信息确认实际模型和 effort，避免用户配置、项目配置或 profile 改变了有效值。项目级 .codex/config.toml 仅在受信任项目中生效，也应纳入检查。

设计一组有效的 A/B 测试

推理档位评测最常见的问题是同时改变了模型、提示、仓库状态和任务内容。这样得到的差异无法归因。更可靠的方法是固定其他变量，只改变 effort。

1. 固定精确模型版本，不在测试中途自动切换模型。
2. 准备一组代表真实工作的任务，而不是只用一道演示题。
3. 每个任务从相同提交、相同依赖和相同工作区状态开始。
4. 使用完全相同的指令、工具权限和验收命令。
5. 分别以 low、medium、high 运行多次，并随机化顺序。
6. 记录推理 token、总 token、首次响应时间、总完成时间和工具调用数。
7. 由自动测试和人工检查共同判断任务是否真正完成。

同一任务需要重复运行，因为生成式模型存在波动，网络与工具耗时也会变化。结果应至少报告中位数；样本足够时，再观察较慢运行的高分位耗时。对于成功率，不要只看“脚本退出码为零”，还要检查功能、边界条件和改动范围。

一个实用的记录表

task_id,model,effort,success,reasoning_tokens,total_tokens,first_action_ms,total_ms,tool_calls,rework
T01,<model>,low,1,...
T01,<model>,medium,1,...
T01,<model>,high,1,...

记录时应保存任务版本和代码提交号。否则仓库变化后重新运行，数据已经不可比较。如果 Codex 环境没有暴露 reasoning token 明细，也不要根据可见文本长度伪造该数字；可以先比较产品可见用量、总耗时、工具次数和成功率，并明确指标限制。

用“合格任务成本”做决策

单次调用 token 少，并不等于业务成本低。更有意义的指标是“每个合格任务的资源消耗”：把一批运行的总 token 或总时间，除以最终通过验收的任务数。这样能把失败、返工和人工介入计算进去。

例如，low 平均用量较小但成功率明显下降，medium 可能在每次运行上稍贵，却以更少重试完成更多任务。此时 medium 的合格任务成本可能更低。反之，如果简单任务在 low 与 medium 的成功率相同，继续使用 medium 就是在支付没有测得收益的推理开销。

团队可以据此建立路由规则：

• 可机械验证、单文件、低风险任务默认 low；
• 常规编码与排错默认 medium；
• 跨模块、高风险或首次失败后的任务升级 high；
• 只有基准证明有收益时才使用 xhigh。

不要忽略缓存、上下文和工具成本

长对话中的上下文会随轮次增加。即使 effort 不变，后续调用的输入规模也可能更大。对于重复前缀，缓存可以显著改变实际输入成本和响应时间。比较档位时要固定会话策略，并分别记录缓存输入与非缓存输入，避免把缓存收益误判成 effort 收益。

工具调用也会放大差异。一次额外的全仓库搜索可能带来大量上下文；一次失败构建可能花费几分钟；网页和远程接口还受网络波动影响。测试报告应把模型等待和外部工具等待分开。否则，“high 比 low 慢”可能只是某次测试服务器较慢。

常见误区

误区一：档位与 token 呈固定比例

effort 是推理投入级别，不是精确 token 配额。不同任务、模型和运行即使使用相同档位，reasoning token 也可能差异很大。

误区二：更高一定更准确

高档位可能改善困难任务，但不会修复错误需求、缺少上下文或不可靠的验收标准。开放式工具权限与模糊停止条件还可能让高 effort 产生不必要探索。

误区三：最终回答短，所以成本低

可见回答只是一部分输出。模型可能生成了 reasoning token，也可能进行了多轮工具调用。应查看完整用量和任务轨迹。

误区四：只测首字延迟

Codex 是代理式开发工具。快速开始但多次返工的运行，未必比晚一点开始、一次完成的运行更高效。

误区五：把 API 价格等同于 Codex 套餐

API 使用量与 Codex 产品额度可能采用不同规则。讨论成本时必须先说明使用的是哪种产品、哪种账户和哪种计量口径。

什么时候应该调整档位

如果任务长期在低档位一次通过，且人工检查没有发现质量回退，可以保留下调。若出现漏改文件、忽略约束、工具路线反复或复杂推理错误，应将同类任务升级一档并重新评测。反过来，如果 high 与 medium 的成功率、缺陷率和返工率没有统计上有意义的差异，就没有理由长期承担额外等待。

模型升级后也要重新建立基线。不同模型的默认 effort、可用档位和推理效率可能变化，旧模型上得到的结论不能永久沿用。配置中最好显式写出模型和 effort，并把基准日期、任务集版本与测试结果一并保存。

结论

Codex CLI 的推理强度主要在速度、reasoning token 与复杂任务质量之间做权衡。降低 effort 通常更快并减少推理 token，提高 effort 通常给模型更多分析空间，但具体增幅不是固定比例，也不保证质量单调上升。最稳妥的策略是从 medium 建立基线，用真实任务同时测量成功率、reasoning token、总 token、首个动作时间、总完成时间和返工次数，再把简单任务下调到 low、困难任务升级到 high。只有当重复评测证明收益大于额外延迟与资源消耗时，才应长期使用更高档位。