GPT-5.6 三档模型：Sol、Terra、Luna 该用哪个（2026）

三档模型，同一代际。 GPT-5.6 以 Sol、Terra、Luna 三档发布：相同的 1M 上下文、相同的 128K 输出上限，在价格和能力曲线上占据三个不同的位置。Sol 是旗舰，每百万 token $5/$30；Terra 是均衡的中间档，价格正好是一半（$2.50/$15）；Luna 是廉价的主力，$1/$6。难点不在于怎么把它跑起来，难点在于为每种任务挑对档位，别为你根本用不到的能力多花钱。本指南两头都讲：怎么接入全三档，以及怎么决定由哪一档处理哪类请求。

30 秒看懂 GPT-5.6：你能做什么，不能做什么

一句话版本：批量流量默认走 Luna 或 Terra，难啃的尾部留给 Sol，永远传入明确的档位 ID，需要最高强度时用 Responses API。之后的内容都是细节。

决策框架：这套分档什么时候划算（什么时候不划算）

分档是一种习惯，不是一个配置开关。当你的流量确实混杂时它划算，当流量并不混杂时它只会浪费你的时间。

什么时候该跑全三档。 当你的工作负载跨越多个能力层级时，就在 Sol/Terra/Luna 之间路由：同一个产品里，廉价的分类和路由紧挨着困难的多文件重构。当你的月账单大到批量流量上 2 倍或 5 倍的价差成为真金白银时。当你对成本敏感却不能在那困难的 10% 请求上降低能力时。这正是路由器为之而生的场景，也是从每百万输出 token 的 $1 到 $30 的价差变成一根你可以拉动的杠杆的地方。

什么时候不用折腾。 如果每个请求的难度大致相同，就选一档收手。单一用途的分类器只该跑 Luna，别的都不用；一个永远只做困难推理的研究智能体应该跑 Sol，跳过路由逻辑。如果你的总花费每天不到几美元，搭建档位路由的工程时间成本比它节省的还多。而且如果你在 OpenAI 直连 API 上依赖裸的 gpt-5.6 别名解析到 Sol，那么在你真正需要 Terra 或 Luna 之前，加上档位逻辑对你毫无好处。

收手规则。 如果你的目标只是调用旗舰，用 gpt-5.6-sol（或网关上的 openai/gpt-5.6-sol）然后在下一节收手。下面的档位选择和路由内容只有在你至少有两种难度不同的请求类型时才值得花功夫。

系统要求

没什么稀奇的。你需要两种接入方式之一，以及一个说 OpenAI 协议的 SDK。

两栏之间的差别故意做得很小。网关路径的存在，是为了让一把密钥就能触达全三档 GPT-5.6 以及你用到的所有其他模型，无需三个独立的提供商账号。如果你已经在用 OpenAI SDK，迁到网关只是改一下 base URL 和 model 字符串，仅此而已。

三档模型并列对比

以下是每档实际提供的规格，价格已对照 ofox 模型目录在 2026 年 7 月 13 日核实。所有费率均为每百万 token。

两个事实主导了大部分决策。第一，规格边界在各档之间完全一致：相同的 1M 上下文，相同的 128K 输出上限。你永远不用拿上下文去换成本。一段整模块的提示在 Luna 上装得下，在 Sol 上一样装得下；你选的是每 token 的能力，不是容量。第二，价差很大。Luna 的输出 token 是 Sol 的五分之一。在输出繁重的工作上,也就是智能体账单集中的地方,这个比例就是把流量往下推的全部理由,只要质量允许。

Sol 的标价（$5/$30）与上一代旗舰 GPT-5.5 相同。Terra 把同样的工作负载定成正好一半。Luna 再往下一档。代际号在三档中都保持 5.6；变动价格的是档位名称。

哪一档处理哪类任务

干净利落的选法是按请求形态来选，而不是凭直觉猜某个任务”有多聪明”。把任务映射到档位，再让路由器去执行。

几乎所有团队最终收敛到的模式是双档拆分：批量请求走 Luna 或 Terra，一小撮难啃的尾部升级到 Sol。这在那 90% 不需要旗舰的流量上吃住了价差，只在多几个百分点的通过率能改变结果的地方才花旗舰预算。

下面是同样的逻辑,做成一张你可以直接搬进路由函数的流程图。

flowchart TD
    A[Incoming request] --> B{Bounded output?<br/>classify / route / extract}
    B -->|Yes| L[openai/gpt-5.6-luna]
    B -->|No| C{Everyday coding<br/>or agentic work?}
    C -->|Yes| D{Latency or cost<br/>the priority?}
    D -->|Yes| T[openai/gpt-5.6-terra]
    D -->|No, hardest tasks| S[openai/gpt-5.6-sol]
    C -->|No, hardest reasoning| S
    S --> U{Needs max effort or<br/>Ultra heavy compute?}
    U -->|Yes| R[Sol via Responses API]
    U -->|No| S2[Sol via chat/completions]

档位选择在每个任务上花你多少钱

在你给任务套上一个形态之前，档位差距还是抽象的。拿一个多轮智能体任务举例：50K 输入 token（仓库上下文、工具结果、几个回合）和 15K 输出（编辑、解释、重试）。同一个任务，三档，采用上表中的 ofox 费率。

在每天一千个任务的规模下，把一切都跑在 Sol 上和把一切都跑在 Luna 上，两者的差距大约是每月 $16,800。没人应该把一切都跑在 Luna 上，因为其中不少任务需要的能力超过 Luna 所能给的。但这个数字解释了为什么分档值得那份路由代码：如果哪怕三分之一的流量足够有界能走 Luna，另有三分之一过关能走 Terra，混合后的账单就会远低于全 Sol 那条线，而且完全不用碰那困难的尾部。

关于这套算术，有两点值得记牢。第一，输出是昂贵的那一半。Sol 的输出 token 是 Luna 的五倍，其输入 token 也是五倍，但输入通常是更大的原始数量，所以在输出较少的任务上各档会压缩，在输出繁重的任务上各档会拉开。优先把你输出繁重的生成任务（测试脚手架、codemod、长篇解释）往下推，因为那正是档位差距咬得最狠的地方。第二，缓存不会改变排序。每档的缓存输入费率正好是它自己未缓存输入费率的十分之一（Luna 上 $0.10 对 $1，Terra 上 $0.25 对 $2.50，Sol 上 $0.50 对 $5），所以缓存以相同比例降低每一档的输入账单，无论命中率如何，Luna 都比 Terra 便宜、Terra 都比 Sol 便宜。开启缓存是为了绝对的省钱；别让它改变你选哪一档。

分步操作：用一把密钥跑全三档

这里走的是 ofox 路径，因为一把密钥触达全三档正是重点。OpenAI 直连路径除了 base URL 和去掉 openai/ 前缀外完全相同。

第 1 步：设置你的密钥和 base URL

export OFOX_API_KEY="sk-..."      # from app.ofox.ai
export OFOX_BASE_URL="https://api.ofox.ai/v1"

预期结果：设好两个环境变量。此时还没有发起网络调用。

第 2 步：每档各调用一次以确认访问权限

from openai import OpenAI
import os

client = OpenAI(base_url=os.environ["OFOX_BASE_URL"], api_key=os.environ["OFOX_API_KEY"])

for tier in ["openai/gpt-5.6-luna", "openai/gpt-5.6-terra", "openai/gpt-5.6-sol"]:
    r = client.chat.completions.create(
        model=tier,
        messages=[{"role": "user", "content": "Reply with your tier name only."}],
    )
    print(tier, "->", r.choices[0].message.content.strip())

预期结果：三行，每档一行。如果任何一行抛出 not-found 错误，先检查 model 字符串的拼写，再确认你的密钥是否有 GPT-5.6 访问权限。

第 3 步：构建档位路由器

一个函数把请求类型变成一个 model 字符串。这就是整套分档系统。

def pick_tier(job: str) -> str:
    if job in {"classify", "route", "extract", "autocomplete"}:
        return "openai/gpt-5.6-luna"
    if job in {"code", "review", "refactor", "docgen"}:
        return "openai/gpt-5.6-terra"
    return "openai/gpt-5.6-sol"   # hard reasoning / agentic tail

resp = client.chat.completions.create(
    model=pick_tier(job_type),
    messages=messages,
)

预期结果：每个请求落到能过其质量门槛的最便宜档位上。你账单上的 model 列会精确显示每个请求的花费，而 pick_tier 是调整拆分比例的唯一入口。

第 4 步：Node，形态相同

如果你的技术栈是 JavaScript，路由器的形态完全一致。

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: process.env.OFOX_BASE_URL,
  apiKey: process.env.OFOX_API_KEY,
});

const pickTier = (job) => {
  if (["classify", "route", "extract"].includes(job)) return "openai/gpt-5.6-luna";
  if (["code", "review", "refactor"].includes(job)) return "openai/gpt-5.6-terra";
  return "openai/gpt-5.6-sol";
};

const resp = await client.chat.completions.create({
  model: pickTier(jobType),
  messages,
});

第 5 步：触达最高强度和 Sol Ultra（Responses API）

max 推理强度和 Sol 的重算力 Pro/Ultra 模式不能在 /v1/chat/completions 上运行。它们需要 Responses API。Sol 支持的推理强度覆盖 none、low、medium、high、xhigh 和 max；这个区间的顶端加上子智能体 Ultra 模式，正是旗舰配得上它价格的地方。

resp = client.responses.create(
    model="openai/gpt-5.6-sol",
    input="Trace this deadlock across the four files below and propose a fix.",
    reasoning={"effort": "high"},   # max also valid here; not on chat/completions
)
print(resp.output_text)

预期结果：一个推理繁重的答案。把同样的调用改到 chat.completions 上，配上 high 强度设置加函数工具，你就会得到下一节里那个 400 错误。

运行 GPT-5.6 的常见错误（及修复）

关于 not-found 和访问失败的完整排查流程，包括模型列表检查和 VPN 区域封锁情形，请见 GPT-5.6 model-not-available 错误修复。简短版在表格里；详细版给出了诊断顺序。

基准测试对每一档到底说了什么（和没说什么）

按价格和你自己的评测来选档，别按发布头条选，因为头条数字并不覆盖每一档。下面是诚实的归属，按到底是谁跑出了什么严格拆开。

实用的读法：Sol 有真正已公布的数字。Terra 和 Luna 有一次降价加上一个针对 Claude Fable 5 的模糊相对说法，仅此而已。所以当营销说 GPT-5.6 在 Terminal-Bench 上达到 91.9% 时，那是 Ultra 模式下的 Sol，不是你会用来路由日常编码的那一档。别在规划时把 Sol 的基准套到 Terra 上。如果你要把一个工作负载从 Sol 下移到 Terra 来降本，先在你自己的日志上跑一个 20 到 30 个任务的 A/B。Terra 便宜，所以评测也便宜，而且这是唯一描述你自己流量而不是 OpenAI 流量的数字。Terra 与 GPT-5.5 成本拆解 更深入地推演了那套 A/B 算术和基准归属。

团队和多开发者配置

档位选择在团队共享后会变得更有价值，而不是更没价值。团队里的失败模式是每个开发者硬编码一个不同的 model 字符串，结果你一半的流量悄悄地在 Luna 本能搞定的任务上跑旗舰。

集中管理档位映射。把 pick_tier（或它的 Node 双胞胎）放进一个共享的内部包里，禁止在应用代码里出现原始 model 字符串。这样当你的评测或预算变化时，你就有一个地方来挪动 Luna/Terra/Sol 的边界，而且它让成本归属变得可读，因为账单的 model 列现在反映的是一项策略，而不是上百次各自为政的猜测。

共享一个密钥入口。让全三档都通过单一的 https://api.ofox.ai/v1 密钥运行，意味着一条计费明细、一次访问授权，无需按开发者去折腾 OpenAI 组织。新工程师拿到同样的三个模型 ID 和同一个路由器。当你以后加入来自不同厂商的第四个模型时，它会加入同一把密钥和同一个路由函数，而不是一次新的集成。关于把整个模型目录路由到一个端点后面的通用模式，请见 多模型路由器指南，以及 Codex CLI 自定义提供商配置，了解如何把同一把密钥接入编码 CLI。

给旗舰设上限。如果 Sol 的花费让你担心，就把它锁在路由器后面，只让升级路径能触达它，并记录每一次 Sol 调用及其任务类型。大多数团队会发现有一块 Sol 流量在 A/B 里 Terra 处理得很好，而路由器就是你把它挪走的地方。

替代方案：接入 GPT-5.6 的其他方式（及更多）

ofox 网关。 一把 https://api.ofox.ai/v1 密钥就能在 OpenAI 兼容协议上运行全三档（openai/gpt-5.6-sol、openai/gpt-5.6-terra、openai/gpt-5.6-luna）以及你的其他模型，按量付费，由档位路由器决定每个请求的成本。这正是本指南围绕的配置，也是在你正式选定一个档位之前对它做 A/B 摩擦最小的方式。价格跟随实时控制台。

OpenAI 直连。 platform.openai.com 以裸 ID（gpt-5.6-sol 及同类）提供同样的三档，用 Responses API 支持 max 强度和 Sol 的 Pro/Ultra 模式。如果你已经深入 OpenAI 的组织工具体系，且不需要在同一把密钥上再添一个厂商，就选这条。代价是访问权限按接入面和按组织分别限定，所以来自错误组织的密钥即便是同一个人能在 ChatGPT 里用这个模型，也照样会 404。

GitHub Copilot 及其他接入面。 GPT-5.6 在 GA 时也在 Copilot 里上线了。用于编辑器内的交互式编码没问题，但它不是一个你用来路由程序化流量的 API，所以在构建应用时它不能替代网关或直连路径。

关于其他方案的诚实说明：OpenAI 直连是模型的权威来源，也是唯一能保证别名行为和 Responses-API 特性的地方；网关的优势在于跨档位和跨厂商的单一密钥，加上即插即用的成本 A/B。按你看重单厂商的简单还是多模型的路由来选。

FAQ

上面 frontmatter 里的 FAQ 块回答了在 People Also Ask 中围绕 GPT-5.6 档位选择出现最多的八个问题：三档模型是什么、怎么运行、该选哪个、gpt-5.6 是否等于 gpt-5.6-sol、Ultra 模式是什么、每 token 成本、400 推理强度错误，以及不改代码切换档位。

本次更新核对的来源

• OpenAI GPT-5.6 Sol model reference
• OpenAI API pricing
• OpenAI reasoning guide (effort levels, Responses API)
• Simon Willison: the new GPT-5.6 family (Luna, Terra, Sol)
• OpenAI community: GPT-5.6 chat-completion reasoning-effort behavior
• ofox model catalog: GPT-5.6 Sol
• ofox model catalog: GPT-5.6 Terra
• ofox model catalog: GPT-5.6 Luna