求选｜GPT-5.6 Luna、Terra、Sol 怎么选？从 API 价格到任务路由的实测判断

先给结论：GPT-5.6 Luna 适合边界清楚、可批量验收的执行任务；Terra 适合日常多步骤开发；Sol 更适合失败代价高的规划、审查与关键决策。 这不是固定排名，而是一条成本路由：先定义验收线，再选择能稳定越过它的最低成本模型。

这条判断结合了两类来源：OpenAI 2026 年 7 月 30 日公布的 GPT-5.6 API 价格调整，以及 Token Beggars LAB-0001 在同一代码任务上的本地对照记录。前者回答“调用价格变了多少”，后者只回答“在这一个任务里，哪些正确性边界被验证”。

GPT-5.6 Luna、Terra、Sol 的 API 价格有什么变化？

按 OpenAI 7 月 30 日公告，GPT-5.6 Luna 降价 80%，Terra 降价 20%。公告列出的 API 价格为：

• GPT-5.6 Luna：每百万输入 token 0.20 美元，输出 token 1.20 美元。
• GPT-5.6 Terra：每百万输入 token 2 美元，输出 token 12 美元。
• GPT-5.6 Sol：价格不变；新增 Fast mode，最高可达到标准处理速度的 2.5 倍，价格为标准模式的两倍。

单看标价，Luna 与 Terra 的输入、输出单价相差一个数量级。但模型选型不能只比较每百万 token 价格：如果一次失败会触发返工、人工审查、数据修复或生产事故，真正要算的是“通过验收的总成本”。

GPT-5.6 模型怎么选？先按任务失败代价分流

1. 规格清楚、结果容易验收：先用 Luna

适合 Luna 的工作通常有明确输入、明确输出和便宜的自动验证，例如：

• 按既定规则批量修改文件；
• 为已有函数补单元测试；
• 整理结构化资料或生成固定格式草稿；
• 按已经确认的设计实现局部组件；
• 执行可以用 lint、类型检查和测试快速判定的改动。

这类任务的关键不是“绝不出错”，而是错误能被低成本发现并重跑。Luna 的低价只有在结果没有掉出验收线时，才会转化成真实节省。

2. 日常开发、需要工具调用和多步判断：先用 Terra

Terra 更适合作为常规开发默认档：需求边界大致稳定，但仍需要搜索代码、修改多个位置、运行命令并根据结果迭代。它位于 Luna 与 Sol 之间，适合先处理大多数可回滚、可测试的工程任务。

但“日常默认”不等于把高风险边界交给模型自行猜测。涉及重试、并发、权限、账号隔离或持久化时，必须把这些条件写进验收，而不是只要求“功能能用”。

3. 登录态、迁移、权限和并发：把 Sol 放在关键节点

当判断错误可能损坏数据、泄露账号状态或产生不可逆副作用时，Sol 更适合承担规划、风险枚举、架构审查和最终复核。典型场景包括：

• 登录恢复与跨账号数据隔离；
• 请求重放、幂等键和重复提交；
• 数据库迁移、权限模型与生产配置；
• 并发状态、竞态条件和失败恢复；
• 发布前的高风险 Diff 审查。

这并不意味着整项任务都必须用 Sol。更经济的组合是：Sol 定义不可丢的边界，Luna 或 Terra 按规格实现，自动化测试负责持续验收，Sol 再审查关键差异。

LAB-0001 实测说明了什么？

LAB-0001 比较的是一个预先登记的代码救援任务：让未登录用户的草稿穿过登录流程，同一请求最多提交一次，并且不能把 A 账号的草稿带到 B 账号。三个候选使用同一仓库快照、任务说明和时间限制，运行期间没有追加人工提示。

记录结果是：

• Sol、Terra、Luna 都通过了普通本地浏览器路径；
• Sol 与 Luna 还通过了同账号服务端重放和跨账号隔离检查；
• Terra 的普通 UI 路径通过，但在后续本地审计中，清除 cooldown 状态以模拟冷却不再阻挡重试后，相同认证会话和相同请求体得到两次 201，生成了两个不同 Post ID。

因此，Sol 与 Luna 在这项 correctness-first 评分中并列第一，Terra 排在第三。这里最重要的不是名次，而是一个模型路由原则：浏览器流程通过，不等于服务端幂等成立；测试是否覆盖失败边界，会直接改变“便宜模型是否划算”的答案。

这项实验没有实际等待五分钟，没有模拟真实传输层丢包，也没有测试生产环境。Sol 与 Luna 的正式 token 总量以及三个候选的实际货币成本都没有记录，所以不能把 LAB-0001 外推成通用模型排行榜或成本榜。

一套可复用的 AI 模型选型清单

在 Codex、OpenAI API 或其他 Agent 工作流中，可以按下面五步选择模型：

1. 写出验收结果：什么输出才算完成，哪些测试必须通过？
2. 列出不可丢边界：是否涉及权限、并发、幂等、迁移、隐私或生产数据？
3. 评估失败成本：失败只是重跑一次，还是需要人工排查、回滚或修复数据？
4. 从低成本档开始：先让 Luna 或 Terra 处理可验证部分；越不过验收线再升级。
5. 拆分而不是整单升级：只把规划、关键判断和最终审查交给 Sol，避免高价模型承担机械执行。

常见问题

Luna 降价后是不是性价比最高？

对边界明确、自动验收便宜的任务，它可能是最省钱的起点；对幂等、权限和迁移等高失败成本任务，仅凭 token 单价不能得出这个结论。

复杂代码任务是否应该全程使用 Sol？

不必。先用 Sol 划定风险与验收，再让 Luna 或 Terra 执行清楚的子任务，通常更容易控制总成本。

怎么判断该从 Luna 升级到 Terra 或 Sol？

当失败连续越过同一条验收边界、问题依赖多步工具判断，或错误开始影响数据正确性时升级；不要只因为任务文件多就自动升级。

这次实验能证明 Luna 普遍强于 Terra 吗？

不能。它只证明在 LAB-0001 的一个本地任务和仓库快照中，Luna 保住了已登记的重放与账号隔离边界，而 Terra 的候选实现没有保住本地重放边界。

你会把哪一段真实工作交给 Luna？请带上任务边界、所用模型、验收方式和失败点回来；如果记录了 token、延迟或金额，也一并贴出。

— Token Beggars 编辑部

参考来源

• Token Beggars LAB-0001