GPT-5.6推理token按输出计费：成本估算可能偏差4倍

OpenAI 的 GPT-5.6 在整个产品线都带来了推理能力。Sol、Terra、Luna——所有模型在响应之前都会先进行推理。

这是一次能力升级。同时也是大多数团队还没遇到、但很快会遇到的一个计费问题。

吃掉你预算的隐形 token

推理 token 按输出 token 计费。只是它们从不出现在返回的响应中。

所以模型返回一个简短的答案，却在内部消耗了大量可计费的 token。你的估算器只看到可见的输出。账单却看到了一切。

具体例子——一个 Sol 请求返回 200 个可见 token，其下隐藏着 600 个推理 token：

Visible output:    200 tokens
Reasoning:         600 tokens
Billed output:     800 tokens

按每百万输出 token 30 美元计算：

估算（仅可见输出）：   200 / 1M × $30 = $0.006
实际：                 800 / 1M × $30 = $0.024

差了 4 倍。不是因为数学算错了。是因为估算器测量的对象就错了。

为什么单点估算在这里会失效

大多数预调用成本守卫逻辑是这样的：

const estimatedCost =
  (inputTokens / 1_000_000) * inputPrice +
  (expectedOutputTokens / 1_000_000) * outputPrice;

当可见输出长度是可计费输出的合理代理时，这么做没问题。对于推理模型，不是这样。

一个简单的格式化任务和一个复杂的架构问题，可能返回大小相似的响应，却在内部生成完全不同的推理 token 数量。输出长度相同，成本却天差地别。

守卫逻辑需要考虑到这种不确定性——而不是假装它不存在。

用区间，而不是数字

不要估算单一成本数字，而是估算一个区间：

interface ModelPricing {
  inputPerM: number;
  outputPerM: number;
  thinkingMultiplierRange?: [number, number];
}

把问题从：

"这次调用要花多少钱？"

转变为：

"可能成本的 ceiling 是多少——这个 session 能承受吗？"

如果最坏情况估算超出剩余预算，就在请求发出之前阻断它。这是唯一你仍有控制权的时刻。

执行后对账

一旦 provider 响应，用实际数据替换预留：

调用前：
  估算区间
  按 ceiling 预留
  如果 ceiling 不可承受则阻断

调用后：
  读取实际 token 使用量
  释放预留
  记录实际花费

这是标准的预留模式。关键属性不变：预算决策发生在请求发出之前。实际用量只是来完成这个闭环。

让你的实际工作负载来校准区间

通用的乘数是起点，不是答案。

一旦有了生产数据，按模型、按工作负载类型追踪推理 token 与可见输出 token 的比率。随着时间推移，你的注册表会从：

"推理可能额外增加 0.5–4×"

演进到：

"对于这个工作负载，观察到的范围是 1.2–1.8×"

守卫逻辑会越来越精准，而不是假装推理成本在执行前就可预测。

缓存产生了相反的失败模式

推理使实际成本高于估算。缓存使实际成本低于估算。

过于简单的守卫在两个方向上都会失败：

推理：实际成本 > 估算 → 预留不足，超支

缓存：实际成本 < 估算 → 预留过多，徒劳阻断调用

无论哪种情况，修复方法都一样：建模 provider 实际的计费机制，而不仅仅是 input × price + output × price。

随着模型越来越复杂，token 数量本身已不足以作为成本模型。

生产环境成本守卫需要考虑：

模型特定的定价层级

缓存输入折扣

推理输出区间

重试和部分失败

跨多个 agent 的 session 级预算

其中一些变量只在执行后才能完全知晓。这不是需要绕过的限制——而是需要为之设计的架构。

调用前估算和预留。调用后与实际用量对账。

估算没有错。只是不再是完整账单了。