Codex 模型对比与选择
历史范围：本文保留来源记录中的模型系列、费率示例和界面名称，未将其核验为当前可用配置。计量方法与任务组织原则可参考；实际模型和价格请以文末官方入口及账号界面为准。
Codex 是 ChatGPT 中用于读取、修改、运行、测试和审查代码的智能代理。ChatGPT Plus、Pro 是订阅方案，模型则是 Codex 执行任务时使用的能力引擎。订阅档位主要影响可用额度，不等于模型名称。
模型、额度和可用范围可能随官方发布及账号灰度而变化；实际使用时请以 Codex 模型选择器和 OpenAI 官方页面为准。
一、快速结论
| 模型 | 定位 | 能力 | 速度 | 相对消耗 | 推荐场景 |
|---|---|---|---|---|---|
| GPT-5.6 Sol | 旗舰模型 | 最高 | 中等 | 最高 | 架构设计、复杂 Bug、大型重构、高风险任务 |
| GPT-5.6 Terra | 平衡型主力 | 很高 | 快 | 中等 | 日常功能开发、常规重构、测试与 Review |
| GPT-5.6 Luna | 高吞吐模型 | 中高 | 很快 | 较低 | 批量修改、抽取、分类、格式转换 |
| GPT-5.3-Codex-Spark | 低延迟模型 | 中等 | 极快 | 独立限额 | 小范围、交互式代码修改（Pro 研究预览） |
| GPT-5.4 Mini | 轻量模型 | 中等 | 快 | 最低 | 扫描、整理和低风险子任务 |
最实用的选择规则：
- 不知道选什么：Sol + Medium。
- 日常 Go 服务开发：Terra + Medium。
- 复杂架构、并发问题或线上疑难问题：Sol + High。
- 明确、重复、可批量验证的任务：Luna + Low / Medium。
- 只改几行代码并追求即时反馈：可用 Spark（账号可用时）。
二、核心模型怎么选
GPT-5.6 Sol：复杂任务和最终把关
Sol 适合需求模糊、影响范围大、错误成本高的任务。它通常更善于主动寻找隐藏依赖、分析边界条件，并完成从代码探索到验证的长链路工作。
典型场景：
- 跨模块、跨服务或跨仓库修改
- 微服务架构设计与大型重构
- Goroutine 泄漏、死锁、竞态和锁竞争
- GC 抖动、内存增长和 pprof 分析
- 数据迁移、协议升级与兼容性设计
- 生产事故根因分析、安全审查
- 对其他模型或子任务产出做最终验收
Sol 的成本和推理耗时最高。简单 CRUD、字段修改或格式转换没有必要默认使用它。
GPT-5.6 Terra：日常开发主力
Terra 在能力、速度和额度之间最均衡，适合团队大多数日常研发任务。它比 Luna 更能应对不完全明确的需求，又比 Sol 更适合高频使用。
典型场景：
- API、CRUD 和后台功能开发
- MySQL、Redis、RPC 等常规业务逻辑
- 修复范围明确的 Bug
- 编写单元测试、配置和 SQL
- 中小型重构、日志与错误码完善
- 常规代码审查、lint、test 和 build
- 阅读代码、补充开发文档
建议将 Terra + Medium 作为日常默认配置，遇到复杂或高风险任务再切换 Sol。
GPT-5.6 Luna：明确任务的高性价比选择
Luna 适合验收标准清楚、格式固定、可以批量执行的任务。它速度快、消耗低，但对模糊需求、架构取舍和隐藏副作用的判断弱于 Sol 和 Terra。
典型场景：
- 批量补充简单单元测试
- 批量改名、补注释或统一日志格式
- JSON、YAML、TOML 和 SQL 结构转换
- 从代码中抽取接口、配置或错误码清单
- 日志分类、文档整理和结构化总结
- 按固定模板生成低风险代码
使用 Luna 时应把文件范围、转换规则、禁止修改项和验收命令写清楚。高风险批量修改完成后，建议再由 Terra 或 Sol 审查。
旧模型与特殊模型
- GPT-5.5 / GPT-5.4：主要用于兼容旧工作流或复现历史结果；新任务通常优先使用 5.6 系列。
- GPT-5.4 Mini：适合极低成本的简单扫描和机械修改；通常优先考虑能力更强的 Luna。
- GPT-5.3-Codex-Spark：强调近实时交互，适合快速、小范围修改，目前主要面向 Pro 研究预览。
- GPT-5.3-Codex / GPT-5.2：不建议在新的 ChatGPT 登录工作流中继续配置。
- GPT-5.5 Cyber：特殊安全访问模型，不属于普通 Plus/Pro 的常规模型。
三、推理等级怎么选
模型决定能力上限，推理等级决定单次任务投入多少分析与执行资源。
| 等级 | 适用任务 | 使用建议 |
|---|---|---|
| Low | 字段修改、格式转换、简单测试、明确编译错误 | 范围小、结果可快速验证 |
| Medium | 常规功能、多文件修改、API 与数据库接入 | 日常默认 |
| High | 复杂 Bug、状态机、性能问题、大型模块分析 | 需要主动验证多个假设 |
| Extra High | 高风险迁移、跨服务改造、安全相关代码 | 错误成本较高时使用 |
| Max | 极难复现问题、复杂架构、单代理深度分析 | 不建议作为默认配置 |
| Ultra | 可拆分的大型探索、迁移或审计任务 | 多代理并行，消耗最高 |
不要仅通过提高推理等级来弥补不清楚的需求。明确入口文件、修改范围、业务约束和验收方式，往往比盲目使用 Max 更有效。
四、Go 服务端任务选择表
| 任务 | 推荐组合 | 原因 |
|---|---|---|
| 单个接口、CRUD、分页查询 | Terra + Medium | 多文件开发的能力与成本平衡最好 |
| 增加字段、修改 Tag 或配置 | Luna + Low | 规则明确、容易验证 |
| 普通 Bug 修复 | Terra + Medium / High | 能兼顾定位、修改和测试 |
| 并发、死锁、泄漏、竞态 | Sol + High | 需要分析完整生命周期和隐藏路径 |
| 难以复现的线上问题 | Sol + Max | 需要更深入的假设验证 |
| 微服务拆分、协议或数据迁移 | Sol + Extra High | 影响范围大、兼容风险高 |
| 大型且可并行的跨仓库改造 | Sol + Ultra | 可并行探索、实现与验证 |
| 批量补测试或机械修改 | Luna + Medium | 高吞吐、低消耗 |
| 常规代码 Review | Terra + High | 质量与成本平衡 |
| 发布前高风险 Review | Sol + High | 更适合最终风险把关 |
| pprof、GC、锁竞争、慢查询 | Sol + High | 需要综合代码、指标和运行数据 |
五、推荐的三级路由
团队可以按任务风险和清晰度路由，而不是始终使用最强模型：
查看图表代码
推荐实践：
- Terra 处理大多数日常开发，保持速度和额度平衡。
- Luna 承担明确的批量工作，但必须给出严格范围和验收命令。
- Sol 负责难题、方案决策和最终把关，避免在高风险任务上因反复返工而增加总成本。
六、影响消耗的不只是模型
实际额度消耗还受代码库大小、上下文长度、推理等级、输出长度和工具调用次数影响。大型仓库中，以下做法通常比单纯切换廉价模型更有效：
- 缩小工作目录和任务范围。
- 提供入口文件、相关模块和历史实现位置。
- 明确禁止扫描或修改的目录。
- 使用
AGENTS.md固化工程规则和验证命令。 - 要求先检查
git diff，避免重复读取无关文件。 - 排除 vendor、生成文件、大日志和构建产物。
- 将复杂任务拆成边界清晰、可分别验收的阶段。
七、参考资料
继续阅读
- AI与Codex完整实践与解答
- AI与Codex任务与配置Codex Token 计算规则 · 历史版本
- AI与Codex上手与对象