成本记账
Sakana Fugu 编排 token 是额外工作,不是脚注
OpenAI 形状的字段名很容易让人以为 token_details 里的每一项都是已计入总额的拆分。对 cached_tokens 这确实成立——它就在 input_tokens 之内;但官方定价文档写明编排字段是额外真实用量,并按对应的输入、缓存或输出费率计费。
1. 存官方对象,不要猜子集
直播定价页和 Models 页公布了 Ultra(Models 页也对 Cyber)的这一形状:input_tokens 是发给第一个模型的用户输入总量,已包含缓存部分;cached_tokens 是其中命中缓存的那一部分(是子集,不是额外数量);orchestration_input_tokens 是编排输入合计,同样已包含其缓存部分;orchestration_input_cached_tokens 是该编排输入命中缓存的子集;output_tokens 是最终输出;orchestration_output_tokens 是在最终输出之外额外产生的编排输出;total_tokens 含编排。
两个 cached 字段沿用 OpenAI 的常规语义:各自是其所归属输入总量的子集,因此 cached_tokens ≤ input_tokens、orchestration_input_cached_tokens ≤ orchestration_input_tokens。只有编排字段是 input_tokens / output_tokens 之外的额外用量;普通输入总量本身已经包含其中的缓存部分。
{
"input_tokens": 120,
"output_tokens": 80,
"total_tokens": 200,
"input_tokens_details": {
"cached_tokens": 0,
"orchestration_input_tokens": 0,
"orchestration_input_cached_tokens": 0
},
"output_tokens_details": {
"orchestration_output_tokens": 0
}
}
2. 先减去各自缓存子集,再求和,最后乘费率
未缓存输入 = (input_tokens − cached_tokens) + (orchestration_input_tokens − orchestration_input_cached_tokens)
计费缓存输入 = cached_tokens + orchestration_input_cached_tokens
计费输出 = output_tokens + orchestration_output_tokens
估算 = 未缓存输入/1M × 输入费率 + 计费缓存输入/1M × 缓存费率 + 计费输出/1M × 输出费率
定价前先校验:每个缓存数必须小于或等于其归属的输入总量,普通输入总量必须包含其缓存子集。缓存数大于输入总量时应直接报错,而不是照常计算。把缓存 token 当成全价输入计费,或在已包含缓存的输入总量上再加一次缓存,是这套估算出现翻倍偏差最常见的原因。
编排总量仍是额外的:它们加在普通请求计数之上,而不是折进去。不同模型或 provider 可能返回不同的 envelope,不要用这个公式解析未经校验的 usage 对象。
2026 年 9 月 28 日 Ultra 标准费率仍是每百万 $5 / $0.50 / $30;上下文超过 272K 则为 $10 / $1.00 / $45。只有该次请求的上下文跨过阈值,才用高档。
3. 与计算器相同的工作示例
假设一个月的 Ultra 请求每次上下文都在标准档内,汇总后的原始总量为:用户输入 1,000,000(其中缓存 250,000),编排输入 2,000,000(其中缓存 500,000),最终输出 250,000,编排输出 500,000。每个缓存数都是其所归属输入总量的子集;这是很多次短请求的汇总,不是一次 1M 单请求,因此不会触发长上下文档。
未缓存输入 = (1,000,000 − 250,000) + (2,000,000 − 500,000) = 2,250,000 = $11.25;计费缓存输入 = 250,000 + 500,000 = 750,000 = $0.375;计费输出 = 250,000 + 500,000 = 750,000 = $22.50;合计 $34.125,显示为 $34.13。若忽略编排,你会记下 $11.375 再和财务争论。Ultra 与 Max 计算器就是把字段标清楚、并先减去缓存子集的这段算术。它仍然不能给标准 Fugu 或 Cyber 定价。
4. 避免第二次争论的运维规则
- 原始 usage 对象、算出的金额、所用费率版本要一起保存。
- 不要假设
total_tokens按一个混合单价计费。 - 应用输入费率前,先从各自的输入总量里减去缓存数,并保存你使用的未缓存数值。
- 缓存数大于其输入总量的 usage 对象应直接拒绝,不要悄悄截断。
- 不要把 Ultra 的
max_output_tokens当成花费上限。 - 272K 上下的流量要拆成两次计算。
- 合作方若不返回这些字段,就不能在没有新证据时套用此公式。
即使算出的美元金额看起来整齐,也要留下原始 JSON。以后定价页再变,或发现漏加了编排缓存,从字段修比重画一张合计截图便宜。标准 Fugu 没有这张公开固定表,Cyber 的公开表也已撤回,所以不要把这段公式套到那两款模型上。
把 usage 和请求 ID、模型 ID、当时使用的费率版本放在同一条日志里。下一次对账时,你要回答的不是“大概花了多少”,而是“哪一次 Ultra 请求因为编排输出把费用抬上去了”。计算器只是同一套算术的界面,不能替代保存原始对象。完整方法论见 价格说明。没有原始对象就无法复盘。
本页不覆盖什么
这里不给标准 Fugu 编混合单价,也不恢复已撤回的 Cyber 公开表。公式只适用于官方仍公布固定费率、且返回编排字段的 Ultra 请求。合作方发票如果字段不同,需要另做证据,不能直接套用。