Token 成本三刀归因

这一刀之所以排第一，是因为它决定了后面所有动作的方向，而且判据是一个可以直接算的公式：

单次调用成本 = I × 单价 + O × 单价 × k        I=输入token  O=输出token  k=输出/输入倍数

缓存能省的比例（缓存把输入压到 0.1×）：

    节省率 = 0.9 · I / (I + k·O)

代入三种典型形态（k=5，Anthropic 口径）：

这张表就是"上了缓存还是没省钱"的全部解释。 它兑现了一条已经冻结的判断：缓存只作用于输入侧被缓存的那一段；如果成本大头在输出或思考 token 上，缓存救不了，这时候正确动作是去看 effort 和输出长度。

所以第一刀的操作很简单：从账单或 trace 里拉出输入 token 总量和输出 token 总量，各自乘上单价，看哪边涨得多。 不要猜，这是一个查询就能出的数。

输入侧的四个成因，按发现难度从易到难：

1. 工具结果累积。最常见，也最容易被低估。工具结果默认是永久居民，成本按剩余轮次复利。一个 4000 token 的返回体在 10 轮会话里被重复计费近 10 次。
2. 上下文膨胀。检索条数调大了、few-shot 例子加多了、历史没有压缩。
3. 缓存命中率塌陷。这是唯一会静默发生的一类——在缓存前缀里插入任何每次都变的东西（时间戳、随机 ID、用户名）都会让命中率归零，而账单上只表现为"输入侧变贵了"。排查方法是直接看响应里的缓存读取 token 数与创建 token 数的比值。
4. 前缀长度低于最小可缓存门槛。截至 2026-08，Anthropic 按模型分四档：512 / 1024 / 2048 / 4096。低于门槛静默不缓存、不报错。 所以"我明明开了缓存"和"缓存真的生效了"是两件事。

输出侧的三个成因：

1. effort 档位。这是 2026 年最大的一个隐形开关。官方对它的定位是"行为信号而非硬预算"——它缩放整个响应，包括思考。而 Anthropic 的默认值就是 high。
2. 输出长度。max_tokens 设得过大不直接计费，但会让模型倾向于写更长；prompt 里"请详细说明"这类措辞的成本弹性极大。
3. 工具调用次数。这条最容易被漏掉，而且它是输出侧影响输入侧的通道——effort 提高会让工具调用次数变多，每一次调用又把工具结果永久留在上下文里。开头那个故障的第 1 条和第 2 条就是这样耦合的。

因此有一条必须写进结论的约束：降 effort 会改变工具调用次数和轨迹，所以任何档位调整都必须重跑轨迹评测，不能只看最终答案。（承接 Q5-05 的轨迹评估与不变量断言）