GPT-6 Sol、Luna 与 Claude Opus 5.5 同日发布：别只看单价，按任务路由模型

同一天出现三个新模型，很容易让团队把注意力放在排行榜和“每百万 Token 多少钱”上。真正会影响预算的，是任务是否一次完成、要不要人工返工、缓存有没有命中，以及失败后要花多久把流程拉回来。

9 月 22 日，OpenAI 在变更日志中发布了 GPT-6 Sol 和 GPT-6 Luna；Anthropic 同日发布 Claude Opus 5.5。这篇不把厂商图表当作最终裁决，而是给团队一套能从今天开始执行的路由方法：把工作分层，小范围试跑，按完成任务的总成本做决定。

这张图的重点不在于宣布谁“最强”。重复、高量、边界清楚的工作，和需要处理模糊需求、长链路代码、质量风险的工作，本来就不该用同一个选型规则。

先把已确认的型号、价格和边界放到一张表

官方 API 标价按每百万 Token 计算。下面价格来自 OpenAI 的9 月 22 日变更日志与 Anthropic 的发布说明，长上下文、Fast 模式、批处理和地区可用性另有规则，接入前仍要查控制台。

OpenAI 还说明，Sol 和 Luna 可通过 Responses API 和 Chat Completions 使用；对于工具调用和推理强度，具体接口支持要按模型指南核对。Anthropic 公布的 Opus 5.5 标准价格是输入 $4、输出 $20、缓存读取 $0.20；它也有针对部分敏感任务的防护与路由机制。对需要精确交付的工作，这些边界和价格同样重要。

不要用“单价最低”替代成本计算

一次任务的 API 成本可以先用这个公式估算：

任务成本 =
未缓存输入 Token × 输入单价
+ 缓存读取 Token × 缓存单价
+ 输出 Token × 输出单价
+ 缓存写入、工具调用或长上下文附加费用

任务成本 =
未缓存输入 Token × 输入单价
+ 缓存读取 Token × 缓存单价
+ 输出 Token × 输出单价
+ 缓存写入、工具调用或长上下文附加费用

但采购与工程负责人应该再加上两项：

完成任务总成本 =
API 成本
+ 人工检查与修复时间 × 人工小时成本
+ 失败重跑次数 × 每次重跑成本

完成任务总成本 =
API 成本
+ 人工检查与修复时间 × 人工小时成本
+ 失败重跑次数 × 每次重跑成本

举个有用的极端例子：Luna 处理 10 万条结构化抽取任务，若输出格式稳定、重试很少，它的低单价会很快放大优势。反过来，一项支付迁移或全仓库权限审查即便 Token 花费更高，只要更强模型少一次误改和一天返工，总成本可能更低。

缓存也不应被当成脚注。Sol、Luna 与 Opus 5.5 的缓存读价都有明显折扣，但是否划算取决于前缀是否稳定。每天把系统提示、工具列表、知识库顺序随机改一遍，缓存命中率会掉；把稳定规则放在固定前缀，把当天任务放到后面，才能把缓存价真正用起来。

给工作分三层，再选择默认模型

先不要做“全量迁移”。把现有请求抽样，按后果和重复度分成三层。

第一层：高重复、低风险、结果容易验收

典型工作是标签分类、字段抽取、格式规范化、摘要初稿、批量翻译、工单分流。先选 Luna，但前提是你有结构化 schema、样本集和失败兜底。

实践做法：

1. 取过去两周 100 条已人工确认的真实请求，去掉敏感数据；
2. 为每条写出可机械判断的验收条件，例如字段齐全、金额不变、日期格式正确；
3. 用 Luna 跑两次，记录有效结果率、平均延迟、重试数和人工修复分钟数；
4. 对失败样本区分：提示词问题、输入脏数据、工具失败还是模型判断失误；
5. 只有通过率达到业务阈值，才扩到全量流量。

没有阈值就无法说“能上线”。可以先定一个保守规则：涉及外部写入的自动化，只有置信条件、校验器和人工审批同时通过才执行。

第二层：需要推理和工具协作的主力任务

调试、数据分析、生成带工具调用的工作流、较长的文档归纳，适合从 Sol 开始。Sol 的定位不是“便宜版旗舰”，而是需要较强推理但又必须控制频率和成本的执行层。

试运行时固定四个变量：同一任务集、同一工具、同一最大轮数、同一验收器。不要一边换模型，一边换 prompt、工具描述和上下文，否则结果没有可比性。记录工具调用次数也很关键：模型如果把同一个失败接口试十次，表面 Token 成本可能不高，实际延迟和人工救火已经上去了。

第三层：失败代价高、需求模糊或需要深度检查的任务

代码库迁移、权限审计、复杂修复、关键报告、对外发布前的最终审阅，不该只看每 Token 价格。Opus 5.5 的官方材料重点强调复杂工作、长任务和代码场景；它的性能声明应当被看作选择试验对象的理由，而不是你的项目会自动复制的成绩。

这层的正确做法是用固定验收器比较：测试是否通过、变更是否越界、事实是否能追溯、人工 review 要改几处。若低价模型已经连续两次无法通过同一质量门槛，就升级路由，而不是再让它用更长的思考和更多轮重试。

七天试运行：把争论变成一张表

选型不要从“大家感觉哪个好”开始。用一个 7 天、可回滚的试运行：

最少记录六列：任务 ID、模型与参数、是否一次通过、人工修复分钟、总 Token 与工具费用、最终是否可交付。没有“最终是否可交付”这一列，团队很容易被漂亮的单项分数误导。

一条可落地的路由规则

下面这条伪规则可以先放进网关、队列或人工 SOP：

if task is high-volume and has a deterministic validator:
    route to GPT-6 Luna
elif task needs tools or multi-step execution and has human review:
    route to GPT-6 Sol
elif failure has legal, financial, security, production, or publication impact:
    route to Claude Opus 5.5 or the team's highest approved model
else:
    start with Sol, cap attempts, then escalate after two failed validations

if task is high-volume and has a deterministic validator:
    route to GPT-6 Luna
elif task needs tools or multi-step execution and has human review:
    route to GPT-6 Sol
elif failure has legal, financial, security, production, or publication impact:
    route to Claude Opus 5.5 or the team's highest approved model
else:
    start with Sol, cap attempts, then escalate after two failed validations

模型路由不是永久配置。每周看一次失败样本：如果 Luna 的格式错误来自 schema 不清，先改校验器；如果 Sol 的任务总在工具调用上打转，先改工具返回值和重试策略；如果 Opus 5.5 的高价没有换来更少返工，就缩小它的使用范围。

把模型选择变成可复查的工程决策后，团队才能同时享受低成本模型的规模优势和高能力模型的质量兜底。使用 ClaudeAPI 组织模型调用时，也应把任务分层、成本记录和人工复核放在同一条工作流中，避免把切模型变成不可追溯的试错。

把每条请求登记成任务卡，路由才有依据

“写一篇分析”“修一个 bug”无法帮助你选模型。给每类工作建一张任务卡，记录任务类型、固定前缀和上下文长度、是否调用工具、成功定义、失败后果、人工分钟和回退方式。相同主题的请求，可能有完全不同的风险。

用同一批样本把便宜算清楚

不要让不同模型各跑一套不同的题，再比较总账单。取同一批已完成的真实任务、固定提示词和验收器后运行，至少记录一次通过率、人工修复分钟、中位延迟与每个可交付结果的总成本。

task_id,task_tier,model,validator_pass,review_minutes,input_tokens,cached_tokens,output_tokens,tool_calls,retries,final_status
T-001,extract,Luna,1,0,4200,3000,220,0,0,delivered
T-002,debug,Sol,1,12,18000,14000,1600,3,1,delivered
T-003,release_review,Opus,1,28,25000,20000,2400,4,0,delivered

task_id,task_tier,model,validator_pass,review_minutes,input_tokens,cached_tokens,output_tokens,tool_calls,retries,final_status
T-001,extract,Luna,1,0,4200,3000,220,0,0,delivered
T-002,debug,Sol,1,12,18000,14000,1600,3,1,delivered
T-003,release_review,Opus,1,28,25000,20000,2400,4,0,delivered

单次价格低、但要两次重跑和 15 分钟人工修复的请求，不该自动进入默认路由。

写升级条件，别把重试当成策略

通过机械校验 → 可以进入低成本批处理池
首次校验失败 → 检查输入和 schema，不立刻换更贵模型
同一任务第二次失败 → 升级一档，并保留失败样本
涉及外部写入、账户权限、生产变更或对外发布 → 必须人工审批
输出含数字、政策或事实主张 → 缺少来源字段则不交付

通过机械校验 → 可以进入低成本批处理池
首次校验失败 → 检查输入和 schema，不立刻换更贵模型
同一任务第二次失败 → 升级一档，并保留失败样本
涉及外部写入、账户权限、生产变更或对外发布 → 必须人工审批
输出含数字、政策或事实主张 → 缺少来源字段则不交付

每周只复盘重试、升级和人工接管的任务。若升级都来自一个模糊字段，优先改表单；若工具接口反复被调用，补返回值和错误码；若高价模型只在一类任务里明显少返工，就把它锁在那一类任务里。路由策略应该随记录变化，而不是跟着发布日的热度变化。