Codex 推理强度怎么选：UI 档位与配置取值是两套名字

2026-08-09

第一次想把 Codex（OpenAI Codex）的推理强度调高的人，多半会在同一个地方卡住：文档里讲用法时说的是 Light、Medium、Extra High，可翻到配置参考页，model_reasoning_effort 这个键接受的取值写的是 minimal、low、medium、high、xhigh。两边不是同一套字符串，而我们核对的这几个官方文档页里，没有给出两套名字的对照表。

这不是文档写漏了一段那么简单的事——它直接决定了你能不能把界面上试出来的手感原样搬进配置文件。下面先把两套名字摆清楚，再给一条从你自己的处境倒推出结论的路径。

一、两套名字，各自的原文

界面侧，官方《Models》页给出的档位与用法建议是这样的：

档位	官方给的适用场景
Light / Low	快任务
Medium	平衡
High、Extra High	需要多步的复杂任务

另有两个特殊模式：Max 是对单个问题启用扩展推理，Ultra 是派生子代理并行处理任务。

配置侧，config.toml 里的键与取值是这样的：

键	取值
`model_reasoning_effort`	`minimal` / `low` / `medium` / `high` / `xhigh`

看上去 medium 对 Medium、high 对 High 很顺理成章，但 minimal 对应界面上的哪一档、xhigh 是不是 Extra High、Max 和 Ultra 在配置里有没有落点——这些在我们核对的这几个官方文档页里都没有对照表，我也不打算替它推一个。写文章推错一个字，读者照抄进配置就是错的。所以本文的口径是：讲配置就只用配置侧的五个取值，讲界面就只引官方那几句用法建议，两边不互相翻译。

在选档原则上，官方倒是给了一句很干脆的话：选够用的最低档。这句话是后面整条决策路径的地基。

二、决策路径：先问自己四个问题

岔路 0：你要改的是哪一层？

这是最容易白忙一场的一步。推理强度在 Codex 里不止一个落点：

model_reasoning_effort：会话默认的推理强度
plan_mode_reasoning_effort：Plan 模式专用的推理强度覆盖
agents.default_subagent_reasoning_effort：子代理的默认推理强度

要注意的是：官方文档为 Plan 模式与子代理各给了一个独立的键——plan_mode_reasoning_effort、agents.default_subagent_reasoning_effort。这两个键在未设置时是否继承会话值，官方文档没有说明，我也不替它推。（作为对比，官方对 review_model 是明确写了「不设则继承会话模型」的；推理强度这两个键上没有这句话，所以只能算「未说明」，不能算「不继承」。）

这一点对排查的意义是：当你觉得「我明明调了，怎么感觉没变」，第一件事不是怀疑模型，而是确认你改的那个键，是不是当前正在跑的那条路径所读的那个键。三条路径各有各的键位，这是官方文档层面就能确认的事实。

改的方式也有三种粒度，从临时到长期：

# 只影响这一次调用：-c 覆盖配置文件里的值
codex -c model_reasoning_effort=high

-c, --config <key=value> 的官方说明是覆盖 ~/.codex/config.toml 里的值，点号路径表示嵌套（foo.bar.baz），value 按 TOML 解析，解析失败则按字面字符串处理。最后半句要留个心眼——写错了不一定会拦你，它可能就当字符串收下了。

想要一组固定搭配随时切换，用 profile：-p, --profile <CONFIG_PROFILE_V2> 会把 $CODEX_HOME/<name>.config.toml 叠加到基础用户配置之上。日常一个低档 profile、攻坚一个高档 profile，比每次敲 -c 省事。

要长期生效就写进 ~/.codex/config.toml：

model = "gpt-5.6-sol"
model_reasoning_effort = "high"

[agents]
default_subagent_reasoning_effort = "low"

以上为按官方文档键位组合的示例，未逐项实测，以官方文档为准。

岔路 1：这个活儿要不要改文件、要不要多步

官方对档位的用法建议只有三档粗粒度：快任务用 Light/Low，日常平衡用 Medium，需要多步的复杂任务用 High 与 Extra High。配合「选够用的最低档」这条原则，实操上的判断可以简化成一句话：任务是不是需要模型自己规划出好几步、并且中间一步错了后面全废。

读一段代码回答一个问题、按明确指令改一处、把命令行输出解释一遍，这类活儿的失败成本低、重试便宜，没有理由往高档上顶。真正值得升档的是那种「模型要先看懂现状、再决定动哪几个文件、还要保证彼此一致」的任务。

需要说清楚的是：我没有任何一档的耗时、token 消耗或效果对比数据——本文所依据的官方文档与本机只读命令输出里都没有这类数字，我们也没有发起过任何模型对话请求。所以你会看到我一直在讲「怎么选、怎么验证」，而不会看到「xhigh 比 medium 慢几倍、贵几倍」。任何带这种倍数的说法，你都该问一句数据从哪来。

岔路 2：跑在本地还是跑在 Codex cloud

这一步会直接砍掉一半选项，而且很多人是反过来做的——先纠结推理强度，最后才发现模型根本不由自己定。

官方《Models》页写得很明确：Codex cloud 自动选择模型，不是你在本地选什么云端就用什么。而且 gpt-5.6-terra 在 Codex cloud 上不可用，gpt-5.6-luna 在云端任务不可用，gpt-5.6-sol 才是全平台（含 API）可用的那一款。官方变更说明还提到，gpt-5.6-sol 现为符合条件客户的 Codex cloud 代码评审与 QA 的驱动模型。

所以结论是：如果你的工作流主要落在 Codex cloud，模型这一维基本轮不到你选，能调的只剩下你在本地那一侧的行为。反过来，如果你在本地 CLI 里跑，三档模型和五个推理强度取值才都在你手上。云端这部分是官方文档口径，我们没有实测。

顺带一提研究预览模型 gpt-5.3-codex-spark：官方定位是「纯文本」的研究预览，面向近乎即时的实时编码迭代，只出现在桌面应用与 CLI 两个面上，且仅 ChatGPT Pro 可用。它是研究预览，不是稳定档位，别把它排进日常选型的常规选项里。

岔路 3：预算卡在哪里

如果你的痛点是花销，那么优先级排序应该是先动模型，再动推理强度。理由只需要官方《Pricing》页积分单价表里的一行对比就够了：GPT-5.6 Sol 的输入单价是 125 credits / 1M tokens，GPT-5.6 Luna 的输入单价是 5 credits / 1M tokens——三档之间的输入单价差了 25 倍，输出侧（750 对 30）同样是 25 倍。（完整单价表这里就不整表照搬了，本篇只需要这一维；ChatGPT 官方定价页，2026-08-09 核对，以官方为准。）

选型时之所以要先看这一维，就是因为这个差距是量级级别的：一次「用 sol 还是用 luna」的判断，对账单的影响远大于你在同一个模型上把强度从 medium 挪到 high。而推理强度那一维——我们核对的这几个官方文档页里，没有给出任何按档位区分的单价，我也没有它的消耗数据，所以我给不出一个能和 25 倍并排放的量级。既然一维有硬数据、另一维只有原则，那就先按有数据的那一维决策。

在这种信息不对称下，理性的做法是：先按任务把模型选对（官方对 gpt-5.6-terra 的定位原文是「日常工作的平衡款，性能可与 GPT-5.5 竞争而成本更低」，gpt-5.6-luna 是「家族中成本最低的快速款」），再在选定模型上按「够用的最低档」调推理强度。反过来做——用最贵的模型配最低档去省钱——省不到点子上。

订阅侧还有一点值得放进决策：官方的用量口径是 messages（消息数），不是 token，窗口是 5 小时滚动窗口，而且同一档位下的区间跨度极大（Plus 是 10–2,000 messages / 5h，Pro 是 50–40,000 messages / 5h），官方明确说明这取决于模型（Pro 还取决于档位）。所以「我一天能跑多少」这个问题官方给的是一个随模型变化的区间，不是一个确定数。另外，Codex 包含在 ChatGPT Free 与 Go 中、以及 Plus/Pro/Business/Enterprise/Edu 速率上限翻倍，这些都是官方公告口径下的限时活动，不要当成常规权益来规划。

岔路 4：这台机器是不是你说了算

如果你在企业环境里，模型和策略未必由你的本地配置决定。官方在讲模型退役时点名了五处需要一起改的地方：workspace 默认模型、保存的模型设置、managed config（受管配置）、自定义 agent、计划任务（scheduled tasks）。判断依据很直白：只改交互界面里当前会话的模型是不够的，上面五处任何一处还写着旧模型都会出问题。

这里有个强时效的日期必须记住：官方原文是 GPT-5.4 与 GPT-5.4 mini 于 2026 年 8 月 31 日从 Codex 退役，迁移映射是 gpt-5.4 → gpt-5.6-terra、gpt-5.4-mini → gpt-5.6-luna；gpt-5.2 与 gpt-5.3-codex 已标记为 deprecated。以官方最新说明为准。

本机实测（codex-cli 0.147.0，Windows 11）：~/.codex/config.toml 里存在一段

[notice.model_migrations]
"gpt-5.3-codex" = "gpt-5.4"

说明 Codex 会把已确认过的模型迁移记在 notice.model_migrations 这张老名→新名映射表里。迁移提示是一次性确认的，确认过就不再提醒——所以「我没看到迁移提示」不等于你不需要迁移。企业环境里尤其要注意：managed config（受管配置）是官方在退役迁移里点名的五处之一，而本文没有受管环境可以实测，这一层具体怎么落地、由谁维护，只能问你们的管理员。

三、改完之后怎么确认它真的生效了

这是我认为比选档本身更值钱的一段。

第一步，先确认配置文件被加载了。 在 codex-cli 0.147.0（Windows 11）上，故意用 codex -c 'features=[unclosed' doctor --summary 传一段语法不合法的 TOML，命令没有崩溃退出，doctor 照常跑完，但输出里出现了这么一行：

✗ config       config could not be loaded - Fix the reported config error, then rerun codex doctor.

也就是说，配置坏了 Codex 不会拦你，它会带着「配置没加载成功」的状态继续跑。所以「我改完推理强度没感觉」的第一个动作，应该是跑一次 codex doctor --summary 看 Configuration 分组里 config 那一行是不是 loaded，而不是反复怀疑模型。

第二步，别指望 --strict-config 帮你抓拼写错误。 --strict-config 的官方说明是：config.toml 里出现本版本不认识的字段时直接报错退出。但在 codex-cli 0.147.0（Windows 11）上，执行 codex -c model_reasoning_effortt=high --strict-config exec --help（注意键名故意多打了一个 t）时，命令正常打印了 help，没有报未知字段错误。说明这个校验发生在真正加载配置去跑会话的时候，--help 这类不进入会话的路径不触发校验。别把它理解成「任何情况下都会拦住拼写错误」。

把这两条合起来看，验收顺序就清楚了：先 codex doctor --summary 确认配置加载成功，再在真正会进入会话的路径上验证——而不是用 --help 之类的空跑来「测试配置对不对」。

四、三个长得很像、但管的不是一回事的键

选档时最容易顺手改错的是它旁边这几个：

键	取值	它管什么
`model_reasoning_effort`	`minimal` / `low` / `medium` / `high` / `xhigh`	推理强度
`model_reasoning_summary`	`auto` / `concise` / `detailed` / `none`	推理摘要的详略
`model_verbosity`	`low` / `medium` / `high`	GPT-5 Responses API 的输出详略
`hide_agent_reasoning`	boolean	在 TUI 与 `codex exec` 输出里抑制推理内容

后三个改的是你看到多少，第一个改的才是它想多深。特别提醒 hide_agent_reasoning：它影响的是显示，别把它说成或当成能省钱的开关——这一点没有依据支撑。

五、什么情况下这条路径不适用

你跑在 Codex cloud 上：模型由云端自动选择，本地那套选型逻辑不成立，能调的只剩本地一侧的行为。云端与桌面应用部分我们没有实测，只能按官方文档口径说。
你在受管环境里：官方在 guardian_policy_config、auto_review.policy 这两个键上明确写了受管配置覆盖／优先于本地策略；但模型与推理强度这两个键是否同样被受管层覆盖，我们核对的官方文档里没有说明。所以别一个人在 ~/.codex/config.toml 里反复试，直接问管理员这台机器上哪些键归他们管。
你想要的是「哪一档效果更好」的量化答案：本文给不了。我们核对的这几个官方文档页里没有按档位区分的耗时、消耗或效果数据，我们也没有跑过真实对话任务。要这个答案只能你自己在真实任务上做 A/B，而且结论会随版本变。
你在追某个已经 deprecated 的模型的表现：gpt-5.2 与 gpt-5.3-codex 已标记 deprecated，GPT-5.4 家族 8 月 31 日退役，在这些模型上调出来的手感没有迁移价值。

最后收一句实操建议：把 model_reasoning_effort 当成一个默认值而不是一个开关。默认值按「够用的最低档」定在偏低的位置，遇到真正需要多步规划的活儿再用 -c 或 profile 临时顶上去。这样既不用每次纠结，也不至于让所有琐碎任务都按最重的姿势跑。