> ## Documentation Index
> Fetch the complete documentation index at: https://aicoding.cscitech.top/llms.txt
> Use this file to discover all available pages before exploring further.

# 04-模型、推理强度与速度

> 根据任务难度选择 Codex 模型、推理强度和服务层级，并用上下文管理、并行执行与基准实验在速度、成本和质量之间做出可验证的取舍。

# 模型档位、推理强度与速度

模型选择不是“永远选最强”，速度也不是“把所有开关都调快”。一次 Codex 任务的实际体验，通常由四个变量共同决定：

1. **模型档位**决定基础能力、工具使用能力和处理复杂代码的上限。
2. **推理强度**决定同一个模型愿意投入多少分析资源。
3. **服务层级**决定请求在服务端的速度优先级，以及可能增加的用量成本。
4. **上下文和任务组织**决定模型是否需要反复寻找信息、修正误解和重新执行。

因此，速度、成本和质量不是三个互不相关的开关。一个过大的上下文可能让最快的模型反复返工；一个过低的推理档位可能省下几十秒，却多出几轮人工纠错；一个高优先级服务层级可能缩短等待，但并不会弥补错误的任务边界。

本页只讨论如何做这些选择、如何配置、如何测量，以及如何在 Codex 版本变化时重新确认。模型名称、可用档位、服务层级和命令行参数都可能随账号、入口、地区与版本变化，示例不能代替本地结果。

## 先确认当前能力

在修改配置前，先确认你正在使用哪个 Codex、从哪里启动、当前账号能看到什么。不要直接把旧文章里的模型名写入配置，也不要把一次实验的结果当成所有入口都相同。

```bash theme={null}
codex --version
codex --help
codex exec --help
```

进入交互会话后，优先查看：

```text theme={null}
/model
/status
/help
```

重点记录以下信息：

| 要确认的事实      | 为什么重要                               |
| ----------- | ----------------------------------- |
| 当前模型名称和版本   | 同名模型也可能因入口或版本改变行为                   |
| 当前推理强度      | 低档和高档的延迟、用量和答案深度不同                  |
| 可选推理档位      | `none`、`xhigh` 等并非所有模型都支持           |
| 服务层级和快速模式状态 | “已配置”不等于“当前会话已生效”                   |
| 登录方式和套餐     | ChatGPT 登录和 API key 的模型、计费、快速能力可能不同 |
| 当前上下文状态     | 过长的会话可能抵消模型或服务层级带来的速度收益             |

如果 `/model`、`/status` 或帮助中的名称与本文不同，以本机显示为准。遇到未知字段、无效值或模型不可用，不要连续猜字段名；先恢复到最小配置，再逐项验证。

## 一张决策表

先用任务的四个维度做判断，再决定模型和推理档位：

* **范围**：只改一个位置，还是跨多个模块和入口？
* **不确定性**：根因明确，还是需要探索和假设验证？
* **错误代价**：错了只是返工，还是会影响数据、权限、生产行为？
* **重复次数**：偶尔执行一次，还是每天批量运行数十次？

| 任务特征        | 模型方向        | 推理方向              | 关注指标         |
| ----------- | ----------- | ----------------- | ------------ |
| 范围明确、机械改动   | 轻量模型        | `low` 或更低         | 单次延迟、用量      |
| 单文件功能、普通测试  | 主力模型        | `medium`          | 质量与完成时间      |
| 跨模块设计、复杂调试  | 更强模型        | `high`            | 一次命中率、测试结果   |
| 高不确定性、错误代价高 | 更强模型        | `high` 或模型支持的最高档  | 漏洞、回归、审查时间   |
| 大量独立小任务     | 轻量模型或主力模型分工 | `low` / `medium`  | 吞吐量、并行冲突     |
| 高频问答、短反馈循环  | 支持即时响应的模型   | `minimal` / `low` | 首次响应时间、交互连续性 |

这不是固定配方。正确做法是先选一个成本可接受的起点，跑一组代表任务，再根据“首次通过率、总耗时和人工修复时间”调整。只看模型回复的等待时间，会把返工成本隐藏起来。

## 模型档位怎么选

### 主力模型

主力模型适合复杂编程、跨文件修改、工具调用、代码审查、架构取舍和需要自己验证的工作。它不一定每次都最快，但当任务需要理解多个约束时，较高的一次命中率通常能减少往返。

适合使用主力模型的信号：

* 你无法用一句话描述预期 diff；
* 根因尚未确定，需要读取代码、日志和测试；
* 修改会影响公共接口、数据格式、权限或并发行为；
* 需要比较多个方案并解释取舍；
* 轻量模型已经出现遗漏、重复试错或测试修复循环。

### 轻量模型

轻量模型适合边界清楚、结果容易机械验收的工作，例如批量清理 import、格式化、补简单断言、生成局部测试骨架或读取文件并提取固定信息。它的价值不只是单次便宜，而是可以承担更多相互独立的短任务。

使用前要给它明确文件范围和验收命令。一个“简单”任务如果需要它自行推断架构，就已经不再是轻量任务。轻量模型也不应默认承担安全审查、复杂迁移或最终设计决定。

### 即时响应模型

某些版本提供专门优化即时反馈的模型或研究预览模型。它适合短问答、快速查看局部代码和高频小步迭代，但通常不应因为响应很快就承担高风险的最终修改。是否可用取决于账号和入口；在 `/model` 中看不到时，不要修改配置强行启用。

### 不要依赖过时名称

旧教程中的模型名称可能已经弃用、改名或只在 API 侧可用。模型不可用时按下面顺序排查：

1. 在 `/model` 查看当前账号实际可选列表。
2. 查看 `codex --help` 与官方模型文档的当前说明。
3. 检查是 ChatGPT 登录、API key 还是其他提供方。
4. 检查 profile、项目配置和命令行是否覆盖了模型。
5. 将配置恢复为已确认可用的模型，再进行下一步实验。

不要把“模型名称能写进 TOML”当成“模型真的可调用”。有效性必须由启动、会话状态和一次无害请求共同确认。

## 推理强度是什么

`model_reasoning_effort` 控制支持推理的模型投入多少分析资源。它不是权限开关，也不是质量保证；高档位仍然可能理解错需求，低档位也可能正确完成简单任务。

常见档位从低到高大致包括：

| 档位        | 适合的工作              | 典型代价              |
| --------- | ------------------ | ----------------- |
| `none`    | 模型支持时用于直接执行和极短请求   | 几乎不做额外推理，复杂任务容易遗漏 |
| `minimal` | 即时问答、很短的局部操作       | 速度快，分析深度有限        |
| `low`     | 明确的小改动、批量机械任务      | 对隐含约束和边界覆盖较弱      |
| `medium`  | 日常编码和常规测试          | 速度与质量的平衡点         |
| `high`    | 跨模块重构、难定位 bug、设计比较 | 等待和用量上升           |
| `xhigh`   | 模型支持时用于最难的架构或推理任务  | 延迟最高，简单任务可能严重浪费   |

档位可选范围依模型而不同。一个模型拒绝 `xhigh`，不代表配置语法错误；一个模型接受 `medium`，也不代表另一个模型会接受它。切换模型后应重新确认推理档位。

### 什么时候提高推理强度

出现以下情况时，先把当前模型提高一档，再考虑换模型：

* 第一次方案忽略了已经提供的边界条件；
* 测试能通过，但实现没有解释清楚并发、错误恢复或兼容性；
* 模型在多个候选根因之间来回摇摆；
* 需要从较多文件中建立因果链，而不是只做局部编辑；
* 你愿意等待更久，但不想改变模型和上下文组织。

提高后必须重新运行相同的验证。不能用“回答更长”证明质量更高，应比较测试、diff、边界覆盖和人工修复时间。

### 什么时候降低推理强度

以下任务通常可以降低档位：

* 变更位置和目标都已明确；
* 预期 diff 很小且有现成测试；
* 任务可以按文件列表批量拆分；
* 失败后容易回滚，且不会触发外部副作用；
* 你在同一个短反馈循环里重复执行类似动作。

不要把 `low` 当成“更聪明地省钱”。如果降低档位导致多两轮纠错，总时间和总用量可能反而更高。

## 服务层级与快速模式

服务层级与推理强度解决的是不同问题：

* 推理强度回答“模型投入多少分析资源”；
* 服务层级回答“请求以什么速度优先级处理”。

一些 Codex 版本提供 `service_tier`，常见值可能包含 `flex` 和 `fast`。`flex` 偏向弹性成本，`fast` 偏向响应速度；具体可用值、资格和是否需要 feature flag 必须查看当前版本说明。不要因为配置文件接受字符串就假设服务端使用了它。

可能的配置形态如下，仅用于说明验证思路：

```toml theme={null}
# ~/.codex/config.toml
model = "<当前可用模型>"
model_reasoning_effort = "medium"
service_tier = "flex"
```

某些版本将快速能力与 feature flag 配合使用，形态可能类似：

```toml theme={null}
service_tier = "fast"

[features]
fast_mode = true
```

实际键名和默认值以本机配置参考为准。若会话内提供 `/fast`，应先查看：

```text theme={null}
/fast status
```

再按当前版本支持的形式临时打开或关闭。服务层级只改变排队和响应侧的取舍，不会：

* 提高沙箱权限；
* 绕过审批；
* 让过时模型重新可用；
* 自动缩短过长上下文；
* 替代测试和 diff 审查。

### 什么时候值得使用快速层级

适合开启快速层级的情况：

* 你正在进行短而密集的交互式迭代；
* 延迟确实阻塞了人工决策；
* 当前模型和推理档位已经正确；
* 你能接受更高的 credit 或 API 成本；
* 任务不会因为追求响应速度而减少验证。

不适合长期默认开启的情况：

* 大量后台任务，对单次响应延迟不敏感；
* 还没有测过它是否真的改善端到端时间；
* 任务瓶颈是上下文、测试或并行冲突；
* 账户额度紧张，或成本上限不明确。

## 速度、成本和质量的真实账本

把一次任务的成本拆成四部分：

```text theme={null}
总耗时 = 模型等待时间 + 工具执行时间 + 人工等待/审查时间 + 返工时间
总成本 = 模型用量成本 + 快速服务层级溢价 + 工具/环境成本 + 返工成本
```

模型等待只是第一项。对开发任务来说，返工时间往往更大。一个更快的轻量模型如果第一次通过率明显下降，最终可能比主力模型更慢、更贵。

建议至少记录这些指标：

| 指标      | 计算方法                 | 解释           |
| ------- | -------------------- | ------------ |
| 首次通过率   | 一次请求后验证通过的任务数 / 总任务数 | 质量和指令匹配度的近似值 |
| 端到端耗时   | 从发送请求到验证完成           | 包含工具和人工等待    |
| 模型等待时间  | 从请求到模型结果             | 观察模型和服务层级影响  |
| 返工轮数    | 达到验收前的修复请求数          | 上下文与推理选择的代价  |
| 人工修复分钟数 | 你为纠正结果投入的时间          | 不要遗漏隐性成本     |
| 单任务用量   | 本地状态或服务账单可见的用量       | 比单价更接近实际成本   |

质量不能只用“回答是否看起来合理”衡量。对代码任务，至少需要一个可重复的验收信号：测试退出码、类型检查、构建结果、基准数值、diff 范围或人工审查清单。

## 配置层级与一次性实验

长期默认适合放在用户级 `config.toml`，但实验应优先用命令行覆盖，避免一次试验改变所有项目。用户级配置通常位于：

```text theme={null}
Windows: %USERPROFILE%\\.codex\\config.toml
其他系统: ~/.codex/config.toml
自定义位置: $CODEX_HOME/config.toml
```

一个保守的默认示例：

```toml theme={null}
# ~/.codex/config.toml
model = "<已由 /model 确认的主力模型>"
model_reasoning_effort = "medium"
service_tier = "flex"
```

不要把未确认的模型名和实验字段直接复制进去。一次性实验优先采用当前版本支持的命令行形式，例如：

```bash theme={null}
codex -c model='"<已确认模型>"' \
  -c model_reasoning_effort='"low"'
```

或者使用专用参数（参数名以 `codex --help` 为准）：

```bash theme={null}
codex --model <已确认模型>
```

`-c` 的值按 TOML 解析，字符串需要双引号。命令行覆盖通常只影响当前进程，不会改写配置文件。实验结束后启动一个普通会话，确认默认值没有被意外改变。

## 上下文减负：先减少无效计算

上下文管理经常比换模型更能改善端到端速度。模型需要处理的输入越多，找到关键事实、保持约束和复核结果就越困难。

### 只提供相关材料

目标文件、直接依赖、失败测试和完整错误位置应优先进入上下文。不要为了“让模型了解项目”一次性提供整个仓库。可以先列目录和搜索，再读取命中的小范围文件。

```text theme={null}
先读取 src/auth/session.ts、tests/auth/session.test.ts 和这段完整错误日志。
不要扫描 node_modules、dist、构建产物、.env 或无关目录。
```

文件引用、IDE 当前选区和完整 traceback 比二手概括更可靠，但原始材料也应截断无关部分。日志只保留能定位问题的时间段、请求 ID 和堆栈；不要把令牌、Cookie 或客户数据贴入会话。

### 一个任务一个会话

同一问题的连续定位适合留在同一个会话，便于保留决策和失败尝试。不相关的需求应新开会话，不要让早期的 API 迁移讨论影响后面的 CSS 修改。

下面这些操作的语义不同：

| 操作         | 作用              | 不解决的问题         |
| ---------- | --------------- | -------------- |
| `resume`   | 找回原会话继续工作       | 不会自动确认当前目录和工作区 |
| `fork`     | 从当前上下文尝试另一条路线   | 不会自动隔离磁盘文件     |
| `/compact` | 压缩较早对话，释放窗口     | 不保证保留每个旧工具输出   |
| 新会话        | 清除无关历史，重新给相关上下文 | 不会自动继承未写入文件的决定 |

会话长到出现重复读取、忘记约束、日志反复输出时，先保存状态，再使用当前版本支持的 `/compact`。压缩后重新核对目标、非目标、修改文件、测试结果和下一步。关键接口契约、失败原因和回滚点不要只依赖自动摘要。

### 什么时候新开而不是压缩

如果任务目标、模块或分支已经改变，新会话通常比继续压缩更清楚。压缩适合“仍然是同一个任务，只是过程太长”；新会话适合“要做另一项工作，或需要干净地重新评估”。

## 并行提速：提高吞吐而不是制造冲突

并行适用于互相独立的工作单元，例如：

* 分别为不同模块盘点测试缺口；
* 对不同目录做只读分析；
* 在一个隔离工作区实现功能，另一个隔离工作区运行基准；
* 主任务修改代码时，让子代理探索文档或检查独立测试。

并行前先检查三个条件：

1. 每条线的输入、输出和文件边界明确。
2. 写入任务使用独立 worktree、分支或目录。
3. 汇总结果不会把大量重复日志塞回主会话。

同一个工作区让多个代理同时写文件，不能算提速。它可能造成互相覆盖、锁文件冲突、测试结果失真和无法判断改动来源。`fork` 只复制会话上下文，不能代替 Git worktree。

一个可审查的并行布局：

```text theme={null}
主 worktree：实现核心改动，只修改 src/core/ 和对应测试
review worktree：只读检查接口、错误处理和回归风险
benchmark worktree：运行固定基准，不修改源代码
```

汇总时只带回结论、命令、退出码和关键数值，不要把三个代理读取过的完整文件重复贴入主会话。并行的收益应以“总完成时间”和“冲突后的额外时间”比较，而不是以启动了多少代理计算。

## 基准实验一：同一任务比较推理档位

实验目标是测量档位变化，而不是证明某个档位永远最好。选择一个有真实验收命令、但可以重复运行的中等任务，例如给已有函数补边界测试并修复一个明确失败分支。不要使用生产数据、真实外部请求或会改变共享分支的任务。

### 准备实验记录

```text theme={null}
实验 ID：reasoning-01
日期：填写实际日期
Codex 版本：codex --version 的结果
入口：CLI / IDE / App
模型：/model 显示的完整名称
任务：固定的一句话需求
验收：固定测试命令和预期结果
变量：只改变 model_reasoning_effort
```

分别运行 `low`、`medium` 和模型支持的 `high`。每次使用新会话、相同工作区初始状态和相同任务文字。记录：

* 首次响应时间；
* 完成到验收通过的总时间；
* 读取和修改的文件数；
* 测试命令与退出码；
* 返工请求数；
* 你人工修正的分钟数；
* 状态中能看到的用量信息。

结果表可以这样写：

| 档位       | 首次响应 | 总耗时 | 返工轮数 | 测试    | 人工修正 | 用量 |
| -------- | ---: | --: | ---: | ----- | ---: | -: |
| `low`    |   填写 |  填写 |   填写 | 通过/失败 |   填写 | 填写 |
| `medium` |   填写 |  填写 |   填写 | 通过/失败 |   填写 | 填写 |
| `high`   |   填写 |  填写 |   填写 | 通过/失败 |   填写 | 填写 |

至少重复三次，或使用三项同难度任务。单次结果受服务排队、缓存和任务偶然性影响，不能据此修改全局默认。选择档位时比较总耗时和人工修正，而不是只比较首次响应。

## 基准实验二：模型档位和成本权衡

本实验固定推理强度，比较主力模型和轻量模型。任务必须可以拆成相同输入、相同验收的独立样本，例如对一组不相关文件执行同一种局部重命名或补测试。不要让两个模型修改同一工作区。

```text theme={null}
A 组：主力模型 + medium
B 组：轻量模型 + medium
任务数量：每组至少 5 个独立样本
固定项：任务说明、文件快照、测试命令、超时
记录项：完成率、总分钟、返工数、用量、失败类型
```

用下面的思路计算一个粗略的“有效成本”：

```text theme={null}
有效成本 = 模型用量成本 + 人工修正分钟 × 你的时间单价
```

不要把这个数字当成财务账单，它的用途是让隐性返工可见。轻量模型若适合批量机械任务，往往有较高吞吐；若任务包含隐含架构约束，主力模型的一次通过率可能更重要。

按失败类型分类，而不是只写“失败”：

| 失败类型   | 说明        | 调整方向        |
| ------ | --------- | ----------- |
| 找错文件   | 范围或上下文不足  | 缩小并明确文件范围   |
| 漏掉边界   | 推理或验收不足   | 提高推理，补可执行测试 |
| 过度修改   | 约束和非目标不清  | 明确只改哪些文件    |
| 测试环境问题 | 与模型能力无关   | 固定依赖和运行环境   |
| 服务延迟   | 排队或服务层级影响 | 比较服务层级或错峰执行 |

## 基准实验三：服务层级是否真的提速

服务层级的实验应使用短任务和多个时间点。固定模型、推理档位、上下文和验收命令，只切换 `flex` 与当前版本支持的快速层级。记录服务配置是否在 `/status` 中反映出来；如果状态看不出有效值，不能声称实验已成功切换。

```text theme={null}
实验 A：service_tier = flex
实验 B：service_tier = fast（仅在账号和版本支持时）
每组：至少 5 次独立请求
记录：排队/首次响应、总耗时、用量或 credit、验收结果
```

比较中位数，而不是只看最快一次。若快速层级只让模型等待减少少量时间，却显著增加用量，那么它可能只适合交互式高峰，不适合批量任务。若端到端时间几乎不变，瓶颈可能在测试、上下文读取、网络或人工审查。

服务层级实验不能使用需要外发真实数据的任务，也不能通过关闭审批或沙箱来制造“更快”的假象。速度优化不改变安全边界。

## 动态版本核验清单

每次升级 Codex、切换登录方式、换账号、改变 profile 或发现行为变化时，重新做以下核验：

```text theme={null}
1. codex --version
2. codex --help
3. codex exec --help
4. 进入会话执行 /model、/status、/help
5. 确认模型实际可选列表
6. 确认该模型支持的推理档位
7. 确认 service_tier 或 /fast 的当前支持状态
8. 用无害短任务验证一次配置
9. 用 git diff --check 和测试确认实验没有污染代码
```

检查配置时，先备份再改动，并保留最小字段。TOML 能解析不代表 Codex 认识字段；未知字段可能被忽略、警告或在新版本中变成错误。出现配置报错时，删除最近增加的实验字段，确认基础配置能启动，再按官方当前说明逐项加回。

建议在个人记录中保存：

```text theme={null}
Codex 版本：
账号/入口：
可用模型：
模型支持的推理档位：
service_tier 可选值：
快速模式启用方式：
默认配置路径：
实验日期与结果：
```

不要把 token、Cookie、内部 URL、客户数据或完整的敏感日志写入这份记录。

## 三种可直接采用的工作配置

下面只展示决策形态。`<模型>` 必须替换为本地 `/model` 确认的名称，档位必须是该模型支持的值。

### 日常开发

```toml theme={null}
model = "<主力模型>"
model_reasoning_effort = "medium"
service_tier = "flex"
```

适合普通功能、测试和局部调试。遇到复杂问题时在当前会话临时提高推理，而不是永久把所有任务锁在最高档。

### 批量机械任务

```toml theme={null}
model = "<轻量模型>"
model_reasoning_effort = "low"
service_tier = "flex"
```

只适用于文件边界、改动模式和验收命令都明确的批量任务。每条并行线使用独立目录，完成后统一检查 diff 和测试。

### 复杂分析或高代价变更

```toml theme={null}
model = "<主力模型>"
model_reasoning_effort = "high"
service_tier = "flex"
```

先用只读或计划阶段确认范围，随后再允许写入。复杂不等于应该开启快速层级；先保证上下文精准和验证完整，再判断等待时间是否值得用服务层级换取。

如果你要试验快速服务，优先用命令行临时覆盖或会话内开关，实验完成后恢复默认。不要把高成本快速模式和最高推理强度一起写成机器级默认，除非已经用真实工作负载测过且明确接受额度消耗。

## 失败排查

### 模型切换后仍像旧模型

检查是否复用了旧会话、是否有 profile 或命令行覆盖，以及 `/status` 显示的有效模型。重启一个新会话，用无害短任务确认，不要只根据界面标题判断。

### 推理档位报错

先确认模型支持的档位，再检查字符串拼写和参数位置。删除 `xhigh`、`none` 等不确定值，回到已确认的 `medium` 或本地默认。模型支持范围改变时，重新阅读当前帮助。

### 配置写了但速度没有变化

服务层级可能未启用、需要 feature flag、账号不符合资格，或瓶颈根本不在模型等待。分别测量模型响应、工具执行、测试和人工审查时间；不要用“感觉更快”作结论。

### 降档后返工变多

先比较总耗时和首次通过率。如果失败集中在上下文遗漏，缩小并补足输入；如果失败集中在边界推理，再提高档位或换主力模型。只调快模型而不改变任务描述，通常不能解决根因。

### 并行后出现冲突

立即停止互相覆盖的写入任务，查看每个 worktree 的 `git status` 和 diff。把任务按文件和职责重新隔离；不要用会话名称推断文件已经隔离。合并前逐条运行测试，确认结果来自正确的代码版本。

### 上下文压缩后质量下降

让 Codex 复述目标、约束、已验证结果和不确定项，并重新读取关键文件。必要时开新会话，把可验证状态写入任务记录。不要把关键接口或失败原因只依赖压缩摘要。

## 一套日常操作顺序

每次遇到新任务，可以按下面顺序执行，但每一步都应结合实际任务缩短或展开：

1. 用范围、不确定性、错误代价和重复次数判断任务档位。
2. 在 `/model` 和 `/status` 中确认当前模型、推理和服务状态。
3. 只提供相关文件、完整错误坐标和可执行验收，不把无关仓库塞入上下文。
4. 先从主力模型 + `medium` 或轻量模型 + `low` 开始。
5. 若答案浅或漏边界，提高推理；若任务机械且稳定通过，降低档位或换轻量模型。
6. 若等待确实是瓶颈，再对服务层级做一次可测量的临时实验。
7. 可并行的独立任务使用 worktree 或只读子任务隔离。
8. 用测试、构建、diff 和实际行为验收，而不是只看回复长度。
9. 记录总耗时、返工、用量和失败类型，形成下一次选择的依据。
10. 升级或换账号后重新执行动态版本核验。

## 最终验收

模型和速度配置完成后，至少确认：

* `/model` 显示的模型确实是你要使用的模型；
* 当前模型支持并实际接受所设置的推理档位；
* 服务层级或快速模式的状态已由本地状态、帮助或实验结果确认；
* 配置修改只发生在预期的配置文件，实验没有污染项目；
* 上下文只包含相关材料，没有秘密、客户数据和生成产物；
* 并行任务有文件或 worktree 隔离；
* 质量比较使用了测试、构建、diff 或基准，而不是主观“看起来更好”；
* 成本比较包含返工和人工审查，不只看模型单次价格；
* 未知模型、字段、档位和服务能力都标记为需动态核验。

## 小结

模型档位解决能力上限，推理强度解决投入多少分析，服务层级解决等待优先级，上下文和并行组织决定这些资源能否有效转化为结果。日常默认可以从主力模型 + `medium` + 弹性服务开始；边界清楚的批量任务再降到轻量模型和 `low`；高不确定性、高代价任务提高推理或换更强模型；快速层级只在测量证明等待是瓶颈、且成本可接受时使用。

最终选择依据应是端到端数据：首次通过率、总耗时、返工轮数、人工修正和实际用量。每次版本、账号或入口变化后，都回到 `/model`、`/status`、`--help` 和无害基准实验重新确认。

参考资料：`参考/codex/30-models.md`、`参考/codex/31-speed.md`、`参考/codex/13-prompting.md`。动态模型、推理档位、服务层级和命令以当前 Codex 版本及官方文档为准。