模型档位、推理强度与速度
模型选择不是“永远选最强”，速度也不是“把所有开关都调快”。一次 Codex 任务的实际体验，通常由四个变量共同决定：- 模型档位决定基础能力、工具使用能力和处理复杂代码的上限。
- 推理强度决定同一个模型愿意投入多少分析资源。
- 服务层级决定请求在服务端的速度优先级，以及可能增加的用量成本。
- 上下文和任务组织决定模型是否需要反复寻找信息、修正误解和重新执行。
先确认当前能力
在修改配置前，先确认你正在使用哪个 Codex、从哪里启动、当前账号能看到什么。不要直接把旧文章里的模型名写入配置，也不要把一次实验的结果当成所有入口都相同。
如果
/model、/status 或帮助中的名称与本文不同，以本机显示为准。遇到未知字段、无效值或模型不可用，不要连续猜字段名；先恢复到最小配置，再逐项验证。
一张决策表
先用任务的四个维度做判断，再决定模型和推理档位：- 范围：只改一个位置，还是跨多个模块和入口？
- 不确定性：根因明确，还是需要探索和假设验证？
- 错误代价：错了只是返工，还是会影响数据、权限、生产行为？
- 重复次数：偶尔执行一次，还是每天批量运行数十次？
这不是固定配方。正确做法是先选一个成本可接受的起点，跑一组代表任务，再根据“首次通过率、总耗时和人工修复时间”调整。只看模型回复的等待时间，会把返工成本隐藏起来。
模型档位怎么选
主力模型
主力模型适合复杂编程、跨文件修改、工具调用、代码审查、架构取舍和需要自己验证的工作。它不一定每次都最快，但当任务需要理解多个约束时，较高的一次命中率通常能减少往返。 适合使用主力模型的信号：- 你无法用一句话描述预期 diff；
- 根因尚未确定，需要读取代码、日志和测试；
- 修改会影响公共接口、数据格式、权限或并发行为；
- 需要比较多个方案并解释取舍；
- 轻量模型已经出现遗漏、重复试错或测试修复循环。
轻量模型
轻量模型适合边界清楚、结果容易机械验收的工作，例如批量清理 import、格式化、补简单断言、生成局部测试骨架或读取文件并提取固定信息。它的价值不只是单次便宜，而是可以承担更多相互独立的短任务。 使用前要给它明确文件范围和验收命令。一个“简单”任务如果需要它自行推断架构，就已经不再是轻量任务。轻量模型也不应默认承担安全审查、复杂迁移或最终设计决定。即时响应模型
某些版本提供专门优化即时反馈的模型或研究预览模型。它适合短问答、快速查看局部代码和高频小步迭代，但通常不应因为响应很快就承担高风险的最终修改。是否可用取决于账号和入口；在/model 中看不到时，不要修改配置强行启用。
不要依赖过时名称
旧教程中的模型名称可能已经弃用、改名或只在 API 侧可用。模型不可用时按下面顺序排查：- 在
/model查看当前账号实际可选列表。 - 查看
codex --help与官方模型文档的当前说明。 - 检查是 ChatGPT 登录、API key 还是其他提供方。
- 检查 profile、项目配置和命令行是否覆盖了模型。
- 将配置恢复为已确认可用的模型，再进行下一步实验。
推理强度是什么
model_reasoning_effort 控制支持推理的模型投入多少分析资源。它不是权限开关，也不是质量保证；高档位仍然可能理解错需求，低档位也可能正确完成简单任务。
常见档位从低到高大致包括：
档位可选范围依模型而不同。一个模型拒绝
xhigh，不代表配置语法错误；一个模型接受 medium，也不代表另一个模型会接受它。切换模型后应重新确认推理档位。
什么时候提高推理强度
出现以下情况时，先把当前模型提高一档，再考虑换模型：- 第一次方案忽略了已经提供的边界条件；
- 测试能通过，但实现没有解释清楚并发、错误恢复或兼容性；
- 模型在多个候选根因之间来回摇摆；
- 需要从较多文件中建立因果链，而不是只做局部编辑；
- 你愿意等待更久，但不想改变模型和上下文组织。
什么时候降低推理强度
以下任务通常可以降低档位：- 变更位置和目标都已明确；
- 预期 diff 很小且有现成测试；
- 任务可以按文件列表批量拆分；
- 失败后容易回滚，且不会触发外部副作用；
- 你在同一个短反馈循环里重复执行类似动作。
low 当成“更聪明地省钱”。如果降低档位导致多两轮纠错，总时间和总用量可能反而更高。
服务层级与快速模式
服务层级与推理强度解决的是不同问题：- 推理强度回答“模型投入多少分析资源”；
- 服务层级回答“请求以什么速度优先级处理”。
service_tier，常见值可能包含 flex 和 fast。flex 偏向弹性成本，fast 偏向响应速度；具体可用值、资格和是否需要 feature flag 必须查看当前版本说明。不要因为配置文件接受字符串就假设服务端使用了它。
可能的配置形态如下，仅用于说明验证思路：
/fast，应先查看：
- 提高沙箱权限；
- 绕过审批；
- 让过时模型重新可用；
- 自动缩短过长上下文；
- 替代测试和 diff 审查。
什么时候值得使用快速层级
适合开启快速层级的情况：- 你正在进行短而密集的交互式迭代；
- 延迟确实阻塞了人工决策；
- 当前模型和推理档位已经正确；
- 你能接受更高的 credit 或 API 成本；
- 任务不会因为追求响应速度而减少验证。
- 大量后台任务，对单次响应延迟不敏感；
- 还没有测过它是否真的改善端到端时间；
- 任务瓶颈是上下文、测试或并行冲突；
- 账户额度紧张，或成本上限不明确。
速度、成本和质量的真实账本
把一次任务的成本拆成四部分：
质量不能只用“回答是否看起来合理”衡量。对代码任务，至少需要一个可重复的验收信号：测试退出码、类型检查、构建结果、基准数值、diff 范围或人工审查清单。
配置层级与一次性实验
长期默认适合放在用户级config.toml，但实验应优先用命令行覆盖，避免一次试验改变所有项目。用户级配置通常位于：
codex --help 为准）：
-c 的值按 TOML 解析，字符串需要双引号。命令行覆盖通常只影响当前进程，不会改写配置文件。实验结束后启动一个普通会话，确认默认值没有被意外改变。
上下文减负：先减少无效计算
上下文管理经常比换模型更能改善端到端速度。模型需要处理的输入越多，找到关键事实、保持约束和复核结果就越困难。只提供相关材料
目标文件、直接依赖、失败测试和完整错误位置应优先进入上下文。不要为了“让模型了解项目”一次性提供整个仓库。可以先列目录和搜索，再读取命中的小范围文件。一个任务一个会话
同一问题的连续定位适合留在同一个会话，便于保留决策和失败尝试。不相关的需求应新开会话，不要让早期的 API 迁移讨论影响后面的 CSS 修改。 下面这些操作的语义不同：
会话长到出现重复读取、忘记约束、日志反复输出时，先保存状态，再使用当前版本支持的
/compact。压缩后重新核对目标、非目标、修改文件、测试结果和下一步。关键接口契约、失败原因和回滚点不要只依赖自动摘要。
什么时候新开而不是压缩
如果任务目标、模块或分支已经改变，新会话通常比继续压缩更清楚。压缩适合“仍然是同一个任务，只是过程太长”；新会话适合“要做另一项工作，或需要干净地重新评估”。并行提速：提高吞吐而不是制造冲突
并行适用于互相独立的工作单元，例如：- 分别为不同模块盘点测试缺口；
- 对不同目录做只读分析；
- 在一个隔离工作区实现功能，另一个隔离工作区运行基准；
- 主任务修改代码时，让子代理探索文档或检查独立测试。
- 每条线的输入、输出和文件边界明确。
- 写入任务使用独立 worktree、分支或目录。
- 汇总结果不会把大量重复日志塞回主会话。
fork 只复制会话上下文，不能代替 Git worktree。
一个可审查的并行布局：
基准实验一：同一任务比较推理档位
实验目标是测量档位变化，而不是证明某个档位永远最好。选择一个有真实验收命令、但可以重复运行的中等任务，例如给已有函数补边界测试并修复一个明确失败分支。不要使用生产数据、真实外部请求或会改变共享分支的任务。准备实验记录
low、medium 和模型支持的 high。每次使用新会话、相同工作区初始状态和相同任务文字。记录：
- 首次响应时间；
- 完成到验收通过的总时间；
- 读取和修改的文件数；
- 测试命令与退出码；
- 返工请求数；
- 你人工修正的分钟数；
- 状态中能看到的用量信息。
至少重复三次，或使用三项同难度任务。单次结果受服务排队、缓存和任务偶然性影响，不能据此修改全局默认。选择档位时比较总耗时和人工修正，而不是只比较首次响应。
基准实验二：模型档位和成本权衡
本实验固定推理强度，比较主力模型和轻量模型。任务必须可以拆成相同输入、相同验收的独立样本，例如对一组不相关文件执行同一种局部重命名或补测试。不要让两个模型修改同一工作区。基准实验三：服务层级是否真的提速
服务层级的实验应使用短任务和多个时间点。固定模型、推理档位、上下文和验收命令，只切换flex 与当前版本支持的快速层级。记录服务配置是否在 /status 中反映出来；如果状态看不出有效值，不能声称实验已成功切换。
动态版本核验清单
每次升级 Codex、切换登录方式、换账号、改变 profile 或发现行为变化时，重新做以下核验：三种可直接采用的工作配置
下面只展示决策形态。<模型> 必须替换为本地 /model 确认的名称，档位必须是该模型支持的值。
日常开发
批量机械任务
复杂分析或高代价变更
失败排查
模型切换后仍像旧模型
检查是否复用了旧会话、是否有 profile 或命令行覆盖，以及/status 显示的有效模型。重启一个新会话，用无害短任务确认，不要只根据界面标题判断。
推理档位报错
先确认模型支持的档位，再检查字符串拼写和参数位置。删除xhigh、none 等不确定值，回到已确认的 medium 或本地默认。模型支持范围改变时，重新阅读当前帮助。
配置写了但速度没有变化
服务层级可能未启用、需要 feature flag、账号不符合资格，或瓶颈根本不在模型等待。分别测量模型响应、工具执行、测试和人工审查时间；不要用“感觉更快”作结论。降档后返工变多
先比较总耗时和首次通过率。如果失败集中在上下文遗漏，缩小并补足输入；如果失败集中在边界推理，再提高档位或换主力模型。只调快模型而不改变任务描述，通常不能解决根因。并行后出现冲突
立即停止互相覆盖的写入任务，查看每个 worktree 的git status 和 diff。把任务按文件和职责重新隔离；不要用会话名称推断文件已经隔离。合并前逐条运行测试，确认结果来自正确的代码版本。
上下文压缩后质量下降
让 Codex 复述目标、约束、已验证结果和不确定项，并重新读取关键文件。必要时开新会话，把可验证状态写入任务记录。不要把关键接口或失败原因只依赖压缩摘要。一套日常操作顺序
每次遇到新任务，可以按下面顺序执行，但每一步都应结合实际任务缩短或展开：- 用范围、不确定性、错误代价和重复次数判断任务档位。
- 在
/model和/status中确认当前模型、推理和服务状态。 - 只提供相关文件、完整错误坐标和可执行验收，不把无关仓库塞入上下文。
- 先从主力模型 +
medium或轻量模型 +low开始。 - 若答案浅或漏边界，提高推理；若任务机械且稳定通过，降低档位或换轻量模型。
- 若等待确实是瓶颈，再对服务层级做一次可测量的临时实验。
- 可并行的独立任务使用 worktree 或只读子任务隔离。
- 用测试、构建、diff 和实际行为验收，而不是只看回复长度。
- 记录总耗时、返工、用量和失败类型，形成下一次选择的依据。
- 升级或换账号后重新执行动态版本核验。
最终验收
模型和速度配置完成后，至少确认：/model显示的模型确实是你要使用的模型；- 当前模型支持并实际接受所设置的推理档位；
- 服务层级或快速模式的状态已由本地状态、帮助或实验结果确认；
- 配置修改只发生在预期的配置文件，实验没有污染项目；
- 上下文只包含相关材料，没有秘密、客户数据和生成产物；
- 并行任务有文件或 worktree 隔离；
- 质量比较使用了测试、构建、diff 或基准，而不是主观“看起来更好”；
- 成本比较包含返工和人工审查，不只看模型单次价格；
- 未知模型、字段、档位和服务能力都标记为需动态核验。
小结
模型档位解决能力上限，推理强度解决投入多少分析，服务层级解决等待优先级，上下文和并行组织决定这些资源能否有效转化为结果。日常默认可以从主力模型 +medium + 弹性服务开始；边界清楚的批量任务再降到轻量模型和 low；高不确定性、高代价任务提高推理或换更强模型；快速层级只在测量证明等待是瓶颈、且成本可接受时使用。
最终选择依据应是端到端数据：首次通过率、总耗时、返工轮数、人工修正和实际用量。每次版本、账号或入口变化后，都回到 /model、/status、--help 和无害基准实验重新确认。
参考资料：参考/codex/30-models.md、参考/codex/31-speed.md、参考/codex/13-prompting.md。动态模型、推理档位、服务层级和命令以当前 Codex 版本及官方文档为准。