GPT-6.1 Terra 的档位悬崖：每任务成本降 8 倍，难题通过率也掉 4 倍

GPT-6.1 Terra 有六个推理档位：none、low、medium、high、xhigh、max。降价宣传里最动人的一个数字是"每任务成本最低到 $0.05"，最高档是 $0.40——家族内价差 7.4 倍。

问题在于，这 8 倍差价买到的不是"便宜一点的同样东西"。第三方实测里有一组数字非常刺眼：同一批 105 个植入缺陷，max 档得分 40.7，xhigh 档 11.3，high 档 9.7。

这篇只回答一个问题：档位该怎么选，才不至于用省下的钱去买返工。

先把两组数字放在一起

把这两组数对齐看，得到的是一个违反直觉的结论：在难题上，最贵的档位反而可能是最便宜的。

原因是分母错了。按"每个任务的成本"算，low 档最划算；按"每个成功任务的成本"算，结果会翻过来。

算一笔"已解决任务"的账

下面这组推算需要先声明假设：我手上只有 max 档的官方每任务成本（$0.40）与三档的通过率，中间档的成本按推理 token 随档位近似变化估算（xhigh ≈ $0.20、high ≈ $0.15）。这些是估算值，不是厂商公布数据，用途只是演示算法。

即便把中间档的成本压得很低，max 的"每个已解决任务成本"仍然最低。原因很简单：当通过率从 40.7% 掉到 10% 以下时，分母缩了 4 倍，分子只缩了 2 倍多。

这就是档位悬崖的经济学版本——省钱要省在"任务本来就不难"的地方，而不是"把难任务的档位调低"。

断点从哪来：三条推断

官方没有解释档位与能力的对应关系，以下几点是我的推断，标注清楚以便你反驳：

推断一：档位控制的是思考预算，而不是"聪明程度"。 推理 token 计入输出计费，档位越高，允许模型在内部推导的时间越长。对"定位一个隐蔽缺陷"这类需要多步假设检验的任务，预算不足会直接表现为"看完就猜"。

推断二：训练分布偏向高档位。 如果后训练与评测主要在 max 或较深档位完成，那么低档位就缺少同等的优化信号。这能解释为什么下降一档就掉四分之三——不是线性退化，而是"没在这个配置下被好好训练过"。

推断三：任务难度与档位收益不线性。 简单任务上，none 与 max 的差别可能只有几个百分点；难任务上差别是数量级。所以"取中间档"这个直觉在这里不成立。

三条推断都指向同一个操作建议：档位选择应该由任务难度决定，而不是由预算区间决定。

默认档位是最容易被忽略的坑

据网易智能转述的开发者文档，Terra 的默认思考档位是 medium。这意味着两件事：

1. 如果代码里不显式传 reasoning.effort，你拿到的是"中等档"，不是最高档。
2. 如果这个默认值在过去几代里没变，从 GPT-6.1 Sol 迁到 Terra 的代码很可能"什么都没改就上线了"，然后表现变差，被归因为"便宜模型不行"。

处理方法只有一条：在所有请求里显式写档位。把它做成配置项而不是默认值，让每次调用都能在日志里看见用了哪一档。

payload = {
    "model": "gpt-6.1-terra",
    "reasoning": {"effort": EFFORT},   # 必填，不依赖默认值
    "input": task_prompt,
}

三档路由：一个能落地的分法

不需要六档精细调配，三档就够：

为什么没有 high / xhigh？因为实测里这两档既没占到便宜（成本仍显著高于 low），也没保住质量（通过率不到 max 的四分之一）。除非你自己测出它们在你的任务上有甜点，否则跳过。

用"已解决任务成本"做决策

把这套算法固化成脚本，比看榜单管用：

# 同一批任务，不同档位各跑一遍
for effort in ["medium", "high", "xhigh", "max"]:
    runs = [call_model(task, effort=effort) for task in tasks]
    solved = sum(1 for r in runs if r.passed)
    total_cost = sum(r.cost_usd for r in runs)
    print({
        "effort": effort,
        "pass_rate": solved / len(runs),
        "cost_per_solved": total_cost / max(solved, 1),
    })

输出里最该看的不是 pass_rate，也不是 cost，而是 `cost_per_solved`。三个指标里只有它能回答"这档贵不贵"。

如果团队已经用统一网关管多家模型，可以把这条脚本放在路由层：以可替换实例来说，若通过 4SAPI 这类聚合入口调用，模型名与档位透传情况以该平台控制台当期显示为准——档位被静默吃掉是最常见的坑，验证方法是同一条 prompt 在不同档位下对比输出 token 与耗时。

为什么中间档最尷尬

high 与 xhigh 处在一个很别扭的位置：成本已经离开低位区间，质量却未到高档水平。

这也解释了一个常见现象：团队尝试“降一档省钱”，结果质量下降幅度远超预期，然后放弃整个模型。问题不在模型，而在跳过了两头、选了中间。

一个反直觉的推论

如果上面的推算方向成立，那会有个不好接受的结论：降低推理档位不是“渐进式降本”，而是“阶毯式降质”。

它在管理上意味着两件事。第一，不能用“先把档位调低观察一周”这种渐进策略做降本——你观察到的会是质量突然变差，而不是成本慢慢下降。第二，降本应该发生在任务分层上：把简单任务整类挑出去用低档，而不是把同一个难任务的档位拧小。

换句话说，档位是任务属性，不是预算参数。把它做成全局配置（比如环境变量统一设成 medium）几乎必然出错。

三个失败信号

第三条最值得警惕：重试一次就把成本翻倍，而重试通常还意味着交付延迟。用重试去补档位的窟窿，等于同时放弃省钱和体验。

与宣传口径的关系

官方宣传的"medium 档与 GPT-6 Astra 打平、单价只有 1/10"是真的，但限定在 Agents' Last Exam 这类 computer use 任务上。同一份公告也写了"最复杂的编码任务仍更适合交给 Sol 与 Astra"。

把两句合起来读就是：medium 是"操作类任务"的甜点档，max 是"难题"的必要档。宣传语没有骗人，只是它描述的是它的主场。

限制与结论

必须承认的边界：105 bug 那组数据来自单一作者、单一任务类型（缺陷定位与修复），不能外推到所有任务；我只拿到三个档位的分数，中间档成本是估算；官方没有公布各档位的 token 倍数，因此"断点"的确切形状仍然未知。

可以确定的是方法：把档位当成实验变量而不是省钱旋钮，用"每个已解决任务的成本"作为唯一决策指标，把默认值从代码里赶出去。

下一步很具体：挑 20 条你认为最难的任务，用 medium、xhigh、max 各跑一遍，算出三组 cost_per_solved。如果 max 的这组数最低——按照现有实测，多半会是这样——那么你要做的不是继续找更便宜的档位，而是把预算花在正确的地方。