Claude Fable 5 缓存：契约不变，账单却是 Opus 4.6 的 2.9 倍

claude-fable-5 现已在 Synthorai gateway 上线。对于使用 Claude 系列缓存的团队来说，好消息是缓存与 TTL 契约完全沿用：cache_control 标记不变，仍支持 5 分钟和 1 小时 TTL，写入溢价与深度读取折扣也都相同。只需改一个字符串，现有缓存代码就能迁移。

真正需要重新做预算的不是缓存机制，而是账单。Fable 5 的 token 标价是 Opus 的 2 倍，同一段英文文本产生的 token 数又比 Opus 4.6 多约 45%（它使用 4.6 之后的新 tokenizer，与 Opus 4.8 完全相同）。两个倍率会叠加。本文给出了完整实测结果。

迁移前还要检查一个与缓存无关的限制：Fable 5 不支持零数据保留。在它上线的所有 cloud 上，都必须保留数据 30 天。

TL;DR

• Claude Fable 5 完整沿用 Anthropic 的缓存契约：cache_control 标记相同，TTL 仍为 5 分钟和 1 小时，写入溢价约为 1.25x/2x，实测 warm read 成本约为无缓存价格的 6%。
• 相同文本在 Fable 5 和 Opus 4.8 上均为 9,619 个 token，在 Opus 4.6 上则为 6,614 个，多出 45%。
• Fable 5 的标价为输入 $10/M、输出 $50/M，是 Opus 档位的 2 倍。
• 因此，相同 prompt 的成本是 Opus 4.6 的 2.9 倍（1.45 倍 token x 2.0 倍价格），测量日期为 2026-06-10。

以下所有数据均于 2026-06-10 在 https://synthorai.io/ 上通过 Anthropic 原生 /v1/messages 接口测得。测试使用稳定的约 6.6–9.6K token 英文 system prompt，max_tokens 设为较小值，并按顺序单次运行。成本取自 gateway 的 usage.cost 字段；可迁移参考的是各项比例（token 数、写入溢价、读取折扣、跨模型成本），绝对金额会随 prompt 而变化。对外引用前，请用自己的 prompt 复测。

可用性

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 上下文窗口。行为上有一点需要注意：它是 reasoning 模型，默认会生成 thinking token。我们的测试中，即使只要求“reply OK”，返回的 output_tokens_details.thinking_tokens > 0，而 Opus 4.6/4.8 均为零。做预算时要计入这部分输出 token。cache_control 的具体机制见缓存教程；缓存为何存在及其架构原理见本系列第 1 篇。

关键变化：Fable 5 使用新 tokenizer

Opus 系列从 4.7 这一代开始，token 数明显增加。同一段英文文本在 4.6 上约为 6.6K 个 token，到 4.8 则约为 9.6K。Fable 5 使用新版 tokenizer，相同文本得到的 token 数与 Opus 4.8 完全一致。

同一个 system prompt 在 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 这一代引入的 tokenizer/词表更新最为吻合。如果从 4.6 或更早版本迁移，请重新测量；如果从 4.7/4.8 迁移，token 数应当持平。

缓存行为：契约没有变化

我们分别在每个模型上执行了同样的无缓存、cold write 和 warm read 流程。整个折扣结构完全一致。Fable 5 支持 cache_control，并返回相同的 usage 字段，包括 cache_creation_input_tokens、cache_read_input_tokens，以及 ephemeral_5m / ephemeral_1h bucket。

三个模型都遵循以下两条规律：

• 写入溢价约为 1.25x（5m）和 2x（1h）。 首次 cold call 会写入缓存：5 分钟 entry 的成本约为无缓存价格的 1.25 倍，1 小时 entry 则约为 2 倍。命中一次即可回本。
• 读取折扣超过约 90%。 Fable 5 的 warm cache read 成本约为无缓存调用的 6%，即折扣约 94%。这与 Anthropic 文档中约 90% 的缓存读取折扣一致，甚至略好。无论 TTL 取何值，读取都能获得大幅折扣。

各模型的百分比基本持平。与 Opus 4.7 → 4.8 的升级一样，Fable 5 的绝对账单更高，是价格和 token 数共同造成的，并不是缓存经济模型发生了变化。下一节会详细说明。

TTL 行为：两个时间窗口均有效

Fable 5 与系列内其他模型一样，支持两种 TTL：默认的 5 分钟滑动窗口，以及需要显式启用的 1 小时窗口。我们为每次调用使用唯一前缀，分别测试两种 TTL，避免旧 entry 干扰结果。usage 对象会正确返回对应 bucket，即 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 小时 TTL 的写入成本约为无缓存的 2 倍，5 分钟 TTL 则约为 1.25 倍。无论使用哪种 TTL，读取都能获得大幅折扣，与 Opus 4.6/4.8 完全一致。如果在 Opus 上为实时聊天选择 5m，为存在人工介入停顿的 agent 选择 1h，迁移到 Fable 5 后可以保持原方案。

成本：2x 价格 x 1.45x token

Fable 5 真正的差异在成本上。账单上涨由两个因素共同推动，而且两者会相乘。

1. 标价是 Opus 档位的 2 倍。

2. 相同文本产生的 token 数比 4.6 多约 45%，原因就是前面提到的 tokenizer 变化。

两个因素相乘后，同一段英文 prompt 的成本会明显增加。我们在每个模型上使用完全相同的 system prompt，通过 gateway usage.cost 做了同样的单次运行测量：

与使用相同 tokenizer 的 Opus 4.8 相比，Fable 5 的成本正好是 2 倍，差异完全来自价格。与 Opus 4.6 相比，tokenizer 变化和价格变化叠加，同一 prompt 的成本约为 2.9 倍。缓存折扣没有变化，但折扣所作用的绝对成本基数约为 4.6 的 2.9 倍。如果单次调用预算是按 4.6 制定的，需要重新计算。

另一个实际影响是：需要重新检查 1,024 token 的缓存准入下限。 Anthropic 只会缓存达到最小长度要求的前缀。某个 prompt 在 4.6 的旧 tokenizer 下可能略低于下限，到了 Fable 5 上由于 token 数增加约 45%，就可能达到要求。反过来，基于旧 token 数做出的大小估算也可能失准。应始终读取线上响应中的 cache_creation_input_tokens / cache_read_input_tokens，不要依赖可能与服务端不一致的本地 tokenizer 估算。

迁移检查清单（Opus → Fable 5）

• ✅ 缓存代码可原样沿用。 cache_control 标记、breakpoint 数量上限（最多 4 个）、ttl: "1h" 以及 usage 字段名都完全相同。
• ✅ TTL 方案可直接沿用。 实时或 session 型 workload 使用 5m；突发型 workload 或会中途暂停的 agent 使用 1h。
• ✅ 折扣机制保持不变。 读取折扣约 90%+；写入成本约为 1.25x（5m）或 2x（1h）。
• ⚠️ 按绝对成本重新做预算。 Fable 5 的单位 token 价格约为 Opus 的 2 倍，相同 prompt 的成本约为 Opus 4.6 的 2.9 倍。折扣比例不变，但计算折扣的成本基数变了。
• ⚠️ 如果从 4.6 或更早版本迁移，重新测量 token 数，相同文本预计会增加约 45%。从 4.7/4.8 迁移则应当持平。
• ⚠️ 计入默认生成的 thinking token。 Fable 5 默认会生成 reasoning token，并按输出价格（$50/M）计费。不需要时请限制或关闭 thinking。

结论

对于已经在 Claude 上使用缓存的团队，claude-fable-5 的集成迁移很简单：缓存和 TTL 的整套接口都没有变化，无需重新学习，也不用重写代码。但从 Opus 4.6 迁移时，预算不会同样轻松。单位 token 价格上涨 2 倍，再叠加 tokenizer 导致的约 45% token 增幅，同一 prompt 的成本约为原来的 2.9 倍。请通过线上 usage 对象确认实际数据，判断是否需要默认生成的 thinking token，并根据新的 token 数设置缓存 breakpoint。

完整的缓存实践，包括 prompt 结构、命中率排查和 TTL 感知模式，见完整 prompt 缓存指南、系列首篇 KV Cache 与 TTL 的工作原理以及可运行的 Python 教程。

常见问题

使用 Fable 5 时需要修改 cache_control 代码吗？ 不需要。标记语法、breakpoint 上限和 TTL 选项都与 Opus 系列相同。只需修改 model 字段，缓存链路中的其他部分无需调整。

Fable 5 的缓存读取折扣变了吗？ 没有。Warm read 的成本只占无缓存输入价格的个位数百分比，折扣超过约 90%。我们在 Fable 5 上实测约为 94%，与 Anthropic 文档中的缓存读取经济模型一致。

Fable 5 支持 1 小时 TTL 吗？ 支持。{"type": "ephemeral", "ttl": "1h"} 的行为与 Opus 完全相同。1 小时 TTL 的写入成本约为无缓存的 2 倍，5 分钟 TTL 则约为 1.25 倍。两种 TTL 的读取都能获得大幅折扣。

为什么同一个 prompt 在 Fable 5 上比 Opus 4.6 贵这么多？ 有两个叠加的倍率：Fable 5 的单位 token 标价是 2 倍；同一段英文文本的 token 数又多约 45%，因为它使用 4.6 之后的 tokenizer。两者叠加后，相同 prompt 的成本约为 2.9 倍。缓存折扣本身没有变化。

Fable 5 可以直接替换 Opus 4.8 吗？ 就缓存、TTL 和 token 数而言可以。两者的 token 数完全相同，差异只有 Fable 5 的价格是 2 倍，并且默认生成 thinking token。我们不会发布未经实测的能力 benchmark；质量和 reasoning 相关结论请参考 Anthropic 的 model card。

验证说明：所有 token 数、成本、写入溢价和读取折扣数据，均于 2026-06-10 使用官方 anthropic SDK 在 https://synthorai.io/ 上测得，采用单 tenant、单次顺序运行。成本读取自 gateway 的 usage.cost 字段；跨模型比率及溢价／折扣比率均根据这些实测成本计算，不受任何账号级促销影响。折扣与溢价比率还与 Anthropic Prompt Caching 文档进行了交叉核对。测试中的 warm-read 延迟（TTFT）主要受网络抖动影响，数据不可靠，因此未列出。实际结果会随 prompt、region 和负载而变化。

← 返回博客