**先说结论：**Codex 降低成本的关键，不是把所有任务都换成最便宜的模型，而是让高能力模型负责需求理解、规划和复杂决策，让成本更低、速度更快的模型承担高频执行、子 Agent 与代码审查。当前 Codex 已提供主模型、review_model 和默认子 Agent 模型等配置字段，一次设置后即可长期复用。

Codex 的站内介绍与官方入口：Codex – AI 编程智能体。本文以 GPT-5.6 Sol 与 GPT-5.6 Luna 为示例；实际可用模型、费用和额度取决于账号、套餐与所用 Provider。

Codex 成本优化的核心：规划、执行、审查按能力分工

一、为什么“全程使用最强模型”容易浪费预算？

一项看似简单的 Codex 任务，通常包含多个难度不同的阶段：

1. **主对话与规划：**理解目标、读取上下文、拆分任务、选择实现路线并协调执行。
2. **子 Agent 执行：**修改文件、补代码、跑测试、搜索资料或完成一个边界清晰的子任务。
3. **Review：**通过 /review 检查代码差异、发现风险并提出修改建议。
4. **Compact：**上下文过长时进行压缩，保留继续工作需要的信息。

这些阶段对推理能力的要求不同。如果每一步都使用最昂贵的模型，就相当于让高级架构师长期承担机械修改和重复检查。真正有效的优化，是把预算集中在方向判断和复杂取舍上。

从任务输入到主模型、子Agent、Review和Compact的工作链路

二、当前推荐的模型分工

环节	示例模型	推荐理由
主对话	GPT-5.6 Sol	适合复杂推理、规划与编码决策
/review	GPT-5.6 Luna	边界明确、调用频率较高
默认子 Agent	GPT-5.6 Luna	适合成本敏感、高并发执行
Compact	随当前实现与主会话	当前没有独立的 compact 模型配置项

这不是固定答案。若任务涉及架构重构、安全审计、复杂并发或模糊需求，子 Agent 和 Review 也可能需要更强模型。正确方法是先设一个默认分工，再根据任务风险显式升级。

不同工作环节的模型选择与作用

三、最简单的配置：一个 config.toml 完成主模型、Review和子Agent分工

用户级配置文件位置：

• macOS / Linux：~/.codex/config.toml
• Windows：C:Users<用户名>.codexconfig.toml

推荐先使用当前官方字段完成最小配置：

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

[agents]
default_subagent_model = "gpt-5.6-luna"
default_subagent_reasoning_effort = "medium"

这几项分别控制：

• model：新会话默认主模型。
• model_reasoning_effort：主模型推理强度，复杂任务可设为 high。
• review_model：执行 /review 时使用的模型；它不是所有“审查类提示词”的全局自动路由。
• agents.default_subagent_model：未显式指定模型时，子 Agent 默认使用的模型。
• agents.default_subagent_reasoning_effort：未显式覆盖时，子 Agent 的默认推理强度。

**重要修正：**只在 ~/.codex/agents/ 新建一个 worker.toml，并不会自动让所有子 Agent 使用它。最省事的方法是使用上面的 agents.default_subagent_model；需要自定义角色时，再在主配置中声明角色和配置文件。

四、自定义 worker 角色：需要在主配置里显式声明

如果希望让 Codex 在分工时看到一个名为 worker 的专用角色，可在主 config.toml 中增加：

[agents.worker]
description = "负责边界清晰的代码修改、文件处理和测试执行"
config_file = "agents/worker.toml"

然后创建 ~/.codex/agents/worker.toml：

model = "gpt-5.6-luna"
model_reasoning_effort = "medium"

config_file 的相对路径以声明角色的配置文件所在目录为基准。若在一次 spawn 中显式指定模型或推理强度，该次显式设置会优先于默认值。

五、如何验证配置真的生效？

1. 保存配置后重新启动 Codex，或至少新建一个任务。
2. 在设置或任务信息中确认主模型是预期值。
3. 执行一次 /review，确认审查环节使用了配置的 Review 模型。
4. 创建一个边界清晰的子任务，检查子 Agent 的模型与推理强度。
5. 使用同一测试任务对比修改前后的质量、耗时、Token或积分消耗。

不要只看总成本。建议同时记录首次通过率、返工次数、测试失败数和交付时间。若省下 30% 调用成本，却增加大量人工返工，整体并没有真正降本。

六、第三方 Provider 如何沿用同一思路？

Codex 支持自定义模型 Provider，但当前协议字段 wire_api 只支持 responses。第三方服务必须兼容 Responses API，并以服务商实际提供的模型名、专属 API Key 和 Base URL 为准。

model = "<Provider中的强模型>"
review_model = "<Provider中的轻量模型>"
model_provider = "my-provider"

[agents]
default_subagent_model = "<Provider中的轻量模型>"
default_subagent_reasoning_effort = "medium"

[model_providers.my-provider]
name = "my-provider"
base_url = "https://example.com/api/v1"
env_key = "MY_PROVIDER_API_KEY"
wire_api = "responses"

第三方模型通常继承当前会话的 Provider，因此主模型、Review 和子 Agent 的模型名都应当是该 Provider 可识别的名称。国内 Provider 的套餐、专属密钥和端点可能随产品更新变化，不要照抄旧截图；可结合站内 火山方舟相关模型入口核对当前产品信息。

**密钥安全：**只在系统环境变量中保存 API Key，不要把真实密钥直接写进 config.toml、仓库、截图或教程。Provider 配置使用 env_key引用环境变量名。

七、进一步省钱的 7 个实用策略

1. **默认轻量、按风险升级：**子 Agent 默认用 Luna，遇到复杂重构再显式切换。
2. **降低清晰任务的推理强度：**机械修改可尝试 low 或 medium，不要所有调用都设为 high。
3. **先缩小任务边界：**明确文件、交付物与验收标准，减少模型探索无关目录。
4. **避免重复传入大文件：**只提供相关片段，长项目使用项目说明与稳定文档沉淀背景。
5. **把测试命令写清楚：**让子 Agent 一次完成修改和验证，减少反复来回。
6. **Review 聚焦高风险差异：**明确安全、并发、数据迁移或兼容性关注点，避免泛泛审查。
7. **建立自己的成本基准：**用固定任务每周比较质量、时间和消耗，模型升级后重新测。

八、哪些情况下不应该为了省钱降模型？

• 需求本身模糊，需要大量澄清和架构判断；
• 涉及支付、权限、加密、隐私或安全边界；
• 跨多个系统的数据迁移和不可逆操作；
• 难以复现的并发、性能或生产故障；
• 代码审查结果将直接作为发布门禁。

这些任务的错误成本往往高于模型成本。可以继续让轻量模型负责资料整理与测试执行，但最终规划、关键修改和审批应交给更强模型并保留人工复核。

九、推荐的落地顺序

1. 先只配置 review_model，观察 Review 质量和消耗。
2. 再配置默认子 Agent 模型，用 3-5 个真实任务验证。
3. 确认稳定后，才建立 worker、researcher 等自定义角色。
4. 最后接入第三方 Provider，并单独验证模型名、工具调用、流式响应和错误处理。

**一句话总结：**让 Sol 负责想清楚，让 Luna 负责高频执行与常规审查；按任务风险升级，而不是让最贵模型包办所有工作。

常见问题

review_model 会自动接管所有代码审查吗？

不会。当前配置说明表明它是 /review 的模型覆盖项；普通对话中要求“帮我审查代码”仍可能由当前会话模型执行。

只创建 worker.toml 就能让子 Agent 自动使用吗？

不能保证。建议使用 agents.default_subagent_model设置默认模型；自定义角色还应通过 agents.<name>.config_file显式声明。

Compact 可以单独指定便宜模型吗？

当前公开配置参考中没有独立的 Compact 模型字段，因此不要假设可以单独切换。

第三方 Provider 一定能接入 Codex 吗？

不一定。它需要提供兼容的 Responses API、正确的模型名和认证方式，工具调用与推理元数据也要逐项测试。

使用 Luna 一定比 Sol 省钱吗？

官方将 Luna 定位为成本敏感、高吞吐场景，通常更适合高频执行；但最终成本仍取决于套餐、Provider、输入输出量、返工次数和实际定价。