Claude Fable 5.1 提示缓存经济学：盈亏平衡计算、请求模式与路由策略

Fable 5.1 的缓存读取从每百万 token $1.00 降到了 $0.25，降幅 75%。这让缓存密集型工作负载便宜了大约 25%，长时间 agent 运行最多能省 45%。但标价没动，输入仍然 $10/MTok，输出仍然 $50/MTok。如果你的应用从不使用缓存，Fable 5.1 的账单和 Fable 5 一模一样，一分不差。

我们写这篇指南，是因为缓存经济学现在直接决定了 Fable 5.1 和更便宜的模型之间该怎么选。答案取决于你的缓存命中率、上下文长度和 agent 执行了多少步，而不是 75% 这个数字本身。

本文数据来自以下来源，均于 2026-09-14 检索。Anthropic 定价页、Anthropic 提示缓存文档、Anthropic Fable 5.1 公告、VentureBeat 报道。

---

一句话看变化

0.025x 的缓存读取倍率只适用于 Fable 5.1 和 Mythos 5.1。其他 Claude 模型都是 0.1x。这个不对称性就是全部经济学。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

---

Anthropic 提示缓存的工作机制

Anthropic 会缓存提示前缀对应的注意力层 KV 张量。后续请求如果共享相同前缀，模型跳过重新计算，按缓存读取费率计费，而不是按基础输入费率。

可选两种模式。

• 自动缓存，在请求级别加上 cache_control: {"type": "ephemeral"}。系统把缓存断点放在最后一个可缓存内容块的末尾，随着对话增长自动前移。
• 显式断点，在单独的内容块上放置 cache_control，精确控制缓存范围。

几个关键约束需要注意。

• 最小可缓存前缀 Haiku 模型 1,024 token，其他所有模型（包括 Fable 5.1）2,048 token。
• TTL 选项 5 分钟临时缓存（写入成本 1.25x 输入价）或 1 小时扩展缓存（写入成本 2x 输入价）。缓存读取会自动刷新 TTL。
• 仅前缀 缓存严格基于前缀。如果可变内容出现在静态上下文之前，缓存不会触发。

usage 响应中包含 cache_creation_input_tokens 和 cache_read_input_tokens 字段，能精确追踪有多少 token 命中了缓存、多少是新写入的。

---

缓存定价的五个 token 桶

每个 Fable 5.1 请求最多产生五类计费 token，理解它们才能算盈亏平衡。

1. 未缓存输入 token 按 $10/MTok 计费。出现在缓存前缀之后的内容，或者首次请求尚未建立缓存时的全部输入。
2. 5 分钟缓存写入 token 按 $12.50/MTok 计费（1.25x 输入价）。首次请求建立缓存前缀或缓存过期后重建时产生。
3. 1 小时缓存写入 token 按 $20/MTok 计费（2x 输入价）。同上，但保留窗口更长。
4. 缓存读取 token 按 $0.25/MTok 计费（0.025x 输入价）。后续请求命中缓存前缀时产生。
5. 输出 token 无论是否缓存，统一 $50/MTok。

经济学归结为一个简单问题，从缓存读取 token 省下的钱（$0.25 代替 $10）能不能覆盖一次性的写入成本（$12.50 或 $20）。

---

盈亏平衡分析

5 分钟 TTL（临时缓存）

写入 P 个 token 到 5 分钟缓存，成本是 P × $12.50/MTok。每次后续缓存读取节省 P × ($10 - $0.25)/MTok = P × $9.75/MTok。

盈亏平衡读取次数 = $12.50 / $9.75 ≈ 1.28

只需 2 次缓存读取，写入成本就能回本。在旧版 Fable 5 定价下（缓存读取 $1.00），盈亏平衡是 $12.50 / $9.00 ≈ 1.39，也是 2 次，但利润更薄。Fable 5.1 的折扣没有改变盈亏平衡次数，但大幅增加了每次读取在回本之后的节省额。

回本后每次额外读取的节省额

• Fable 5 每次节省 $9.00/MTok
• Fable 5.1 每次节省 $9.75/MTok（多 8.3%）

1 小时 TTL（扩展缓存）

写入 P 个 token 到 1 小时缓存，成本是 P × $20/MTok。每次读取节省 P × $9.75/MTok。

盈亏平衡读取次数 = $20 / $9.75 ≈ 2.05

需要在一小时内 3 次缓存读取。Fable 5 下盈亏平衡是 $20 / $9.00 ≈ 2.22，也是 3 次。次数相同，但回本后每次读取省得更多。

实际问题在于缓存命中率

实际中盈亏平衡取决于你的缓存命中率，即输入 token 中有多少来自缓存读取而非新鲜输入。Anthropic 公布的数据显示，典型工作负载有效成本降低 25%，agent 工作负载最高达 45%。

从这些数字反推。

缓存命中率达到 80% 时，Fable 5.1 的输入成本低于 Opus 5 无缓存时的 $5/MTok。这是缓存折扣让前沿模型在输入成本上比低一级模型更便宜的临界点。

---

受益最多的请求模式

Agent 循环（节省最多）

Agent 在每一步都发送不断增长的上下文，包括系统提示、工具定义、任务描述，加上之前所有步骤的完整对话记录。前缀稳定且体量大，第一步之后，几乎所有输入 token 都是缓存读取。

一个 50 步的 agent 运行，配合 50K token 的系统提示和增长的上下文，缓存命中率可以达到 85-95%。在 Fable 5.1 上，有效输入成本在 $1.50 到 $2.50/MTok 之间，而不是 $10。

RAG + 稳定前导内容（中等节省）

如果你的 RAG 流程在检索到的内容块前面固定拼接一大段系统提示或参考文档，这段稳定前缀能很好地被缓存。检索到的内容和用户查询每次都不同，所以无法缓存。

典型缓存命中率 40-60%，取决于稳定前导内容和动态内容的比例。

多轮对话（可变节省）

每一轮把之前的交流追加到上下文里，增长的前缀通过自动缓存自然被缓存。早期轮次缓存命中率低，后期轮次接近 agent 循环的模式。

平均 8-12 轮的对话，整个会话的缓存命中率预期在 50-70%。

单次请求（没有节省）

只执行一次、内容完全独立的请求，比如一次性的摘要或单次分类，没有可缓存的内容。如果写入了缓存却从未读取，你白白多付了 25%（或 100%）的写入附加费。

---

系统提示和前缀结构策略

缓存命中要求前缀完全匹配。合理安排请求结构以最大化稳定前缀，是工程投入直接转化为成本节省的地方。

模式 1 静态系统提示 + 工具在前，用户内容在后

{
  "model": "claude-fable-5.1",
  "cache_control": {"type": "ephemeral"},
  "system": "你的 5000 token 系统提示...",
  "tools": [...],
  "messages": [
    {"role": "user", "content": "可变的用户输入"}
  ]
}

系统提示和工具定义构成缓存前缀。用户内容每次请求都变，但不会破坏上面前缀的缓存。

模式 2 参考文档作为早期消息

RAG 风格的工作流中，把参考文档作为早期的用户/助手交互插入，放在实际查询之前。

{
  "model": "claude-fable-5.1",
  "cache_control": {"type": "ephemeral"},
  "system": "你是一个研究助手...",
  "messages": [
    {"role": "user", "content": "[参考文档 A — 20K token]"},
    {"role": "assistant", "content": "我已经阅读了参考材料。"},
    {"role": "user", "content": "根据上述内容回答：[可变查询]"}
  ]
}

系统提示 + 参考文档构成约 20K token 的缓存前缀。可变查询是唯一未缓存的输入。

模式 3 显式断点实现多段缓存

需要精细控制时，在特定内容块上放置 cache_control。

response = client.messages.create(
    model="claude-fable-5.1",
    max_tokens=4096,
    system=[
        {
            "type": "text",
            "text": "你的稳定系统提示...",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": large_reference_document,
                    "cache_control": {"type": "ephemeral"}
                },
                {
                    "type": "text",
                    "text": "请回答我的具体问题..."
                }
            ]
        }
    ]
)

这样系统提示和参考文档分别被缓存，形成两个缓存断点。

---

路由决策：Fable 5.1 在什么时候比便宜模型划算

缓存折扣制造了一个不太直觉的路由问题。缓存后的 Fable 5.1 在什么时候单请求成本低于未缓存的便宜模型？

Fable 5.1 缓存 vs Opus 5 无缓存

高缓存命中率下，Fable 5.1 在输入上胜出，但输出成本是 Opus 5 的两倍。输入密集型任务（大上下文、短回答）中，缓存后的 Fable 5.1 可能比无缓存的 Opus 5 更便宜。输出密集型任务（代码生成、长文写作）中，输出溢价是主导因素。

Fable 5.1 缓存 vs Sonnet 5 无缓存

即使 80% 缓存命中，Fable 5.1 的输入成本也只是接近 Sonnet 5 的无缓存输入价，而输出贵了 5 倍。除非你确实需要 Fable 级别的推理能力，并且输入端的节省能在你的工作负载中抵消输出端的溢价，否则 Sonnet 5 在纯成本上更优。

路由判断标准

缓存感知路由在以下条件全部满足时有意义。

1. 工作负载有高缓存命中率（60% 以上的输入 token 来自缓存读取）
2. 任务是输入密集型（大上下文窗口，相对较短的输出）
3. 你需要 Fable 级别的推理能力（任务在更便宜的模型上失败或质量下降）

三个条件同时成立时，带缓存的 Fable 5.1 可以是性价比最高的前沿选项。任何一个不成立，就应该考虑路由到 Opus 5 或 Sonnet 5，它们各自也支持缓存（都用标准的 0.1x 缓存读取倍率）。

通过 TheRouter 路由请求时，fallback 链可以包含缓存感知的决策。高复杂度、上下文大部分已缓存的任务走 Fable 5.1，缓存不适用或输出量主导成本的任务降级到 Opus 5 或 Sonnet 5。

---

对比：Fable 5.1 缓存 vs 其他提供商

提示缓存不是 Anthropic 独有的。下面对比 Fable 5.1 的缓存读取折扣和其他提供商的差异。

在前沿模型中，Fable 5.1 的 0.025x 倍率是所有主流提供商里最激进的缓存读取折扣。OpenAI 的 24 小时扩展保留以 0.25x 在绝对金额上有竞争力，但基础价格不同。

更详细的跨提供商缓存对比请参阅我们的提示缓存指南（OpenAI、Anthropic 与 DashScope）。

---

常见陷阱

只写不读。 如果你在很少重复的请求上启用了缓存，你付了 25% 的写入附加费（或 1 小时 TTL 的 100% 附加费）却永远收不回来。上线前先审查 usage 响应中的缓存读取/写入比。

可变内容破坏前缀。 时间戳、请求 ID 或任何动态值插入到提示的早期位置，会让它之后的所有内容缓存失效。把所有可变内容移到消息数组的末尾。

TTL 选择不匹配。 5 分钟 TTL 写入更便宜但过期快。如果你的请求间隔超过 5 分钟，缓存在第二次读取前就已过期。批处理工作流选 1 小时 TTL，实时 agent 选 5 分钟。

忽略分词器变化。 Claude 4.7 及之后的模型（包括 Fable 5.1）使用的新分词器对相同文本产生大约 30% 更多的 token。从旧模型迁移时要把这个因素算进成本预估。

---

上线清单

部署带缓存的 Fable 5.1 之前确认以下事项。

• 测量缓存命中率。 从 usage 响应中记录 cache_read_input_tokens 和 cache_creation_input_tokens，至少跑 24 小时生产流量。
• 计算有效输入成本。 公式 (未缓存 token × $10 + 缓存写入 token × $12.50 + 缓存读取 token × $0.25) / 总输入 token。
• 和替代方案对比。 如果有效输入成本超过 $5/MTok，考虑 Opus 5（无缓存 $5/MTok）在可接受质量下是否成本更低。
• 优化提示结构以最大化前缀重叠。 静态内容在前，动态内容在后。自动缓存的断点位置不理想时改用显式断点。
• 选对 TTL。 高频 agent 循环用 5 分钟。批处理或低频工作流用 1 小时。
• 监控写入/读取比。 健康的缓存部署的写入/读取比应当远低于一比二。写入占主导说明缓存在频繁失效。
• 别忘了输出成本。 Fable 5.1 输出 $50/MTok 是大多数工作负载中最大的成本项。输入端的缓存节省不会减少输出成本。

---

FAQ

75% 缓存读取折扣适用于所有 Claude 模型吗？

不适用。0.025x 缓存读取倍率（$0.25/MTok）只属于 Fable 5.1 和 Mythos 5.1。其他 Claude 模型的缓存读取倍率是 0.1x。Opus 5 缓存读取 $0.50/MTok，Sonnet 5 缓存读取 $0.20/MTok。

Fable 5.1 的提示缓存是自动的吗？

缓存默认不开启。你必须在请求中加入 cache_control，要么在请求级别用于自动缓存，要么在单独的内容块上用于显式断点。不加的话，每个 token 都按完整输入费率计费。

缓存会影响输出质量吗？

不会。缓存存储的是输入前缀的中间计算（注意力 KV 张量）。模型的生成行为在输入被缓存和重新处理时完全相同。

可以通过 TheRouter 使用提示缓存吗？

TheRouter 将 OpenAI 兼容请求路由到已配置的提供商。上游提供商是 Anthropic 且请求中包含 cache_control 时，缓存行为会透传到 Anthropic API。TheRouter 支持跨已配置提供商的模型路由与 fallback。

新分词器对缓存成本有什么影响？

Fable 5.1 使用的分词器对相同文本产生大约比 Claude 4.6 及更早版本多 30% 的 token。同样的系统提示在 token 量上贵了约 30%，但 75% 的缓存读取折扣在缓存内容上远远补偿了分词器膨胀带来的成本增加。