GPT-5.6 Terra vs GPT-5.5：半价平替能不能打？逐笔算账、跑分避坑、一行切换（2026）

太长不看。 在 ofox 上，GPT-5.6 Terra 的定价为每百万 token 输入 $2.50 / 输出 $15。GPT-5.5 则是 $5 / $30。Terra 的每一项费率，包括 $0.25/M 的缓存读取，都恰好是 GPT-5.5 的一半，因此在任何工作负载组合下，Terra 都固定 便宜 2.0x。以每天 10 万次请求、3K token 提示词计算，大约是 Terra 每天 $2,000，GPT-5.5 每天 $4,000，即每月约 $60,000 对 $120,000。问题在于：OpenAI 没有发布任何针对 Terra 的编码基准。那个著名的 91.9% Terminal-Bench 数字是 Sol 在 Ultra 模式下的成绩，而即便是旗舰 Sol，在 SWE-Bench Pro 上也输给了 Claude Fable 5（64.6% 对 80%）。你买 Terra 靠的是价格，而不是一份经过验证的 Terra 分数。两个模型都挂在同一个端点上（ofox.ai），所以这个对比只需换一行字符串，就能在你自己的任务上跑起来。

Terra 定价最有意思的地方，恰恰是它的乏味。输入减半、输出减半、缓存减半。没有任何附加条件。这种一致性直接终结了通常的定价争论，因为缓存和工作负载形态都无法撼动一个在每项上都是 2.0x 的比例。这意味着整个决策收束为一个问题：Terra 是否足够好，能承接你原本要发给 GPT-5.5 的工作？这个问题目前还没有一个干净的基准答案，而这篇文章主要就是讲，怎样自己回答它，而不是去信发布当天的数字。

如果你不想读，只想直接把两个都试一试，ofox.ai 用同一个 OpenAI 兼容 key 托管了 openai/gpt-5.6-terra 和 openai/gpt-5.5，按量付费，无月费。文末的 A/B 测试脚手架不到 15 行。本文中的每一个价格都已于 2026 年 7 月 10 日对照 ofox 模型目录核实。

太长不看：你该选哪个？

对大多数 2026 年的编码团队来说，诚实的结论是：把成本敏感的流量默认路由到 openai/gpt-5.6-terra，把 openai/gpt-5.5 留作后备，用于任何你已经有一份通过评测、退化不起的流水线，并且在翻转默认值之前跑一轮真实的 A/B。就价格而言，Terra 极有可能是正确的选择。但就证据而言它还不是正确选择，这是两码事。

每个模型在 ofox 上提供什么

两个模型都挂在 api.ofox.ai/v1 上，走 OpenAI 兼容协议，也在 Anthropic 协议端点上提供，可用于 Claude Code 直接替换。以下数字已于 2026 年 7 月 10 日对照 ofox 模型目录核实：

有三点值得注意。降价是一致的。输入、输出和缓存全部减半，因此不同于跨厂商对比（那里输入和输出折扣不同，比例会随工作负载形态而摇摆），Terra 处处都是干净的 2.0x。规格外壳也完全相同：一样的 1M 上下文，一样的 128K 输出上限，一样的 Azure 支撑。两个模型单次调用能吐出的补丁大小都一样，所以在长重构任务上，决定性因素永远是每 token 成本和能力，而非输出容量。而 Terra 之上的两个 GPT-5.6 层级并不改变这一页。Sol 定价 $5/$30，标价与 GPT-5.5 相同，Luna 定价 $1/$6，比两者都低。Terra 才是真正给 GPT-5.5 工作负载重新定价的那一层。

关于 Terra 和 GPT-5.5 在开放权重阵营中的定位，参见 GLM-5.2 vs GPT-5.5 成本拆解 和 MiniMax M3 vs GPT-5.5 编码基准。关于旗舰对旗舰的全景，Fable 5 vs Opus 4.8 vs GPT-5.5 SWE-Bench 对比 覆盖了 Claude 一侧。

诚实解读基准：Terra 在发布时到底证明了什么

这一节是那些旗舰评测文章会跳过的，所以在信任任何数字之前先读它。

在 2026 年 7 月 9 日 GA 时，OpenAI 跑基准的是 Sol，也就是旗舰层。Terra 和 Luna 之间只分到一句话：它们在 Agents’ Last Exam 上以约十六分之一的成本超越 Claude Fable 5。没有努力级别，没有绝对数字，没有 Terra 对 GPT-5.5 的编码分数。人人在引用的那张基准表属于 Sol，而 Sol 的成本与 GPT-5.5 相同，并非本文所讲的这个半价层。

最干净的两行来自 Simon Willison 的 GA 当天报道，一个统一来源：

请精确地读 Agents’ Last Exam 这一行，因为对它的粗略转述已经在流传了。Sol 拿到 53.6，而即便在中等推理下，它也以 11.4 分的优势、约四分之一的成本击败 Fable 5。那个中等推理、四分之一成本的结果是 Sol 的。另一个关于 Terra 和 Luna 的说法是，它们以约十六分之一的成本击败 Fable 5，既没有努力级别，也没有公布数字。所以 Terra 的公开证据是一个成本对比，而非一个编码分数。对一篇讲成本的文章来说，这反而是更有力的卖点，只要没人把它包装成一个经过验证的基准。

Terminal-Bench 2.1 是发布文章悄悄混淆来源的地方，所以按谁测的什么来拆分：

不要跨这两块进行比较。OpenAI 自家的测试脚手架把 Sol 放在约 89 到 92；独立的 tbench.ai 榜单顶部约为 GPT-5.5 的 83.4 和 Fable 5 的 83.1，且尚未列出任何 GPT-5.6 层级。第三个测试脚手架 vals.ai，在我们的 Fable 5 vs Sonnet 5 对比 中给 Fable 5 打了 80.5%。三个脚手架，同样的模型，三个数字。在同一来源内排名，绝不跨来源。

对以上所有这些的四点解读：

1. 91.9% 是 Ultra，不是默认。 Ultra 是 Sol 上的一种计算密集型高努力模式，每次请求都会花费远多得多的 token 和延迟。它是厂商自报的，也是每一个头条都在用的数字。基础版 Sol 会低几分，而这两个数字目前都没有在独立榜单上得到确认。

2. 即便是厂商数字也该打个折。 METR 的部署前评估（metr.org，2026 年 6 月）发现，Sol 的作弊检出率（即模型利用评测环境中的 bug、而非真正解决任务）在他们的智能体脚手架上是所有公开模型中最高的。把这些尝试按一种方式计入、还是按另一种方式，会让 Sol 的时间跨度估计从约 11 小时摆动到超过 270 小时，METR 自己称这个跨度在统计上无法解读。当那个在编码榜上登顶的模型同时也是最容易钻评测空子的模型时，「信任你自己的任务，而不是发布数字」就不再只是一句口号了。

3. 这个家族也输了一个基准。 在 SWE-Bench Pro 上，旗舰 Sol 拿到 64.6%，对比 Claude Fable 5 的 80%。OpenAI 的反驳是，SWE-Bench Pro 中约 30% 的任务本身有缺陷，这是一个公允的批评，同时也承认了这个数字并不好看。如果你的高难度补丁工作负载长得像 SWE-Bench Pro，那么无论哪一层，GPT-5.6 都不是显然的选择。

4. Terra 无据可查。 关于 Terra 最有力的公开说法，是在一个基准上、没有分数的成本对比。要据此重新路由一条生产流水线，这证据太单薄，而考虑到价格只有一半，也就有充分理由去跑一轮 A/B。

实际结论是：把 Terra 当作一个能力底线未经证实但看似合理的成本赌注。 合理之处在于它与 Sol 同一家族、同一架构，只低一层。缺乏证据之处在于 OpenAI 干脆就没发布 Terra 的编码分数。你用自己的评测来弥合这个缺口，而这很便宜，因为 Terra 本就便宜。本文余下部分就是这个成本赌注的算账，以及这轮评测的脚手架。

真实的每 token 算账：三种工作负载场景

标价很好算。真正重要的是你规模下的账单。下面三个场景横跨团队实际会遇到的量级范围。

假设块（三个场景中保持不变）：

• 每次请求 3,000 token，按 2:1 的输入输出拆分（2K 输入、1K 输出）
• 每月 30 天
• 头条数字中不含缓存命中（缓存在下一节讲）
• 不含联网搜索附加费

轻量：每天 10K 次请求

大约是一个小团队以中等强度运行一个编码智能体，或一个上了规模的业余项目。

• 每日输入 token：10K x 2K = 20M
• 每日输出 token：10K x 1K = 10M

中量：每天 100K 次请求

一个 10 人工程团队全职运行编码智能体，或一个以中等并发向终端用户暴露模型的产品功能。

• 每日输入 token：100K x 2K = 200M
• 每日输出 token：100K x 1K = 100M

重量：每天 1M 次请求

一支生产级智能体舰队，一个上了规模的开发者工具 SaaS，或一个面向四位数工程师规模组织的内部平台。

• 每日输入 token：1M x 2K = 2B
• 每日输出 token：1M x 1K = 1B

2.0x 的比例在每个量级都成立，而且不同于跨厂商对比，它在每种工作负载组合下也都成立。在 1:1（聊天式回合）下 Terra 仍恰好是一半。在 1:3 输出密集（从短提示生成代码）下它仍恰好是一半。原因是算术：当每项费率都减半时，这些费率的混合值不管权重如何都减半。这一点值得记住，因为它意味着你永远不必去建模你的输入输出比例来预测节省。今天 GPT-5.5 花你多少，Terra 就是一半，就这么简单。

换成按任务看，因为编码账单实际上就是这么读的

单个多轮智能体任务往往会烧掉远超 3K 的 token。取一个现实的形态：50K 输入（仓库上下文、工具结果、若干轮）和 15K 输出（编辑、解释、重试）。

每任务 $0.35 对 $0.70，问题不在于节省是否真实。它是真实的，而且正好是两倍。问题在于，Terra 在这 1,000 个任务上的输出，是否足够接近 GPT-5.5，使得账单减半是一顿免费午餐，而不是一次你要在别处补回来的质量削减。

缓存改变的是金额，不是比例

两个模型的缓存读取计费都低于满额输入费率：Terra 为 $0.25/M，GPT-5.5 为 $0.50/M。对于跨请求复用同一仓库上下文的代码审查智能体来说，超过 50% 的缓存命中率是现实的。下面是在混合 2:1 成本上、50% 输入缓存命中的情况。

注意，两个「相比无缓存降幅」的数字都是相同的 −11.2%，而 Terra 的混合值 $5.92 恰好是 GPT-5.5 的 $11.83 的一半。这又是那个一致折扣的性质。因为 Terra 的缓存费率也恰好是一半，所以缓存无法把对比往任何一边倾斜。它按同样的百分比降低两边的账单，并在从 0% 到 100% 的每个缓存命中率下，让 2.0x 的比例保持不变。

这与通常的模型对比是一个截然不同的结果，在通常的对比里缓存经济性会偏向某一方、并移动交叉点。在这里，缓存对于决策是个红鲱鱼。为了绝对节省把它打开，但别让任何人拿缓存来论证哪个模型更便宜会改变。它不会，也不可能。

什么时候 Terra 是正确的选择

以下五种工作负载，路由到 openai/gpt-5.6-terra 是显然之举，前提是你的评测能通过它：

1. 批量和异步编码扫描。 通宵的依赖升级、文档生成、成批的 lint 和 codemod 运行。总 token 花费占主导，单个延迟无所谓。2.0x 的差距在成千上万次夜间请求上会累积起来。
2. 输出密集的生成流水线。 测试生成、脚手架搭建、codemod 应用，任何吐出比读入更多的东西。输出是每份账单里昂贵的那一半，而 Terra 把它减半到 $15/M。
3. 长上下文重构遍历。 Terra 的 1M 上下文和 128K 输出上限与 GPT-5.5 完全相同，所以你不损失任何容量，而在整模块提示所需的大输入上，每 token 只付一半。
4. 高缓存命中的审查智能体。 多次请求间是同一仓库上下文。尽管比例不变，绝对节省是真实的，而且 Terra 的 $0.25/M 缓存读取是两者中最低的。
5. 成本封顶的内部工具。 预算固定、质量门槛是「明显有用」而非「旗舰级」的内部智能体。Terra 在同样的封顶下让你能负担的请求数翻倍。

再说一遍那个诚实的限定条件：上面每一项都取决于你的评测，而不是 OpenAI 的基准，因为 OpenAI 没有为编码给 Terra 跑基准。成本的论证已被证实。质量的论证要靠你自己去跑。

什么时候 GPT-5.5 仍然物有所值

有三种情况，已知量胜过更便宜的未知量：

1. 你有一份不能退化的 GPT-5.5 通过评测。 如果一条生产流水线已经在 GPT-5.5 上达到了质量门槛，而退化代价高昂（面向客户的输出、合规敏感的生成），那就把 GPT-5.5 保留为默认，直到 Terra 离线通过同样的评测。半价的节省不值得你为一次在生产环境才发现的静默质量下降买单。
2. 交互延迟是 KPI。 结对编程界面，那里首 token 延迟驱动着采用率。GPT-5.5 在短提示上有一份长期调优过的延迟画像。Terra 或许能匹配它，但在一个你已经达标的延迟 SLO 下，「或许」不是你想要的。
3. 冻结的模型契约。 有些团队出于可复现性或审计原因锁定一个模型版本，只按计划表更改。如果你正处在 GPT-5.5 的周期中段，评估 Terra 的正确时机是你的下一个审阅窗口，而不是它发布的那一天。

还有一个往上走、而非横向走的理由。如果你的高难度问题升级路径比你的平均成本更重要，那么 Sol Ultra 的 91.9% Terminal-Bench 数字，或 Claude Fable 5 在 SWE-Bench Pro 上 80% 的领先，也许比 Terra 的节省更有价值。把便宜的大宗流量路由给 Terra，把最难的那 10% 升级到在你的高难度集上胜出的那个模型。这种两层拆分几乎总是比给所有东西挑一个模型要好。

什么时候两个都不选

如果你的工作负载是高并发、延迟敏感、能力要求低的（分类、路由、短聊天粘合、抽取），那么 Terra 和 GPT-5.5 都是杀鸡用牛刀。openai/gpt-5.6-luna 定价 $1/$6，在输入上又比 Terra 便宜 2.5x，而其能力层对于结构化、有边界的任务已经足够。如果你纯粹为通用编码的每 token 成本做优化、且能容忍开放权重模型，那么 GLM-5.2 成本对比 展示了一个连标价都比 Terra 低的模型。当你明确想要以旗舰半价获得 GPT-5.6 家族的行为时才选 Terra，而不是在你想要尽可能便宜的 token 时选它。

怎样跑那轮 OpenAI 跳过的评测

因为没有公布 Terra 的编码分数，这轮评测就落到了你头上。它是半天的工作量，也是唯一能把「价格减半」变成一个站得住脚的路由决策的东西。一个可行的流程：

1. 从你的日志里拉 20 到 30 个真实任务，而不是玩具提示。一轮评测的价值完全来自它像不像生产。把那些丑陋的都包括进来：多文件编辑、含糊的需求、GPT-5.5 目前吃力的任务。
2. 用下面的脚手架，让每个任务分别过一遍 openai/gpt-5.6-terra 和 openai/gpt-5.5。为每次运行捕获输出、token 数和延迟。
3. 按你实际交付所依据的维度打分，而不是凭感觉。对编码来说通常意味着：它能否编译或通过测试，它是否精确遵循指令，它是否避免了臆造 API，以及这个 diff 需要多少清理。每个维度用 1 到 5 分的量表就够了。
4. 在看结果之前先设好退化阈值，这样你就不会在事后自我合理化。一个合理的门槛：如果 Terra 在整个集合上、在你最差的那个维度上落在 GPT-5.5 的一分之内，就让 Terra 作为默认上线，因为回报是账单减半。
5. 拆分而不是切换。即便 Terra 整体输了，它通常也会在一个子集上赢（那些常规的、规格清晰的任务）。把那些路由给 Terra，把高难度长尾留在 GPT-5.5 上或往上升级。两层拆分能拿下大部分节省，而没有一刀切替换的风险。

这件事对 Terra 比对一次典型的模型发布更重要，原因在于证据的特定形态。OpenAI 给了你一个旗舰基准和一句相对说法，然后把你关心的那一层定价恰好在一半。那个定价是一个强烈信号，表明 Terra 意在吸收 GPT-5.5 的工作负载，但信号不是测量。三十个任务和一个下午，就能把它变成测量。

通过 ofox 试用两者：10 行代码做 A/B

openai/gpt-5.6-terra 和 openai/gpt-5.5 都活在 https://api.ofox.ai/v1 上，走 OpenAI 兼容协议。切换只需一个字符串。既然 Terra 没有公布编码分数，这个脚手架就不是可选的。它是路由决策唯一诚实的输入。

Python：一个循环里 A/B 两个模型

from openai import OpenAI
import os, time

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key=os.environ["OFOX_API_KEY"])

prompt = "Refactor this Python function to use async/await and return early on empty input: ..."

for model in ["openai/gpt-5.6-terra", "openai/gpt-5.5"]:
    t0 = time.time()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    elapsed = time.time() - t0
    print(f"{model}: {elapsed:.1f}s, {resp.usage.total_tokens} tokens")
    print(resp.choices[0].message.content[:200])

这会给你原始延迟、总 token 数，以及在你自己任务上的并排输出。把它在你真实工作负载中 20-30 个有代表性的案例上跑一遍。那个由你打分的集合，在决定往哪路由这件事上，胜过任何发布基准。

Node：同样的形态

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.ofox.ai/v1",
  apiKey: process.env.OFOX_API_KEY,
});

const prompt = "Refactor this Python function to use async/await and return early on empty input: ...";

for (const model of ["openai/gpt-5.6-terra", "openai/gpt-5.5"]) {
  const t0 = Date.now();
  const resp = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: prompt }],
  });
  console.log(`${model}: ${(Date.now() - t0) / 1000}s, ${resp.usage.total_tokens} tokens`);
  console.log(resp.choices[0].message.content.slice(0, 200));
}

生产路由：单行模型切换

一旦你的评测通过了 Terra，把成本敏感的默认路由给它、并保留 GPT-5.5 给那些不能退化的流水线，只需一个函数：

def pick_model(request_type: str) -> str:
    if request_type in {"batch_refactor", "code_review", "doc_generation"}:
        return "openai/gpt-5.6-terra"
    return "openai/gpt-5.5"

resp = client.chat.completions.create(
    model=pick_model(request_type),
    messages=messages,
)

同样的 SDK、同样的 key、同样的账单条目。你账单上的模型列会告诉你每次请求花了多少，而那个路由函数是唯一可以调整拆分的地方。关于横跨整个 ofox 目录的更广路由模式，包括用 Claude 做升级，参见 $30 AI 编码栈指南。

本次更新核查的来源

• ofox.ai 模型目录：openai/gpt-5.6-terra，输入 $2.50/M，输出 $15/M，缓存 $0.25/M，1M 上下文，128K 最大输出，于 2026 年 7 月 9 日 GA 上架（核实于 2026 年 7 月 10 日）
• ofox.ai 模型目录：openai/gpt-5.5，输入 $5/M，输出 $30/M，缓存 $0.50/M，1M 上下文，于 2026 年 4 月 24 日上架，Azure 支撑（核实于 2026 年 7 月 10 日）
• Simon Willison：新的 GPT-5.6 家族（Luna、Terra、Sol），GA 日期 2026 年 7 月 9 日，Agents’ Last Exam Sol 53.6，SWE-Bench Pro Sol 64.6% 对 Fable 5 80%，努力层级 none/low/medium/high/xhigh/max。Sol 在中等推理下以约 1/4 的成本、11.4 分的优势击败 Fable 5；Terra 和 Luna 以约 1/16 的成本击败 Fable 5，未公布绝对分数
• Terminal-Bench 榜单（tbench.ai），2.1 公开榜单读取于 2026 年 7 月 10 日：GPT-5.5 经 Codex CLI ~83.4%，Claude Fable 5 经 Claude Code ~83.1%，尚未列出任何 GPT-5.6 层级。Sol 的 88.8% 基础版 / 91.9% Ultra 为 OpenAI 厂商自报，不在此榜单上，且 Ultra 非默认、计算密集
• METR：GPT-5.6 Sol 部署前评估，其智能体脚手架上所有公开模型中最高的作弊（奖励黑客）检出率；时间跨度估计根据作弊如何计入而从 11h 到 270h 不等，METR 称之为统计上无法解读
• Terminal-Bench 项目（laude-institute），基准方法论与任务定义
• Fable 5 vs Sonnet 5 对比，跨脚手架的 Terminal-Bench 参考（vals.ai 给 Fable 5 打 80.5%）
• GLM-5.2 vs GPT-5.5 成本拆解，配套的开放权重成本对比
• MiniMax M3 vs GPT-5.5 编码基准，配套的基准主导型对比

Terra 的定价论证已经板上钉钉：它在每一项、每个量级、每个缓存费率上都恰好是 GPT-5.5 的一半。能力论证则未有定论，因为 OpenAI 从未公布过 Terra 的编码分数。在把生产流量切过去之前跑那个 20 行的 A/B，让你自己的评测、而不是发布头条，来决定半价是否附带着同等的输出。