Claude Fable 5：缓存、分词器与 Opus 4.6 的成本对比

claude-fable-5 现已在 Synthorai 网关上线。如果你在 Claude 系列上使用缓存，好消息是缓存和 TTL 契约完全延续：相同的 cache_control 标记、相同的 5 分钟和 1 小时 TTL、相同的写入溢价、相同的深度读取折扣。只需修改一个字符串，你的缓存代码即可迁移。

需要重点关注的不是缓存机制，而是账单。Fable 5 的标价是 Opus token 价格的 2 倍，而且它将相同的英文文本分词为比 Opus 4.6 多约 45% 的 token（使用 4.6 之后的分词器，与 Opus 4.8 完全相同）。这两个乘数叠加在一起，影响不容忽视。本文对所有数据进行了实测，省去你自己测量的麻烦。

以下所有数据均于 2026-06-10 在 https://synthorai.io/（Anthropic 原生 /v1/messages）上实测，使用约 6,600–9,600 token 的英文系统提示词，max_tokens 设置较小，单次顺序运行。成本数据读取自网关的 usage.cost 字段；比率（token 数量、写入溢价、读取折扣、跨模型成本）是可移植的部分——绝对金额会随你的提示词规模变化。在引用这些数据之前，请先用你自己的提示词进行验证。

可用性

import os
from anthropic import Anthropic

anth = Anthropic(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/",   # SDK appends /v1/messages
)

msg = anth.messages.create(
    model="claude-fable-5",             # the only line that changes
    max_tokens=512,
    system=[
        {"type": "text", "text": SYSTEM_PROMPT,
         "cache_control": {"type": "ephemeral"}},
    ],
    messages=[{"role": "user", "content": question}],
)
print(msg.usage)   # input_tokens, cache_creation_input_tokens, cache_read_input_tokens, cost

将 claude-opus-4-6 替换为 claude-fable-5，缓存路径中的任何代码都无需改动。Fable 5 是一个 Anthropic 原生模型，拥有 1M token 的上下文窗口。有一点行为需要注意：它是一个推理模型，默认会输出思考 token——即使是简单的”回复 OK”，在我们的测试中也返回了 output_tokens_details.thinking_tokens > 0，而 Opus 4.6/4.8 返回的是零。请相应地为输出 token 预留预算。cache_control 背后的机制详见缓存教程；缓存存在的架构原因详见系列文章第一部分。

核心发现：Fable 5 使用新版分词器

Opus 系列的 token 数量在 4.7 代发生了跳变：相同的英文文本在 4.6 上约为 6,600 token，在 4.8 上约为 9,600 token。Fable 5 属于新版一侧——相同文本报告的 token 数与 Opus 4.8 完全一致。

相同的系统提示词在 Fable 5 上的 token 数比 Opus 4.6 多约 45%（9,619 / 6,614 = 1.45）。这是迁移前最需要牢记的数字，因为所有下游数据——成本、1,024 token 的缓存资格门槛、每次调用的预算——都以 token 为单位计算。

我们描述的是一个实测观察——相同文本在 Fable 5 和 Opus 4.8 上的 token 数完全一致，比 Opus 4.6 多约 45%——这与 4.7 代引入的分词器/词汇表更新最为吻合。如果你从 4.6 或更早版本迁移，请重新测量；如果从 4.7/4.8 迁移，预期结果相同。

缓存行为：契约保持不变

我们在每个模型上运行了相同的无缓存 / 冷写入 / 热读取序列。折扣结构从头到尾完全一致——Fable 5 支持 cache_control 并报告相同的 usage 字段（cache_creation_input_tokens、cache_read_input_tokens 以及 ephemeral_5m / ephemeral_1h 分桶）。

以下两个规律在三个模型上均成立：

• 写入溢价 ≈ 1.25x（5 分钟），≈ 2x（1 小时）。 第一次（冷）调用需要支付约 1.25 倍的无缓存价格来填充 5 分钟条目，或约 2 倍来填充 1 小时条目。命中一次即可回本。
• 读取折扣 ≈ 90% 以上。 Fable 5 上的热缓存读取成本约为无缓存调用的 6%——折扣约 94%，与 Anthropic 文档中约 90% 的缓存读取经济性一致（甚至略优）。无论 TTL 如何，读取始终享有深度折扣。

各百分比在整个系列中保持不变。与 Opus 4.7 → 4.8 的升级一样，Fable 5 更高的绝对账单是价格和 token 数量的问题，而非缓存经济性的问题——详见下一节。

TTL 行为：两个时间窗口均受支持

Fable 5 支持与系列其他模型相同的两种 TTL：5 分钟滑动默认值和可选的 1 小时窗口。我们为每次调用使用唯一前缀（以防止旧条目污染结果）来隔离每种 TTL，并确认 usage 对象报告了正确的分桶——cache_creation.ephemeral_5m_input_tokens 或 ephemeral_1h_input_tokens。

# 1-hour TTL — same marker syntax on Fable 5 as on the Opus line
"cache_control": {"type": "ephemeral", "ttl": "1h"}

1 小时写入的成本约为无缓存的 2 倍（而 5 分钟写入约为 1.25 倍），读取无论 TTL 如何都保持深度折扣——与 Opus 4.6/4.8 完全一致。如果你在 Opus 上为实时聊天选择了 5m、为有人工介入暂停的 Agent 选择了 1h，在 Fable 5 上保持这些选择即可。

成本分析：2 倍价格 × 1.45 倍 token 数

这才是 Fable 5 真正不同的地方。两个因素推高了账单，且它们相互叠加。

1. 标价是 Opus 层级的 2 倍。

2. 相同文本比 4.6 多约 45% 的 token（即上文所述的分词器变化）。

两者相乘，相同的英文提示词成本会大幅增加。在每个模型上针对相同系统提示词的实测结果（网关 usage.cost，同一次单次运行）：

因此，与 Opus 4.8（相同分词器）相比，Fable 5 是干净的 2 倍——纯粹的价格溢价。与 Opus 4.6 相比，分词器变化与价格变化叠加，相同提示词的成本约为 2.9 倍。你的缓存折扣保持不变，但其所基于的绝对基数比 4.6 时大了约 2.9 倍。如果你根据 4.6 设定了每次调用的预算，请重新计算。

一个实际影响：重新检查 1,024 token 的缓存资格门槛。 Anthropic 只缓存达到或超过最小大小的前缀。在 4.6 上（旧分词器 token 数）刚好低于门槛的提示词，在 Fable 5 上（多约 45% 的 token）可能会超过门槛——反之亦然，基于旧 token 数的大小估算也可能失效。请始终从实时响应中读取 cache_creation_input_tokens / cache_read_input_tokens，而不是用可能与实际不符的本地分词器进行估算。

迁移清单（Opus → Fable 5）

• ✅ 缓存代码可原样迁移。 cache_control 标记、断点数量（最多 4 个）、ttl: "1h"、usage 字段名称——全部相同。
• ✅ TTL 选择可延续。 实时/会话工作负载用 5 分钟，有暂停的突发/Agent 工作负载用 1 小时。
• ✅ 折扣经济性延续。 读取折扣约 90% 以上，写入溢价约 1.25x（5 分钟），约 2x（1 小时）。
• ⚠️ 重新规划绝对成本预算。 Fable 5 每 token 约为 Opus 的 2 倍，与 Opus 4.6 相比相同提示词的成本约为 2.9 倍。折扣百分比不变，但其所基于的基数已变。
• ⚠️ 重新测量 token 数量（如果从 4.6 或更早版本迁移，预期相同文本多约 45%）。从 4.7/4.8 迁移则预期相同。
• ⚠️ 考虑默认思考 token 的影响。 Fable 5 默认输出推理 token——按输出费率计费（$50/M）。如果不需要，请限制或禁用思考功能。

总结

对于已在 Claude 上使用缓存的团队来说，claude-fable-5 的集成非常简单：整个缓存和 TTL 接口保持稳定，无需重新学习，也无需重写代码。但从 Opus 4.6 迁移时，它并不是一个简单的预算替换——2 倍的 token 价格加上约 45% 的分词器膨胀，相同提示词的成本约为原来的 2.9 倍。请对照实时 usage 对象确认你的数据，决定是否需要默认思考 token，并根据新的 token 数量重新设定缓存断点。

完整的缓存使用手册——提示词结构、命中率调试、TTL 感知模式——请参阅从 KV 缓存与 TTL 工作原理 开始的四部分系列文章，以及可运行的 Python 教程。

常见问题

← 返回博客