Opus 4.6 的能力很强，价格也不低——25 每百万输入/输出 token。如果你的应用调用量大，账单会很可观。
好消息是 Anthropic 提供了两个官方降本工具：Prompt Caching 和 Batch API。单用都能省不少，组合用效果更好。
这篇把两个工具的机制、组合方式、适用场景捋一遍。
Prompt Caching：重复前缀打一折
每次请求 Claude 时，system prompt、RAG 文档、对话历史这些内容大部分是重复的。Prompt Caching 把这些重复部分缓存起来，下次遇到相同前缀直接复用。
Opus 4.6 的缓存价格：
| 操作 | 价格 |
|---|---|
| 正常输入 | $5.00/MTok |
| 缓存写入（5分钟） | $6.25/MTok |
| 缓存写入（1小时） | $10.00/MTok |
| 缓存命中 | $0.50/MTok |
缓存命中时，输入价格从 0.50——打了一折。代价是第一次写入缓存时多付 25%（5 分钟缓存）或 100%（1 小时缓存）。
关键条件：后续请求的前缀必须跟缓存内容完全一致。改了一个字符，缓存就失效。
怎么标记缓存
Anthropic 的缓存是手动标记的——你在请求里用 cache_control 指定哪些内容需要缓存：
response = client.messages.create(
model="claude-opus-4-6",
max_tokens=4096,
system=[{
"type": "text",
"text": "你是一个代码审查助手。以下是项目编码规范...(2000 tokens)",
"cache_control": {"type": "ephemeral"}
}],
messages=[{"role": "user", "content": "审查这段代码..."}]
)
最多 4 个缓存断点。5 分钟的 TTL，每次命中会刷新。如果 5 分钟内没有新请求，缓存过期，下次要重新写入。
适合缓存的内容
按优先级排：
- System prompt（几乎不变，缓存命中率最高）
- RAG 文档 / 知识库内容（同一会话内不变）
- 对话历史的前几轮（已经发生的不会改）
- 工具定义（tools 参数，通常固定）
不适合缓存的：用户的当前输入、动态生成的内容。
Batch API：非实时任务打五折
Batch API 让你把一批请求打包提交，异步处理。没有实时性要求，所以 Anthropic 给了 50% 的折扣。
Opus 4.6 的 Batch 价格：
| 项目 | 标准价 | Batch 价 |
|---|---|---|
| 输入 | $5.00/MTok | $2.50/MTok |
| 输出 | $25.00/MTok | $12.50/MTok |
用法是把多个请求写成一个 JSONL 文件提交：
batch = client.batches.create(
requests=[
{
"custom_id": "task-001",
"params": {
"model": "claude-opus-4-6",
"max_tokens": 4096,
"messages": [{"role": "user", "content": "分析文档 A..."}]
}
},
{
"custom_id": "task-002",
"params": {
"model": "claude-opus-4-6",
"max_tokens": 4096,
"messages": [{"role": "user", "content": "分析文档 B..."}]
}
}
]
)
提交后轮询状态，全部完成后拉取结果。处理时间没有 SLA 保证，通常几分钟到几小时。
适合 Batch 的场景
- 批量文档分析 / 摘要
- 批量代码审查
- 数据标注 / 分类
- 批量翻译
- 定期报告生成
不适合：实时对话、需要立即返回结果的 Agent、用户在等待的交互式场景。
组合使用：缓存 + Batch
两者可以叠加。在 Batch 请求里同样可以使用 Prompt Caching。
叠加后的价格：
| 操作 | 标准价 | 缓存命中 | Batch | Batch + 缓存命中 |
|---|---|---|---|---|
| 输入 | $5.00 | $0.50 | $2.50 | $0.25 |
| 输出 | $25.00 | — | $12.50 | $12.50 |
输入 token 从 0.25——打了两折。
一个实际例子：你有 500 份合同，每份需要 Opus 4.6 做风险分析。每份合同平均 8K token，system prompt + 分析框架约 3K token。
不做任何优化：
- 500 次请求 × (11K 输入 + 3K 输出) = 5.5M 输入 + 1.5M 输出
- 成本：5.5 × 25 = 37.50 = $65.00
只用 Batch：
- 成本：5.5 × 12.50 = 18.75 = $32.50（省 50%）
Batch + Caching（3K 的 system prompt 被缓存，命中率 95%）：
- 缓存命中部分：3K × 500 × 0.95 = 1.425M token @ 0.36
- 未命中部分：3K × 500 × 0.05 = 0.075M token @ 0.19
- 缓存写入（首次）：3K × 1 × 0.01
- 非缓存输入：8K × 500 = 4M @ 10.00
- 输出：1.5M × 18.75
- 总成本：约 $29.31（省 55%）
缓存在 Batch 场景下的增量收益不如单独用时大——因为 Batch 已经把输入价打了五折，缓存再打折的基数变小了。但几千美元的量级下，每多省 5% 也是真金白银。
高频实时场景：Caching 是主力
如果你的场景是高频实时调用（比如客服 bot，每秒几个请求），Batch 用不了。这时候 Caching 是唯一的降本手段。
优化重点：
1. 前缀排列很重要。 不变的放前面，变化的放后面。System prompt → RAG 文档 → 对话历史 → 用户输入。这个顺序让缓存匹配到最长的前缀。
2. 不要在 System Prompt 里放动态内容。 常见错误：在 system prompt 开头加"当前时间：2026-02-06 14:30:22"。每秒都变，缓存全废。把时间信息放到用户消息里，或者精度降到小时级别。
3. RAG 文档排序要固定。 如果你的 RAG 每次返回 5 篇文档但顺序不同，缓存命不中。给文档按 ID 排个序再塞进去。
4. 监控缓存命中率。 响应里的 cache_read_input_tokens 和 cache_creation_input_tokens 能告诉你缓存效果。如果 cache_creation 远多于 cache_read，说明缓存一直在过期重建——要么请求间隔太长，要么前缀在变。
长上下文溢价下的组合策略
如果你用了 1M 上下文（输入超过 200K），所有价格翻倍：
| 操作 | >200K 标准 | >200K 缓存命中 | >200K Batch | >200K Batch+缓存 |
|---|---|---|---|---|
| 输入 | $10.00 | $1.00 | $5.00 | $0.50 |
即使在长上下文溢价下，Batch + Caching 也能把输入价格从 0.50。如果你一定要用长上下文，这两个工具必须同时开。
总结一下优先级
- 缓存永远开。几乎没有不开的理由（除非你的请求完全没有重复前缀）
- Batch 在非实时场景下开。有 50% 的确定性收益
- 两者组合在大批量任务里用。输入成本可以降到标准价的 5%
- 长上下文场景下，这两个工具从"省钱的好处"变成"必须有的成本控制"
