YunLab.ai YunLab · 模型使用复盘
省钱的同时更合理。
GPT-5.6 发布以后，我没有马上开始什么新项目，主要还是给之前的几个工作收尾，以及处理一些日常任务。
所以一开始，我对三个模型的选择非常简单：Sol 能力最高，那就尽量使用 Sol。Terra 偶尔会用，Luna 基本没有使用。
至少在 7 月底的那段时间，我看到的额度几乎每天都会重置，也就没有认真考虑消耗问题。既然额度够用，似乎没有必要专门选择能力更低的模型。
但使用一段时间以后，我逐渐觉得：这种方式可能用错了。
问题不是 Sol 不够好，而是我把“能力最高”和“所有工作都适合它”当成了同一件事。
三个模型不是简单的高中低档
按照 OpenAI 对 GPT-5.6 三个模型的官方定位：
- Sol 是旗舰模型，适合最复杂、最重要、需要深度推理的工作。
- Terra 是更加平衡的日常工作模型，兼顾能力、速度和成本。
- Luna 强调速度和价格，适合高频、大批量以及成本敏感的任务。
如果只看这个介绍，很容易把它们理解成“高、中、低”三个档位。
但在我目前的工作流里，我把它们分成三种不同的工作角色：
- Sol 负责处理不确定性。
- Terra 负责组织和推进执行。
- Luna 负责完成已经定义清楚的大量工作。
这是我自己的编排，不是 OpenAI 规定的固定流程。三种角色之间，也不是简单的替代关系。
官方数据里的能力差距
OpenAI 在 7 月 9 日发布页中公布的部分任务评测如下：
| 评测项目 | Sol | Terra | Luna |
|---|---|---|---|
| SWE-Bench Pro | 64.6 | 63.4 | 62.7 |
| DeepSWE v1.1 | 72.7 | 69.6 | 67.2 |
| Terminal-Bench 2.1 | 88.8 | 87.4 | 84.7 |
| OSWorld 2.0 | 62.6 | 50.2 | 45.6 |
| BrowseComp | 90.4 | 87.5 | 83.3 |
| OpenAI MRCR v2 8-needle（256K–512K） | 91.5 | 89.6 | 41.3 |
这些数据说明，三个模型之间的差距并不是固定的。
在代码修改和终端任务上，Terra、Luna 与 Sol 的差距没有我原来想象中那么大。在 OSWorld 计算机操作中，Sol 与 Terra、Luna 的差距明显扩大；BrowseComp 的差距相对温和；在 MRCR 超长上下文中，主要是 Luna 明显落后，Terra 仍然接近 Sol。
因此，正确的问题不应该是：
哪个模型最好？
而应该是：
当前任务里最难、最不确定的部分是什么？哪些部分已经被定义清楚，可以交给更便宜的模型执行？
这也是我后来调整使用方式的起点。
独立任务评测里的成本差异
截至 2026 年 8 月 5 日，Artificial Analysis Coding Agent Index v1.3 使用了 321 个任务，并对每个任务进行了三次尝试。下面这些结果对应 Codex 执行框架中的三个模型、max 推理配置，并不是脱离执行框架的纯模型分数。
| 模型 | Coding Agent Index | 单次任务尝试的平均 API 成本 | 平均单次任务尝试耗时 |
|---|---|---|---|
| Sol | 67 | 7.08 美元 | 10.2 分钟 |
| Terra | 62 | 2.21 美元 | 8.4 分钟 |
| Luna | 59 | 0.31 美元 | 8.0 分钟 |
这里的成本是按照 API 用量估算的，不能直接换算成 Codex 订阅里的额度消耗。但它仍然揭示了一个很明显的事实：Sol 的综合得分最高，但在很多已经定义清楚的执行任务上，它带来的能力增量，未必与成本增量成正比。
Luna 的得分没有低到不能工作，价格却低了很多。它真正需要的不是被排除在工作流之外，而是更清楚的任务说明、更小的执行范围和更明确的验收标准。
还有一个容易忽略的问题：便宜不等于使用的 token 更少。Artificial Analysis 的同一组结果里，Luna Max 每次任务尝试的平均 token 量反而高于 Sol Max。模型分工的目的不是单纯压缩 token，而是让每个层级的能力用在适合的位置。
OpenAI 发布页里的单项评测与 Artificial Analysis v1.3 综合指数采用不同任务和计分口径，两组数字不能直接比较。
价格变化进一步放大了分工价值
OpenAI 在 7 月 30 日下调了 Terra 和 Luna 的价格，Sol 价格保持不变。单次请求输入不超过 272K token 时，调整后的未缓存标准 API 价格为：
| 模型 | 输入价格 / 百万 token | 输出价格 / 百万 token |
|---|---|---|
| Sol | 5 美元 | 30 美元 |
| Terra | 2 美元 | 12 美元 |
| Luna | 0.20 美元 | 1.20 美元 |
如果单次请求输入超过 272K token，长上下文费率会提高：Sol 的输入 / 输出价格为每百万 token 10 / 45 美元，Terra 为 4 / 18 美元，Luna 为 0.40 / 1.80 美元。因此，使用约 512K token 上下文的任务不能直接套用上表估算成本。
OpenAI 同时说明，ChatGPT 与 Codex 的订阅价格和额度预算没有变化；在 Codex 和 ChatGPT Work 中，Terra 与 Luna 的使用会消耗更少 credits。
更重要的是，OpenAI 在这次价格说明中直接给出了一个类似的工作方式：先由 Sol 消除不确定性、定义计划，再让 Luna 完成已经明确的修改、编写和运行测试，并检查结果。
这并不能直接证明我的整套分工就是最佳方案，但至少说明了一点：让最强模型负责规划，再把明确的执行交给更便宜的模型，并不是单纯为了节省成本，而是官方也在强调的使用方向。
我现在的模型选择方法
经过一段时间的实验，我现在不再按照“哪个模型最强”来选择，而是先判断任务里的不确定性、影响范围和执行量。
第一种：相对复杂的任务
Sol 制定方向和打磨计划 → Terra 执行 → Sol 复核和修复
对于方向不够明确、影响范围比较大，或者出错以后不容易恢复的任务，我现在先让 Sol 负责：
- 理解真正要解决的问题；
- 找出需求、权限和现有状态之间的冲突；
- 确定修改范围；
- 补全执行细节和验收条件；
- 判断哪些地方不能直接动。
计划足够明确以后，再交给 Terra 执行。
Terra 的作用不是重新设计，而是按照已经确认的方向完成修改、运行验证并整理证据。执行完成后，再回到 Sol 做最终检查。
这种方式比从头到尾都使用 Sol 便宜，也避免让 Terra 在方向还没有确定时一边猜、一边修改。
一个尚未完成的案例：优化本机“宪法”
最近我正在优化本机的“宪法”。
这里的“宪法”不是一份普通说明文档，而是约束本机 AI 如何工作的基础规则。它会规定哪些操作可以直接完成，哪些需要确认，如何保留证据，执行失败以后怎样恢复，以及不同 AI 之间如何交接。
这项工作到现在还没有完成，但它已经可以作为模型分工的案例。
在这个任务里，我没有让 Terra 一上来就修改文件，而是先让 Sol Max 负责：
- 审查现有规则；
- 判断真正的问题；
- 设计新版结构；
- 确定权限边界；
- 把工作拆成可执行批次；
- 为每个批次定义准确的修改范围和验收标准。
只有某个批次通过 Sol 的设计审核以后，Terra Max 才能按照限定范围执行。执行完成后，还要重新交给 Sol 检查，确认实际修改、验证结果和原来的设计一致。
在正式执行之前，独立复核已经提出了几个必须先解决的潜在风险，包括隐私边界、授权范围、已有修改保护和执行证据可信度。
这些问题没有靠执行阶段临时补救，而是在进入修改之前就阻止了不成熟的方案继续向前。
这个案例还没有完成，所以它不能证明最终方案已经成功，也不能证明 Terra 的执行质量已经通过验收。
它目前能够证明的只是：把设计与执行分开，可以让错误更早暴露。一次“没有开始修改”，有时正是审核机制发挥作用的结果。
这个任务里我没有加入 Luna，因为它属于高影响、强约束的复杂工作。为了凑齐三个模型而强行使用 Luna，反而会增加交接成本。
三个模型分工，不等于每个任务都必须同时使用三个模型。
第二种：任务简单，但执行量很大
如果方向已经明确、单个任务并不复杂，但是需要处理大量文件、数据或重复步骤，我现在采用更完整的分工：
Sol 确定方向和打磨计划 → Terra 拆分并派发任务 → Luna 执行 → Terra 复核 → Sol 最终审核和修复
这里的关键不是简单地把任务交给 Luna，而是先把任务加工到 Luna 可以稳定执行的程度。
Sol 负责定义：
- 最终目标；
- 不允许改变的边界；
- 输入和输出格式；
- 成功与失败的判断方法；
- 抽样检查和停止条件。
Terra 再把计划转换成可以执行的小任务，控制任务范围和批次，收集 Luna 的结果，并完成第一轮复核。
Luna 只处理已经被定义清楚的执行工作，不负责决定方向，也不负责自行扩大任务范围。
执行结束后，Terra 检查数量、格式、错误和遗漏，最后由 Sol 判断整体结果是否真正达到原来的目标，并处理剩余问题。
这种工作流更适合：
- 大量相似文件的整理；
- 已有规则下的数据处理；
- 批量生成结构固定的内容；
- 明确范围内的代码修改；
- 重复测试和结果收集；
- 可以通过规则或样本验收的任务。
Luna 的优势只有在任务被充分定义以后才能发挥出来。如果任务说明仍然模糊，把它直接交给 Luna，节省下来的模型成本很可能会变成返工成本。
真正节省的不是一次调用，而是返工
我过去把节省理解成“少用额度”或者“选择便宜的模型”。
现在我更关心的是整个任务的总成本：
- 方向判断花了多少；
- 执行花了多少；
- 因为要求不清产生了多少返工；
- 审核有没有发现真实问题；
- 最后有没有形成可以验收的结果。
如果一个任务本来只需要 Luna 执行，却从头到尾都使用 Sol，确实浪费了高价能力。
但如果为了省钱，过早让 Luna 接手一个方向仍然模糊的任务，最后反复重做，也不是真正的节省。
我目前的判断标准很简单：
- 不确定性高：先用 Sol。
- 需要可靠执行：使用 Terra。
- 要求明确、数量很大：使用 Luna。
- 影响范围大：最后回到 Sol。
省钱只是结果之一。更重要的是，模型的能力、责任和任务阶段能够对应起来。
从跨工具审核，到同一体系内的角色分离
以前我的常用方式，是让 Claude Code 执行，再由 Codex 审核。
两个工具之间天然存在一层分离：执行者和审核者不是同一个系统，思考方式、上下文和容易忽略的问题也不完全一样。
后来，我这边的 Claude Code 无法继续使用，原来的执行与审核链路也随之中断。所有工作转到 Codex 以后，如果让同一个任务既设计、又执行、再审核自己的结果，很容易变成自我确认。
在同一 Codex 体系内拆分设计、执行和复核比较麻烦，但 Sol、Terra、Luna 的分工，至少提供了一个可以落地的替代方向：
- Sol 负责设计、关键决策和最终验收；
- Terra 负责组织执行和第一轮复核；
- Luna 负责范围明确的大量执行；
- 必要时另开独立上下文，让 Sol 复核前一个 Sol 的设计。
这不能完全替代 Claude Code 与 Codex 之间真正的跨系统审核。三个模型仍然属于同一个模型体系，可能共享某些偏差。
但它至少把“设计、执行、复核、最终验收”重新拆开了。每一步有不同的责任，也有明确的交接和停止条件。
这种变化不一定会让单次回答看起来更聪明，却能在一定程度上提高工程完成度：减少遗漏，提前暴露冲突，保留执行证据，并让任务更有机会真正收尾。
所以，我现在使用 GPT-5.6 的核心思路，不再是始终选择最强的模型。
而是让 Sol 处理不确定性，让 Terra 管理执行，让 Luna 承担清楚而大量的工作，再把最终判断交回 Sol。
模型选项没有变。改变的是我开始把它们当成一支需要分工的队伍。