Synthorai 上的 Claude Opus 4.8：缓存与 TTL 对比 4.7/4.6

claude-opus-4-8 现已接入 Synthorai 网关。如果你已经在 Opus 系列上使用提示词缓存，可以放心：缓存和 TTL 约定与 4.7、4.6 完全相同。 cache_control 标记没变，5 分钟和 1 小时 TTL 没变，读取折扣和写入溢价也没变。现有缓存代码可以直接沿用。

真正发生变化的只有一项，而且变化始于 4.7，并非 4.8：它会影响你的 token 预算。本文给出了实测数据。

TL;DR

• Claude Opus 4.8 的缓存约定与 4.7/4.6 完全相同：实测读取折扣为 89%，5 分钟 TTL 的写入溢价约为 1.25 倍，1 小时 TTL 约为 2 倍。
• 相同的 system 文本在 Opus 4.7/4.8 上报告的输入 token 数比 4.5/4.6 多约 43%（11,394 对 7,976 个 token）。
• 整个 Opus 系列的单 token 价格相同：4.8/4.5 的成本比为 1.43，与 1.429 的 token 数量比一致。
• Opus 4.5 至 4.8 的热缓存读取 TTFT 均处于 2.2–2.8 秒区间，差异来自抖动。

以下数据均于 2026-05-29 通过 https://synthorai.io/（Anthropic 原生 /v1/messages）测得。测试使用约 8K 字符的英文 system prompt、较小的 max_tokens，并按顺序单次运行。引用前请使用自己的 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-opus-4-8",            # 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)   # cache_creation_input_tokens, cache_read_input_tokens, cost

只需将 claude-opus-4-7 替换为 claude-opus-4-8，缓存链路的其他部分都不用改。cache_control 的工作机制详见缓存教程；缓存存在的架构原因则见本系列第 1 篇。

缓存行为：与 4.7/4.6 相同

我们在近期的几个 Opus 版本上依次执行了相同的缓存写入、缓存读取和无缓存请求。各版本的折扣结构完全一致。

四个版本都有两项不变：

• 读取折扣约为 89%。 热缓存读取成本约为无缓存输入价格的 11%。这与 Anthropic 文档中的 10% 缓存读取费率一致，没有变化。
• 写入溢价约为 25%。 首次冷请求需要填充缓存，成本约为无缓存价格的 1.25 倍。命中一次即可回本。

4.7 和 4.8 的绝对成本高于 4.5/4.6，但原因是 token 数量增加，并非缓存成本模型发生变化。各版本的折扣比例保持不变。

TTL 行为：与 4.7/4.6 相同

Opus 4.8 支持与其他版本相同的两种 TTL：默认采用 5 分钟滑动过期，也可以显式选择 1 小时。我们为每次调用使用唯一前缀，避免旧缓存条目干扰结果，并分别测量两种 TTL 的写入溢价：

# 1-hour TTL — same marker syntax on 4.8 as on 4.7/4.6
"cache_control": {"type": "ephemeral", "ttl": "1h"}

usage 对象报告 TTL 分桶的方式也与之前完全相同，仍然是 cache_creation.ephemeral_5m_input_tokens 或 ephemeral_1h_input_tokens。1 小时写入成本约为无缓存的 2 倍，而 5 分钟写入约为 1.25 倍。无论 TTL 如何，读取成本都保持在约 11%。这与 4.7 完全一致。如果你在 4.7 上为实时聊天选择 5m，为包含人工等待环节的 agent 选择 1h，迁移到 4.8 后无需调整。

首 token 延迟：各版本基本持平

我们通过 streaming 调用测量了热缓存读取的 TTFT。网关预热后，每个模型采集 5 个样本，并报告中位数。在这份约 8–11K token 的 prompt 上，各版本的 TTFT 均处于约 2.2–2.8 秒区间，没有明显的版本趋势。样本区间相互重叠，差异来自抖动，并非版本本身。

这里有两点需要说明：

• 不要据此给模型排名。 各版本的范围高度重叠，4.8 的 4.38 秒高值属于离群样本。对于这种规模的 prompt，TTFT 主要受网络和队列抖动影响，而非模型版本。四个版本的热缓存 TTFT 都可以按约 2.2–2.8 秒估算。
• 缓存带来的 TTFT 收益会随 prompt 长度增加。 在约 8–11K token 时，缓存命中省下的 prefill 时间很少，因此冷请求和热缓存请求的 TTFT 接近。在已预热的网关上，两者都约为 2–3 秒。到了 100K+ token，prefill 会成为主要耗时，差距将明显扩大。此时，热缓存可以把数秒等待缩短到快速返回首个 token。具体机制见第 1 篇：KV Cache 与 TTL 的工作原理。

唯一的实质变化：tokenization（始于 4.7）

迁移前需要重新确认这一点：相同的 system 文本在 4.7/4.8 上报告的输入 token 数比 4.5/4.6 多约 43%。

token 数量从 4.7 开始增加，并延续到 4.8。成本几乎与 token 数量同比增长：4.8 与 4.5 的成本比为 1.43，token 数量比为 1.429。整个系列的单 token 价格相同。4.7/4.8 费用更高，完全是因为相同文本被计算为更多 token。

这会带来两个实际影响：

1. 按绝对成本重新编制预算，不要只看折扣。 缓存读取折扣仍约为 89%，但相同的英文 prompt 在 4.7/4.8 上的绝对成本比 4.6 高约 43%。如果单次调用预算基于 4.6 的 token 数量制定，就会出现偏差。
2. 重新检查 1,024 token 的缓存资格下限。 Anthropic 只缓存达到最低长度的前缀。4.6 上略低于下限的 prompt，在 4.7/4.8 上可能因为 token 数量增加而达到要求。按旧 tokenizer 的 token 数量设计的 prompt 也需要重新测量。应始终读取实时响应中的 cache_creation_input_tokens / cache_read_input_tokens，不要依赖本地 tokenizer 估算，因为两者可能不一致。

这里描述的是实测结果：相同文本在 4.7/4.8 上报告的输入 token 数增加约 43%，最可能的原因是 4.7 这一代更新了 tokenizer 或词表。无论根因是什么，结论都不变：迁移时必须重新测量 token 数量，因为缓存成本按 token 计算。

迁移检查清单（4.6/4.7 → 4.8）

• ✅ 缓存代码可以原样沿用。 cache_control 标记、断点数量（最多 4 个）、ttl: "1h" 和 usage 字段名都完全相同。
• ✅ TTL 选择可以沿用。 实时或会话型工作负载使用 5m，突发型或会暂停的 agent 使用 1h。
• ✅ 折扣模型可以沿用。 读取约为 89% 折扣；5m 写入约为 1.25 倍；1h 写入约为 2 倍。
• ⚠️ 重新测量 token 数量。 如果从 4.5/4.6 迁移，相同文本的输入 token 数预计会增加 40% 以上，这一变化始于 4.7。从 4.7 迁移则预计持平。
• ⚠️ 重新验证成本监控面板。 以实时响应中的 usage.cost 和 *_input_tokens 字段为准，不要使用旧版本留下的缓存估算值。

结论

对于已经在 Opus 上使用缓存的工程团队，claude-opus-4-8 属于很容易完成的升级。缓存和 TTL 接口全部保持稳定，不需要重新学习，也不需要改写代码。如果从 4.6 或更早版本迁移，需要把 tokenizer 变化纳入预算，并通过实时 usage 对象确认数据，然后即可上线。

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

常见问题

使用 Opus 4.8 时需要修改 cache_control 代码吗？ 不需要。标记语法、断点上限和 TTL 选项都与 4.7/4.6 相同。只需修改 model 字段。

4.8 的缓存读取折扣变了吗？ 没有。从 4.5 到 4.8，热缓存读取成本均约为无缓存输入价格的 11%（约 89% 折扣），与 Anthropic 文档中的费率一致。

1 小时 TTL 的溢价变了吗？ 没有。1 小时写入成本约为无缓存输入价格的 2 倍，5 分钟写入约为 1.25 倍。无论 TTL 如何，读取成本都约为 11%。这与 4.7 相同。

为什么同一份 prompt 在 4.8 上比在 4.6 上更贵？ 单 token 价格相同，只是 prompt 被计算为更多 token。实测中，相同文本在 4.5/4.6 上约为 8.0K token，在 4.7/4.8 上约为 11.4K token，增幅约为 43%。最可能的原因是 4.7 这一代更换了 tokenizer。缓存折扣没有变化。

4.8 可以直接替换 4.7 吗？ 就缓存和 TTL 接口而言，可以。token 数量和成本模型在 4.7 时已经发生变化，因此从 4.7 迁移到 4.8 基本持平。我们不会发布尚未亲自测试的能力基准。有关质量和推理能力的说明，请参阅 Anthropic 的模型卡。

验证说明：所有缓存、TTL、token 数量、成本和 TTFT 数据均于 2026-05-29 使用官方 anthropic SDK，通过 https://synthorai.io/ 在单租户环境下测得。成本和 token 数据来自单次顺序运行；TTFT 是网关预热后每个模型 5 个样本的中位数。折扣和溢价比例已与 Anthropic Prompt Caching 文档交叉核对。实际数据会随 prompt、区域和负载而变化。

← 返回博客