GPT-5.6 Sol、Terra、Luna 怎么选？价格、任务路由与实测方法

日常的混合任务先从 GPT-5.6 Terra 开始；边界清楚、数量很大的任务，让 GPT-5.6 Luna 先跑影子流量；困难、长上下文或一次错误代价很高的任务，再升级到 GPT-5.6 Sol。不要只问哪一档最强或最便宜，真正要比较的是：加入重试和人工审核以后，每个通过结果的成本是多少。

按 2026 年 7 月 11 日的标准 API 价，同一份 20 万输入 token + 4 万输出 token 的任务，Sol 约为 2.20 美元，Terra 为 1.10 美元，Luna 为 0.44 美元。这个算式只能说明 token 账单，不能直接宣布生产赢家：一次完整重试会让模型费用翻倍，几十分钟人工修复往往比 token 更贵。

“

**生产停止条件：**同一批任务尚未证明新路线降低每个通过结果的成本、没有新增不可接受的边界失败、并且能随时回滚，就不要替换当前默认模型。

三档模型的核心区别

OpenAI 在 GPT-5.6 发布说明 中把 Sol、Terra、Luna 定义为长期存在的能力档位，而不是一次临时预览。理解它们最有用的方式不是“旗舰、均衡、轻量”三个标签，而是你愿意为多少能力余量付费。

当前不带后缀的 gpt-5.6 会指向 Sol。如果你在意成本控制和结果可复现，生产代码应写明三档完整 ID。否则团队以为自己在用一个“自动均衡”的通用名称，实际可能一直走最高价路线；未来别名若改变，也很难追溯某次结果由哪一档产生。

“Pro”也不是第四个模型 ID，而是请求模式。三档都支持从 none、low、medium、high、xhigh 到 max 的推理强度。做对比时必须固定推理强度；拿 low 的 Luna 对比 max 的 Sol，得到的不是档位差异，而是两个变量一起变化的结果。

按任务形状选择第一条路线

混合任务把 Terra 当作默认试跑起点

一个真实队列往往同时包含代码修改、资料分析、工具调用、表格整理和普通问答。Terra 适合先做控制组：标准价格只有 Sol 的一半，同时 OpenAI 公布的若干智能体和知识任务中，Sol 与 Terra 的差距并不大。

这里的关键词是“试跑起点”，不是“永久默认”。Terra 的任务是先暴露工作负载分布：哪些任务它一次就过，哪些任务需要重试，哪些失败会造成真正损失。只有某一类任务反复漏掉相同的关键约束，才值得为这一类建立 Sol 升级规则，不必让全站流量一起变贵。

例如代码修复可以要求测试、类型检查、lint 和人工审查全部通过；资料综合可以要求每个结论都有可核验来源。Terra 与 Sol 若都通过，就比较总耗时和成本；若 Terra 只是在语气上不够“高级”，却不影响验收，就没有升级理由。

大批量、边界明确的任务让 Luna 先跑影子流量

Luna 的输入和输出价格都是 Sol 的五分之一，适合分类、字段抽取、固定格式转换、短文本改写和路由判断等重复任务。但上线第一步不应是把 100% 流量切过去，而是复制一部分真实请求给 Luna，保留原路线作为生产答案，先比较两边结果。

这就是影子流量：Luna 的输出暂时不影响用户，只用来建立证据。至少检查结构合法率、字段正确率、遗漏约束、工具调用、延迟、重试次数和审核分钟数。如果更低的 token 费换来了大量人工修复，它就不是更便宜的生产路线。

Luna 需要明确的停止条件：

• 输入很长，并且必须跨全文精确回忆时停止；
• 工具或结构化输出连续失败、需要反复重试时停止；
• 审核者必须重新补齐被遗漏的业务约束时停止；
• 同一批任务没有任何结果通过验收时立即停止；
• 提示词轻微变化就导致路线极不稳定时停止。

长上下文尤其不能凭价格乐观推断。OpenAI 公布的 MRCR 256K–512K 档位中，Sol 为 91.5%、Terra 为 89.6%、Luna 为 41.3%。这是提供商基准，不是所有长文任务的通用分数，但足以说明：未经自己的长上下文测试，不能把 Luna 设成默认。

难题和高失败成本任务再升级到 Sol

Sol 适合复杂智能体流程、困难推理、长上下文综合、脆弱迁移，以及一次错误可能带来运营、安全或合规损失的工作。这里购买的是能力余量和降低严重失败的机会，而不是更好看的模型名称。

Sol 同样要证明溢价。如果 Terra 与 Sol 在同一批任务上都一次通过、审核时间接近，那么 2 倍 token 价格没有创造额外的通过结果。比较稳妥的升级规则是：Terra 对同一项重要验收标准连续失败两次，才把该任务族升级到 Sol；预先定义的高风险任务可以从 Sol 开始，但仍要保留日志和回滚路线。

套餐权限、API、缓存和别名要分开看

截至 2026 年 7 月 11 日，OpenAI 公布的产品合同是：Free 和 Go 用户在 ChatGPT Work 与 Codex 中获得 Terra；Plus 及更高套餐可以在支持的产品界面选择三档。套餐权限不等于免费 API 额度，API 标准价也不能拿来代表订阅账单。

缓存会改变输入端成本，却不会改变输出价格比例。高命中任务里，输出 token 和人工审核可能成为主要成本；低命中且频繁写缓存的任务，则可能增加输入支出。不要把“缓存输入九折”或“读取便宜 90%”简单乘到所有输入上，应记录真实命中率。

价格、套餐权限、别名、缓存和推理模式都可能变化。准备上线时应重新查看 官方价格页、最新模型指南 和 API 更新记录。

从 token 单价改算“每个通过结果的成本”

先保留简单价格算式：同一份 20 万输入、4 万输出的任务，Sol $2.20、Terra $1.10、Luna $0.44。然后把重试和人工时间加入分子，把真正通过验收的结果放到分母：

text
每个通过结果的成本 =
  （首次 API 费用 + 重试费用 + 审核分钟数 × 人工时薪 / 60）
  / 通过验收的结果数

假设每档都跑 20 个任务，人工时薪按 60 美元估算：

这是用来解释方法的示例数据，不是三档模型的实测结论。它说明为什么“最低 token 账单”和“最低生产成本”可能完全相反：示例中 Terra 略胜，Sol 虽多通过一个结果却更贵，Luna 的低调用费则被审核时间吞掉。换一批任务、时薪或通过数量，赢家也会改变。

如果通过数量为零，成本不是“接近零”，而是没有可用分母。不要继续自动重试，也不要把便宜 token 包装成效率；应停止该路线，归类失败原因，再决定是否缩小任务边界或升级模型。

官方基准只能决定先测谁

基准表适合提出试验假设，不适合直接替代自己的队列。不同测试的提示词、工具、执行框架和评分方法都不同，终端任务、浏览任务、长文回忆和知识考试也没有相同的失败代价。

从当前官方表格可以得到三个安全结论：Sol 与 Terra 在若干任务上的差距较小，所以混合队列值得先测 Terra；高风险任务中，小差距仍可能减少一次昂贵事故，所以 Sol 值得作为升级路线；Luna 在超长上下文回忆上的明显下降，要求上线前设置专门停止条件。

不要把不相关的行平均成一个“综合分”，也不要因为一两分差距宣布全局胜负。正确动作是把某一行映射到相似任务，选择第一位候选，然后仍用本地验收标准决定是否上线。

用 20 个真实任务做受控测试

选择你接下来确实会路由的 20 个任务，而不是专门挑模型擅长的演示题。三档必须锁定相同的任务、提示词、上下文顺序、工具权限、推理强度、最大轮数、时间限制、重试政策和审核标准。

每个任务至少记录：请求与实际模型 ID、输入/缓存/输出 token、端到端延迟、首次通过时间、重试次数与原因、审核分钟数、是否通过、失败类型。能够盲审时，打乱输出顺序并隐藏档位名称，避免“旗舰应该更好”的预期影响评分。

验收标准必须能执行。代码任务可以要求测试、类型检查、lint、浏览器验证和审核全部通过；抽取任务可以要求 schema 合法、字段级准确率和召回率；研究任务可以要求引用有效、来源质量和必答事实覆盖。编造事实、破坏性工具动作、缺少必填字段或越过安全边界，应预先定义为硬失败，不能被语言流畅度平均掉。

测试结果只进入四种可逆状态：

可以预先规定：成本至少下降 10%、没有新增硬失败、延迟仍在预算内，才允许升级。差距低于阈值就继续影子测试，不因一次漂亮输出切 100% 流量。初始可保留 90% 旧路线，只让 10% 走灰度或影子流量，观察一个有代表性的窗口后再扩大。

如果你要比较跨厂商的编码路线，而不是 OpenAI 家族内部档位，可查看 GPT-5.6 Sol 与 Claude Fable 5 编码对比。那篇文章会把模型、Codex/Claude Code 执行环境、计费和实际生效模型分开，不能与本文的同家族测试混为一谈。

把选择写成可观测、可回滚的路由策略

测试结束后，不要只在群里留一句“以后默认 Terra”。把决策写成带版本的路由规则，并让每次调用都留下选择原因。最小日志应包含规则版本、任务族、风险等级、请求模型、实际模型、是否命中缓存、重试原因、最终是否通过，以及是否触发回滚。这样价格、别名或模型行为变化时，团队能重算旧决策，而不是凭印象争论。

一个保守的起始策略可以这样设计：预先标为高风险或长上下文尚未验证的任务直接走 Sol；只有已经通过 Luna 影子测试的任务族才进入 Luna；其余混合任务走 Terra。Terra 出现一次普通失败并不立刻升级，只有命中预先定义的“关键验收失败”才触发 Sol，并把触发条件写进日志。边界失败或连续零通过时停止自动循环，交给人工判断，避免便宜请求无限重试。

上线仪表盘至少要同时展示五组指标：各档请求量与费用、首次通过率、重试后通过率、人工审核分钟数、硬失败和回滚次数。只看调用成功率会漏掉“HTTP 成功但业务不合格”；只看平均延迟会掩盖尾部超时；只看 token 费会把人工修复变成隐形成本。按任务族拆分这些指标，才能发现 Luna 可能在字段抽取中节省很多，却在长文综合中制造负担。

灰度期间给每个状态设明确出口。影子流量积累到足够样本且跨过收益阈值，才进入 10% 可见流量；10% 稳定后再到 25%、50%，每一步都保留自动或一键回到旧路线的能力。若价格变化导致收益阈值不再成立，或者同一硬失败连续出现，应自动冻结扩量。回滚不是失败，而是这套路由系统能安全学习的前提。

还要定期复核“默认”是否仍有意义。任务分布会变，某个团队从短抽取转向长文综合后，原本适合 Luna 的比例可能下降；提示缓存命中率改变，也会重排输入、输出和审核成本。建议按周查看异常、按月重跑代表样本，在官方价格、模型 ID、别名或推理模式更新后立即重新验证。生产路由应是一份持续校准的政策，不是一张发布日排名表。

在多团队环境中，路由所有者还应区分“模型不可用”和“模型输出不合格”。超时、限流、服务错误属于可用性事件，可以按已验证的备用路线处理；事实错误、越权工具动作、schema 不合法则属于质量或边界失败，不能用无限重试掩盖。两类事件使用不同告警和升级路径，才能避免一次服务抖动错误地改变长期模型策略，也避免稳定返回的错误答案被可用性指标美化。

最后，证据包要能被另一位工程师复现。保存脱敏后的任务样本、验收脚本版本、评审量表、价格时间戳和计算表；对含敏感数据的上下文只记录哈希或受控引用，不把原文塞进普通日志。一次无法复现的“Luna 很快”或“Sol 更聪明”只能算体验，不能成为生产政策。

如果几个业务团队共用同一网关，不要让一个团队的短文本胜利覆盖另一个团队的长文风险。给每个任务族单独设预算、质量门和负责人，模型选择才不会被全局平均数误导。任何临时人工豁免都应标明到期时间，到期后重新走验证，而不是悄悄变成永久规则。

这样，模型策略才真正服务业务结果，而不是服务一张价格表。

常见问题

Terra 是最好的默认模型吗？

Terra 是混合任务最合理的第一轮试跑起点，不是已经证明的永久默认。它价格为 Sol 的一半，又保留较强的通用能力；最终仍要用相同任务、重试、审核时间、通过率和失败影响决定。

哪一档最便宜？

截至 2026 年 7 月 11 日，Luna 标准 API 价最低：每百万输入 token 1 美元、输出 6 美元。它只是每 token 最便宜；如果需要大量重试和人工修复，每个通过结果反而可能更贵。

长上下文应该选哪一档？

高风险或尚未验证的长上下文任务先用 Sol，再把 Terra 当作低成本挑战者。Luna 不能在没有本地证据时直接上线，因为官方 256K–512K MRCR 行显示它与 Sol/Terra 有明显差距。

gpt-5.6 默认指向谁？

当前别名指向 Sol。成本和可复现性重要时，明确写 gpt-5.6-sol、gpt-5.6-terra 或 gpt-5.6-luna，并在未来部署前复查更新记录。

Free 和 Go 用户能选三档吗？

当前官方说明是 Free、Go 在 ChatGPT Work 和 Codex 中获得 Terra；Plus 及更高套餐可选三档。产品套餐权限不代表免费 API 调用。

什么时候才能替换生产默认模型？

只有代表性同任务测试证明新路线跨过预设收益阈值、没有新增硬失败、延迟合格并且能回滚时才替换。先小比例放量，不要因为发布日基准或一次演示直接全切。

结论

把 Terra 作为混合任务控制组，把 Luna 作为边界明确任务的影子通道，把 Sol 作为困难与高失败成本任务的升级路线。先用 20 个真实任务锁定变量，统计重试、审核和通过率；证据没有跨过上线阈值之前，保留当前默认模型。