Anthropic 最新、也是其广泛发布中能力最强的模型 Claude Fable 5（model id claude-fable-5）上线后，不少从 Opus 档迁移过来的团队会在第一张账单上发现一个反直觉的现象：业务逻辑、提示词、上下文都没动，可同一批请求消耗的 token 明显变多了。原因不在你的代码，而在模型底层换了一套新的分词器（tokenizer）。官方给出的定性结论是：相同内容在 Fable 5 上的 token 数，比 Opus 档大约多 30%。这篇文章想把这件事讲清楚——为什么会这样、它如何叠加到价格上、以及工程上该怎么应对。

分词器是计费的真正单位

大模型并不直接「按字数」或「按字符」处理文本，而是先把文本切成一串 token，再在 token 序列上做计算。计费同样发生在 token 这一层：Fable 5 的定价是输入 $10 / 百万 token、输出 $50 / 百万 token。也就是说，你的成本 = token 数 × 单价，而 token 数完全由分词器决定。

不同分词器对同一段文本的切分粒度可以差别很大。一个分词器把 tokenizer 当成一个 token，另一个可能切成 token + izer 两个；中文、代码、非英文文本上的差异往往更明显。所以当 Anthropic 在 Fable 5 上换用一套新的分词器时，即便文本一个字没变，序列长度也会整体抬高。官方给的「约多 30%」是一个跨工作负载的经验值，具体倍数会随内容形态（自然语言 / 代码 / 多语言混排）而浮动——这是一个定性的、需要你自己实测的量，而不是一个可以照搬的硬系数。

30% 的 token 如何叠加成更高的账单

把这件事拆开看，它其实在两个维度上同时推高了成本。

第一个维度是 token 数本身的增长。假设你原先在 Opus 档上一个请求消耗约 NN 个输入 token，迁移到 Fable 5 后，同样的内容大致变成 1.3N1.3N 左右。

第二个维度是单价。Fable 5 处在 Opus 之上的价位段，输入 $10、输出 $50（每百万 token）本身就高于 Opus 档。两者相乘，迁移后的实际账单涨幅会比单看「多 30% token」更大。

不仅是钱。token 数变多还意味着：

  • 上下文预算更紧张。Fable 5 默认即提供 1M token 的上下文窗口（这也是它的最大值），但你原来在旧模型上「刚好塞进窗口」的长文档，换算到新分词器后可能会更接近上限。
  • max_tokens 需要重新标定。单次最多可输出 128K token，但你为旧模型调好的 max_tokens 值（无论是输出上限还是 compaction 触发阈值）都是按旧分词器的尺度算的，直接沿用容易出现「以为留够了余量、实际被截断」的情况。

一句话：在旧模型上测得的任何 token 数、上下文预算、max_tokens 设定都不应直接迁移过来。

不要拍脑袋乘 1.3，去实测

最危险的做法是把「30%」当成一个魔法系数，在成本计算器里全局乘一个 1.3 就收工。因为这个比例会随内容形态变化，代码密集或多语言的负载可能偏离这个均值。正确做法是用 count_tokens 接口，在 你自己的代表性提示词样本 上实测。

更贴心的是，当你向计数接口传入 model: "claude-fable-5" 时，响应会同时返回两套分词器下的计数：新分词器下的 input_tokens（也就是真正计费的那个），以及同一请求在上一代分词器下的 input_tokens_prior_tokenizer。这意味着你可以在一次调用里直接量出迁移带来的 token 增量，而不必去对比两个模型的两次请求。

1
2
3
4
5
6
7
8
9
10
from anthropic import Anthropic

client = Anthropic()
resp = client.messages.count_tokens(
    model="claude-fable-5",
    messages=[{"role": "user", "content": open("prompt.md").read()}],
)
new_tokens = resp.input_tokens                  # 新分词器，计费口径
old_tokens = resp.input_tokens_prior_tokenizer  # 上一代分词器，用于对比
print(f"增量 {(new_tokens / old_tokens - 1) * 100:.1f}%")

顺带提醒：不要用 tiktoken 之类 OpenAI 系的分词器去估 Claude 的 token，它本来就和 Claude 的切分口径不一致，在 Fable 5 的新分词器面前只会错得更离谱。客户端那些基于旧分词器近似值校准过的 token 估算器、成本看板、按 token 数设阈值的限流重试逻辑，迁移时都值得重新核对一遍。

控成本的几个真实杠杆

token 变多不代表只能被动接受更高的账单。Fable 5 提供了几个能切实压低开销的控制点：

  • output_config.effort：Fable 5 的思考始终开启、不可关闭，但你可以用 effort（low / medium / high / xhigh / max）来调节思考深度与整体 token 开销。对例行、不那么吃智能的任务，low / medium 往往就够用——而且 Fable 5 在低 effort 下的表现常常仍然不俗。如果一个任务结果正确但耗时偏长，往下调 effort 通常是第一选择。
  • 提示词缓存：注意 Fable 5 的最小可缓存前缀是 2048 token（与 Opus 4.8 的 4096 不同），命中后缓存读取约为基础输入价的 0.1 倍，是摊薄长前缀成本的主力手段。
  • Task Budgets（beta）：在长程 agentic 循环里给模型一个 token 预算，让它自己量入为出地收尾。

需要强调，这些控制项在压成本的同时可能会让渡一部分模型智能，调参时要在自己的评测集上权衡。

结语

Fable 5 的「同样的话贵了三成」并不是 bug，而是新分词器把文本切得更细带来的必然结果，再叠加上更高的价位段——理解这一点，迁移时就该做一件事：用 count_tokens 带上 model: "claude-fable-5" 在自己的真实提示词上重新标定 token、上下文与 max_tokens，而不是套用任何现成的倍数。