模型选型最容易犯的错，是先给任务贴上“简单、中等、困难”的标签，再把 Luna、Terra、Sol 从小到大排进去。这个办法看起来顺手，落到生产环境却经常失灵。让 Luna 从两百份工单里提取字段，任务规模很大，但不一定难；让 Sol 判断一个只有三行改动的权限漏洞，输入很短，代价却可能很高。

更稳妥的选法，是看一次错误会带来什么后果，以及错误能否被程序及时发现。能用 schema、测试和规则兜住的任务，优先压到 Luna。需要理解上下文、权衡多项约束，但结果仍可评审的任务，从 Terra 起步。答案一旦错了就会带偏架构、资金、合规或生产变更，才值得把 Sol 放到主路径。

先看相同点：三款不是三套产品

Sol、Terra、Luna 共用 GPT-5.6 家族的大部分产品边界。官方模型页给出的上下文窗口都是 1,050,000 Token，最大输出都是 128,000 Token，知识截止日同为 2026 年 2 月 16 日。三者都接受文本和图片输入，支持流式输出、函数调用、结构化输出，也都能在 Responses API 中使用 Web Search、File Search、Code Interpreter、Hosted Shell、Computer Use、MCP 等工具。

这意味着不能用“Luna 没有工具调用”或者“Terra 上下文更短”来做选择。三个型号的接口表面很接近，迁移成本也低。真正要评估的是同一套工具、同一份上下文和同一条提示下，模型需要多少重试、会不会漏掉隐含条件、是否知道该在什么时候停下来问人。

项目	GPT-5.6 Sol	GPT-5.6 Terra	GPT-5.6 Luna
官方定位	复杂专业工作的旗舰模型	能力与成本的平衡档	成本敏感、高吞吐工作负载
输入价格	$4 / 百万 Token	$2 / 百万 Token	$0.20 / 百万 Token
缓存输入	$0.40 / 百万 Token	$0.20 / 百万 Token	$0.02 / 百万 Token
输出价格	$20 / 百万 Token	$12 / 百万 Token	$1.20 / 百万 Token
上下文 / 最大输出	1.05M / 128K	1.05M / 128K	1.05M / 128K
推理档位	none 到 max	none 到 max	none 到 max
适合承担的责任	最终判断、复杂方案、难以验证的高价值任务	主力生产任务、日常开发、带约束的分析	筛选、抽取、改写、预处理和大批量候选生成

还有一个命名细节值得注意：gpt-5.6 这个无后缀别名会路由到 Sol。把模型名写成“最新 GPT-5.6”并不等于自动选择最划算的型号；它实际上是在默认购买旗舰能力。

真正的差别：不是知识量，而是判断余量

Luna：把边界画清楚

任务规则明确、输出能机器校验、失败可以低成本重跑。它不怕量大，怕的是要求藏在上下文里。

Terra：承担日常主路径

需要综合多段材料、调用工具、修改代码或写完整交付物，但仍有测试和评审作为安全网。

Sol：处理不可逆判断

约束相互冲突、需求不完整、错误不容易自动暴露，或者一次判断会影响后面许多昂贵步骤。

Luna 最适合“闭合任务”：输入字段相对稳定，成功条件可以写成断言，模型的自由度被控制在一个小空间里。邮件分类、日志归因候选、文档标签、商品属性抽取、固定格式摘要、SQL 草案和测试数据生成，都属于这一类。它的价值不是替代一次 Terra 调用，而是让原本用不起模型的批处理变得可行。

Terra 是最容易被低估的一档。它的输入、输出价格大约是 Sol 的一半到六成，却保留同样的上下文上限、工具面和最高推理档位。日常开发里，大多数任务并不要求模型独自发明架构：仓库里已有模式，测试会暴露回归，reviewer 能看出不合适的抽象。此时 Terra 往往比“所有请求都上 Sol”更符合工程经济学。

Sol 的优势应当用在判断余量上。所谓判断余量，是模型面对缺失信息、冲突证据和长程依赖时，仍能维持目标、主动验证并发现“题目本身可能错了”的空间。架构迁移、棘手故障、权限设计、跨模块重构、关键合同分析和高价值研究，更容易从这部分余量受益。

一个实用判据：如果任务做错后，下一步仍然会由测试、schema、lint 或人工审批拦住，先用 Luna 或 Terra。如果错误会以“看起来合理”的形式进入生产，而后面没有更强的验证器，才优先用 Sol。

Token 价格不是任务成本

只比较每百万 Token，会得出 Luna 永远胜出的结论。生产系统付的钱却不是模型报价，而是完成一项合格任务的总成本。低价模型若需要三次重试、更多工具往返和更长输出，差距会被缩小；更麻烦的是，人工复核时间通常比 Token 贵。

任务总成本 = 模型调用 + 工具调用 + 重试 + 人工复核 + 错误外溢

先看一个单次长任务。假设输入 10 万 Token，输出 5,000 Token，并暂时忽略缓存、工具费和推理差异：

• Sol：约 0.50 美元；
• Terra：约 0.26 美元；
• Luna：约 0.026 美元。

在一次调用里，Sol 与 Terra 的绝对差额只有 0.24 美元。若这是一次生产事故定位，工程师多等十分钟或走一次错误方向，省下的 Token 没有意义。换成每天一万次、每次一万输入加一千输出的客服或内容流水线，月度差距会迅速放大，这时 Luna 的数量级优势才真正改变业务模型。

长上下文还有第二层价格。三款模型的官方页面都注明：单次提示超过 272K 输入 Token 后，整个请求的输入按 2 倍、输出按 1.5 倍计价。1.05M 上下文是一项能力，不是“塞满也划算”的邀请。把整个仓库、全年工单或几十份 PDF 一股脑塞进去，通常同时损害成本和信噪比。

缓存也不能只看 90% 的读取折扣。GPT-5.6 的缓存写入按普通输入的 1.25 倍计费，读取才是十分之一价格。固定系统提示、工具 schema 和稳定知识库前缀适合缓存；每次都变化的大段上下文，写入后没有复用，就只增加了一笔费用。

模型型号与推理档位，是两根独立旋钮

三款 GPT-5.6 都支持 none、low、medium、high、xhigh 和 max，默认是 medium。于是选型不再是一条从 Luna 到 Sol 的直线，而是一个二维问题：先选模型能力，再选它愿意为当前任务花多少推理。

Terra high 不等于 Sol low。增加推理档位，是让同一个模型探索、验证得更多；换成 Sol，则是换了一套能力上限。前者适合“模型大体会做，只是需要多检查几步”，后者适合“任务本身要求更强的理解和判断”。两者可能在某些任务上接近，但不能靠命名推断，必须用评测确认。

实践中可以这样起步：

• Luna none/low：抽取、分类、改写、候选生成，以及每一步都有校验的流水线。
• Terra medium：日常 API 默认值。代码实现、文档综合、带工具的多步任务先从这里测。
• Terra high/xhigh：模型已经理解问题，但在边界条件、长依赖或验证环节容易漏项。
• Sol medium/high：高价值专业任务、复杂编码和对“看似正确”特别敏感的工作。
• Sol xhigh/max：少量、困难、质量优先，而且确实能用客观标准证明额外推理有收益的任务。

OpenAI 还提供 Pro mode，它不是另一个模型名，而是所选 GPT-5.6 型号上的执行模式。Pro 会增加模型工作量、延迟和计费 Token，适合难度高且边际质量有实际价值的请求。把所有 Sol 请求都开到 max + pro，通常不是“配置拉满”，而是放弃了成本控制。

编程任务怎么分：看改动的爆炸半径

编程场景里，“写多少行代码”与难度关系很弱。增加一个遵循现有模式的 CRUD 模块，可能改十个文件但很好验证；修改三行缓存一致性逻辑，影响可能更大。选择模型时，应看需求清晰度、仓库约束、测试覆盖和改动爆炸半径。

Luna 适合做前后处理，不宜默认拥有最终判断权

Luna 可以批量归类 issue、从日志提取错误签名、生成测试输入、把编译错误映射到文件、完成机械式改名，也可以在约束严格的小模块里补代码。关键是把结果交给编译器、测试或更高层模型验证。让 Luna 扫一千条日志找候选，再让 Terra 分析十条异常，比直接让 Sol 吞下一切更便宜，也更容易追溯。

Terra 应该成为大多数团队的默认 Coding Agent

功能实现、局部重构、依赖升级、测试补齐、CI 修复和文档同步，通常都有现成仓库模式与验证命令。Terra 能使用与 Sol 相同的 shell、apply patch、MCP 和代码工具，缺的不是“能不能改文件”，而是面对含糊需求时的判断余量。只要任务边界清楚、测试可信，Terra 更适合作为持续运行的主力。

Sol 留给那些测试也不告诉你答案的任务

架构边界重新划分、并发与一致性故障、复杂权限模型、跨语言迁移、性能退化根因和大范围遗留代码清理，往往没有单一测试能定义正确答案。模型必须判断哪些约束是偶然实现，哪些是业务不变量，还要决定何时停止修改。此类任务中，Sol 省下的通常不是 Token，而是 reviewer 识别隐蔽错误的时间。

任务	建议起点	升级条件
日志分类、测试数据、机械改名	Luna low	输出无法用规则或测试验证时升 Terra
小功能、CI 修复、依赖升级	Terra medium	跨模块约束多、两次验证失败时升 Sol
局部重构、性能分析	Terra high	缺少基准、根因不清或影响生产路径时升 Sol
架构迁移、权限、并发一致性	Sol high	高价值且有严格验收标准时再比较 xhigh/max 或 Pro
代码审查	Terra 主审 + Sol 抽检高风险 diff	安全、资金或数据边界变更直接交 Sol

不要押一个型号：设计可解释的升级路由

成熟系统很少需要“全公司统一使用某一个模型”。更好的结构是把便宜模型放在默认路径，同时定义何时升级。升级条件应来自任务信号，而不是让模型自己说“我不确定”。模型的自信表达并不是可靠的校准器。

可以直接测量的升级信号包括：

• 结构化输出连续两次不通过 schema；
• 测试、静态检查或事实核验失败；
• 工具调用次数超过预算，开始重复搜索同一信息；
• 输入涉及权限、付款、删除、生产配置或合规判断；
• 多个来源相互冲突，且没有确定性规则可以裁决；
• 任务跨越的模块、服务或责任边界超过设定阈值。

一条常见的生产路由是：Luna 做入口分类和上下文压缩，Terra 完成主体任务，Sol 只处理被规则标记的高风险请求或 Terra 的失败样本。另一条适合代码审查：Terra 检查所有 PR，Sol 只审安全敏感文件、大 diff 和发布前关键变更。

这种分层不能只把失败文本转交给上级模型。升级时应携带原始目标、关键输入、已执行工具、验证结果和失败原因；否则 Sol 还要花一轮重新调查，成本与延迟都会重复。

如何做自己的评测：先定损失函数，再跑模型

官方定位可以决定从哪里开始，不能替代团队自己的评测。不要只准备二十道“代表性问题”看答案顺不顺眼。生产评测至少要覆盖正常样本、边界样本、信息缺失、工具失败和恶意输入，并保留任务原本的分布比例。

每个型号和推理档位记录以下指标：

• 一次通过率，而不是最终重试后的通过率；
• 端到端成功率，包括工具执行和结构化输出；
• P50、P95 延迟与超时率；
• 输入、缓存写入、缓存读取、输出和工具费用；
• 人工修改时间与必须升级到更强模型的比例；
• 漏报、误报和高风险错误分别造成的业务损失。

最后不要按正确率排名，而要按期望损失计算：

期望损失 = 调用成本 + 人工成本 + Σ（错误类型概率 × 该错误的业务代价）

分类任务里，Luna 从 97% 提升到 Sol 的 98% 未必值得二十倍输入价格；欺诈审核里，那 1% 若集中在高金额样本，结论可能反过来。模型没有脱离业务后果的“性价比”。

评测还要防止一个常见误区：把 Luna low 和 Sol high 放在一起比，然后把差距全部归因于型号。正确做法是先固定提示、工具和推理档位横向比较，再在候选型号内调 effort。OpenAI 的迁移建议也是保留原推理档位作为基线，同时再测试低一档，而不是默认把新模型开到最高。

最后给一个直接答案

个人开发者：如果调用量不大，先用 Terra medium。一次任务省几毛钱通常不值得牺牲排查时间；遇到架构、复杂故障和大重构再切 Sol。Luna 用在批量整理、测试生成和可自动验收的小任务。

创业团队：不要把 Sol 设成所有 API 的默认值。Terra 承担主业务，Luna 处理入口分类、内容预处理和离线批任务，Sol 放在高价值用户、高风险动作和失败升级路径。先做路由，通常比继续压缩提示词更能控制账单。

企业平台团队：默认模型不是一个名字，而是一项策略。按数据敏感度、动作权限、可验证性和爆炸半径分级；锁定模型快照，记录 reasoning effort 与工具版本，用线上抽样持续检查路由是否把困难样本错误地下沉给了 Luna。

只想记一句话：Luna 买吞吐，Terra 买日常生产力，Sol 买的是在不完整世界里少走一次错误方向。选择的核心不是任务看起来多难，而是错了以后，谁能发现，以及要付多少钱。

参考资料

• OpenAI：GPT-5.6 Sol 模型页：定位、价格、上下文、工具、长上下文计费与促销价格期限。
• OpenAI：GPT-5.6 Terra 模型页：定位、价格、功能和 Rate Limits。
• OpenAI：GPT-5.6 Luna 模型页：高吞吐定位、价格、工具与 Rate Limits。
• OpenAI：模型对比页：三款模型的并列规格与计费。
• OpenAI：GPT-5.6 Model Guidance：型号选择、reasoning effort、Pro mode、缓存与评测建议。