Bedrock Prompt Caching 1 小时 TTL 实测：Claude Code 场景下费用对比¶

Lab 信息

难度: ⭐⭐ 中级
预估时间: 90 分钟（不含边界测试等待时间）
预估费用: < $0.70（含增强测试）
Region: us-west-2
最后验证: 2026-03-27

背景¶

如果你用过 Claude Code 或其他 AI 编程助手，一定体验过这种模式：每次对话都要把系统 prompt、工具定义、代码上下文一起发过去，而这些前缀在多轮对话中几乎不变。这意味着你在为同样的内容反复付费。

Amazon Bedrock 的 Prompt Caching 可以缓存这些重复前缀，后续请求直接读取缓存，成本降低 90%。但之前只有 5 分钟 TTL — 如果你思考一个问题超过 5 分钟，缓存就过期了，又要重新写入。

2026 年 1 月，AWS 发布了 1 小时 TTL 选项，支持 Claude Sonnet 4.5、Opus 4.5 和 Haiku 4.5。本文实测对比三种策略的费用差异：无缓存、5 分钟缓存、1 小时缓存。

前置条件¶

AWS 账号，已开通 Bedrock Claude Sonnet 4.5 模型访问权限
AWS CLI v2 已配置
Python 3.8+，安装 boto3 和 requests
了解 Bedrock Converse API 基本用法

核心概念¶

Prompt Caching 工作原理¶

在你的 prompt 中标记 cache checkpoint，Bedrock 会缓存从开头到 checkpoint 之间的内容。后续请求如果前缀完全匹配，直接从缓存读取。

5 分钟 vs 1 小时 TTL¶

对比项	5 分钟 TTL（默认）	1 小时 TTL（新）
Cache Write 价格	$3.75/M tokens (Sonnet 4.5)	$6.00/M tokens (贵 60%)
Cache Read 价格	$0.30/M tokens	$0.30/M tokens（相同）
缓存持续时间	5 分钟（每次 hit 重置）	1 小时（每次 hit 重置）
适用场景	高频连续对话（< 5min 间隔）	Agentic workflow、低频长对话
支持模型	所有 Claude 模型	Sonnet 4.5, Opus 4.5, Haiku 4.5

关键定价（Claude Sonnet 4.5, us-west-2）¶

Token 类型	价格 (per 1M tokens)
普通 Input	$3.00
5m Cache Write	$3.75
1h Cache Write	$6.00
Cache Read	$0.30
Output	$15.00

核心洞察：Cache Read 比普通 Input 便宜 90%。只要缓存能命中，就是巨大的节省。

动手实践¶

场景设计：模拟 Claude Code 编程对话¶

我们构造一个典型的 Claude Code prompt 结构：

System prompt（~600 tokens）：角色定义、行为规则、安全约束
代码上下文（~1,500 tokens）：当前项目的 Python 文件
工具定义（~2,000 tokens）：15 个工具（Bash、ReadFile、WriteFile、Edit、Grep 等）
总 static prefix：~4,100 tokens

然后进行 5 轮编程对话，对比三种策略的费用。

Step 1: 准备 API 调用¶

由于 Claude Sonnet 4.5 需要使用 inference profile（不支持直接用 model ID 调 on-demand），我们先确认可用的 profile：

aws bedrock list-inference-profiles \
  --region us-west-2 \
  --query 'inferenceProfileSummaries[?contains(inferenceProfileId, `sonnet-4-5`)].inferenceProfileId' \
  --output text
# 输出: us.anthropic.claude-sonnet-4-5-20250929-v1:0

Step 2: Converse API 中使用 Cache Point¶

无缓存：直接发送 system + messages + tools，不设 cache point。

5 分钟缓存：在 system 内容末尾添加 cache checkpoint：

{
  "system": [
    {"text": "系统 prompt 内容..."},
    {"text": "代码上下文..."},
    {"cachePoint": {"type": "default", "ttl": "5m"}}
  ],
  "messages": [...]
}

1 小时缓存：只需把 ttl 改为 "1h"：

{
  "system": [
    {"text": "系统 prompt 内容..."},
    {"text": "代码上下文..."},
    {"cachePoint": {"type": "default", "ttl": "1h"}}
  ],
  "messages": [...]
}

Step 3: 执行 5 轮多轮对话¶

每组测试发送 5 轮编程对话（间隔 2 秒），模拟快速迭代编码：

"分析 CostAnalyzer 类，建议添加季节性模式检测"
"实现季节性调整，处理历史数据不足的情况"
"为季节性检测添加测试用例"
"修复跨年边界的月份分组 bug"
"添加计算结果缓存机制"

测试结果¶

主测试：5 轮快速对话费用对比¶

Group A: 无 Prompt Cache¶

Turn	Input Tokens	Cost
1	4,473	$0.0182
2	4,541	$0.0182
3	4,586	$0.0171
4	4,631	$0.0180
5	4,672	$0.0181
合计	22,903	$0.0897

Group B: 5 分钟 TTL Cache¶

Turn	Input Tokens	Cache Read	Cache Write	Cost
1	377	0	4,096	$0.0167
2	445	4,096	0	$0.0058
3	490	4,096	0	$0.0044
4	535	4,096	0	$0.0054
5	576	4,096	0	$0.0053
合计	2,423	16,384	4,096	$0.0376

Group C: 1 小时 TTL Cache¶

Turn	Input Tokens	Cache Read	Cost
1	377	4,096	$0.0060
2	445	4,096	$0.0060
3	490	4,096	$0.0045
4	535	4,096	$0.0089
5	576	4,096	$0.0056
合计	2,423	20,480	$0.0310

Group C 为何没有 Cache Write？

Group C 的第 1 轮直接命中了 Group B 写入的缓存 — Bedrock 的 prompt cache 是跨请求共享的，相同前缀的缓存无论用哪种 TTL 写入，后续请求都能读到。这证明了缓存的共享机制。

费用对比总结¶

策略	5 轮总费用	vs 无缓存节省	节省百分比
❌ 无 Cache	$0.0897	—	—
⏱️ 5min Cache	$0.0376	$0.0521	58.1%
🕐 1h Cache	$0.0310	$0.0587	65.4%

边界测试：6 分钟间隔后的真正差异¶

快速连续对话中，5min 和 1h cache 表现相近。真正的差异在间隔超过 5 分钟时：

场景	6min 后第 2 轮费用	缓存状态
5min Cache	$0.0123	❌ MISS → 重新 Write
1h Cache	$0.0026	✅ HIT → 直接读取
差异	$0.0098	1h 节省 79%

关键发现

当对话间隔超过 5 分钟时（比如你在思考、测试代码、或去倒杯咖啡），5 分钟缓存会过期。此时 1 小时 TTL 的优势就体现出来了 — 每次避免一次 cache re-write，在 ~2K 缓存 token 的场景下就能省 $0.01。

在实际 Claude Code 使用中，system prompt + tools 可能有 10-20K tokens，节省效果会更加显著。

费用模型分析：何时选择 1h TTL？¶

1h cache write 比 5m 贵 60%（$6.00 vs $3.75/M），所以不是无脑选 1h 就好。关键在于：1h write 的额外成本能否被避免的 re-write 抵消？

假设 static prefix 为 N tokens：

5m write 成本：N × $3.75/M
1h write 成本：N × $6.00/M
额外成本 Δ：N × $2.25/M
每次避免 re-write 节省：N × ($3.75 - $0.30)/M = N × $3.45/M

Break-even：只需 1 次 cache hit 在 5-60min 间隔内发生，1h TTL 就比 5m TTL 划算（因为 $3.45 > $2.25）。

Static Prefix	1h Write 额外成本	避免 1 次 Re-write 节省	结论
5K tokens	$0.01125	$0.01725	✅ 1 次就回本
10K tokens	$0.02250	$0.03450	✅ 1 次就回本
20K tokens	$0.04500	$0.06900	✅ 1 次就回本

增强测试：1 小时持续编码场景¶

上面的快速测试只有 5 轮 + 1 次边界测试。真实的编程 session 是什么样的？一个开发者可能花 1 小时写代码、review、调试、写测试 — 中间有密集编码，也有思考间隙。

我们设计了一个 19 轮、69 分钟 的完整开发 session，三组同步对比：

A 组：无缓存 — 每次请求全量发送，不设 cache point
B 组：5min TTL — 系统前缀设 5 分钟缓存（默认）
C 组：1h TTL — 系统前缀设 1 小时缓存（新功能）

模拟真实工作节奏：

Phase	时间段	轮次	间隔	模拟场景
Phase 1 编码	0-17min	9 轮	1.5-2.5min	密集编码：写 REST API + 数据层
Phase 2 Review	22-35min	3 轮	5-7min	Code Review + 重构（间隔 > 5min）
Phase 3 Agent	41-61min	3 轮	6-8min	工具调用：搜索 → 分析 → 文档生成
Phase 4 收尾	64-69min	4 轮	1.5min	写测试 + Docker + 收尾

逐轮详细数据¶

Phase 1：密集编码（Turn 1-9，间隔 1.5-2.5min）¶

Turn	时间	间隔	任务	A 费用	B 费用	B 状态	C 费用	C 状态
1	0min	—	设计 API 结构	$0.0100	$0.0119	WRITE	$0.0176	WRITE
2	1.6min	1.5min	实现 POST /costs	$0.0104	$0.0034	HIT	$0.0035	HIT
3	3.3min	1.5min	实现 GET /costs	$0.0102	$0.0033	HIT	$0.0033	HIT
4	5.4min	2.0min	数据访问层	$0.0101	$0.0036	HIT	$0.0032	HIT
5	7.5min	2.0min	GET /reports	$0.0105	$0.0039	HIT	$0.0036	HIT
6	9.6min	2.0min	输入验证	$0.0107	$0.0038	HIT	$0.0039	HIT
7	12.3min	2.5min	GET /alerts	$0.0108	$0.0040	HIT	$0.0040	HIT
8	14.4min	2.0min	错误处理	$0.0109	$0.0042	HIT	$0.0040	HIT
9	17.0min	2.5min	限流 + 日志	$0.0111	$0.0043	HIT	$0.0043	HIT

Phase 1 小结

密集编码阶段，间隔 < 5min，5min 和 1h 缓存都能持续命中。B 组因 write 更便宜（$3.75 vs $6.00/M），Phase 1 总费用反而低于 C 组。快速连续对话中 5min TTL 更划算。

Phase 2：Code Review（Turn 10-12，间隔 5-7min）¶

Turn	时间	间隔	任务	A 费用	B 费用	B 状态	C 费用	C 状态
10	22.2min	5.0min	全面 Review	$0.0126	$0.0057	HIT	$0.0063	HIT
11	28.3min	6.0min	重构数据层	$0.0116	$0.0135	❌ WRITE	$0.0047	✅ HIT
12	35.3min	7.0min	边界检查	$0.0115	$0.0046	HIT	$0.0047	HIT

关键时刻：Turn 11（间隔 6 分钟）

5min cache 首次过期！B 组被迫重新 Write（$0.0135），而 C 组 1h cache 轻松命中（$0.0047）。这一轮 C 组费用仅为 B 组的 35%。

Phase 3：Agent 工具调用（Turn 13-15，间隔 6-8min）¶

Turn	时间	间隔	任务	A 费用	B 费用	B 状态	C 费用	C 状态
13	41.5min	6.0min	搜索最佳实践	$0.0120	$0.0051	HIT	$0.0051	HIT
14	51.6min	8.0min	实现分页	$0.0119	$0.0138	❌ WRITE	$0.0051	✅ HIT
15	60.7min	7.0min	生成 API 文档	$0.0120	$0.0140	❌ WRITE	$0.0052	✅ HIT

5min cache 连续崩溃

Phase 3 间隔全部 > 5min。B 组在 Turn 14 和 15 连续两次 cache miss → re-write，每次 $0.014。而 C 组 1h cache 全程命中，每轮仅 $0.005。Phase 3 中 C 组费用不到 B 组的一半。

Phase 4：收尾（Turn 16-19，间隔 1.5min）¶

Turn	时间	间隔	任务	A 费用	B 费用	B 状态	C 费用	C 状态
16	64.4min	1.5min	单元测试	$0.0112	$0.0054	HIT	$0.0054	HIT
17	66.0min	1.5min	集成测试	$0.0157	$0.0055	HIT	$0.0045	HIT
18	67.7min	1.5min	Dockerfile	$0.0132	$0.0046	HIT	$0.0064	HIT
19	69.3min	1.5min	类型标注收尾	$0.0155	$0.0086	HIT	$0.0071	HIT

分 Phase 费用汇总¶

Phase	场景	A 无缓存	B 5min	C 1h	B vs A	C vs A	C vs B
1 编码	9 轮 1.5-2.5min	$0.0946	$0.0423	$0.0473	-55.3%	-50.0%	B 更优
2 Review	3 轮 5-7min	$0.0357	$0.0238	$0.0157	-33.3%	-56.0%	C 胜出
3 Agent	3 轮 6-8min	$0.0359	$0.0329	$0.0154	-8.4%	-57.1%	C 大胜
4 收尾	4 轮 1.5min	$0.0556	$0.0241	$0.0233	-56.7%	-58.1%	接近
合计	19 轮 69min	$0.2219	$0.1231	$0.1017	-44.5%	-54.2%	-17.4%

Cache 命中统计¶

指标	B 组 5min	C 组 1h
Cache Write 次数	4 次	1 次
Cache Hit 次数	15 次	18 次
Hit 率	78.9%	94.7%
因过期导致的 Re-write	3 次（Turn 11/14/15）	0 次

累计费用趋势¶

费用($)
0.22 ┤                                              ╭── A 无缓存 $0.222
0.20 ┤                                           ╭──╯
0.18 ┤                                      ╭────╯
0.16 ┤                                 ╭────╯
0.14 ┤                            ╭────╯
0.12 ┤                      ╭─────╯           ╭──── B 5min $0.123
0.10 ┤                 ╭────╯           ╭─────╯
0.08 ┤            ╭────╯          ╭─────╯     ╭──── C 1h $0.102
0.06 ┤       ╭────╯          ╭────╯     ╭─────╯
0.04 ┤  ╭────╯          ╭────╯    ╭─────╯
0.02 ┤──╯          ╭────╯    ╭────╯
0.00 ┤─────────────╯────╯────╯
     └──┬────┬────┬────┬────┬────┬────┬────┬
        0   10   20   30   40   50   60   70 分钟
              Phase1  │ Phase2│ Phase3│Phase4
                      │       │       │
                 Turn 11   Turn 14  Turn 15
                B re-write  B re-write×2
                C still HIT C still HIT

核心结论

在 69 分钟的真实开发 session 中：

1h TTL 比无缓存节省 54.2%（$0.222 → $0.102）
1h TTL 比 5min TTL 再省 17.4%（$0.123 → $0.102）
5min cache 因 3 次过期 re-write 多花了 $0.021
越是有思考间隙的工作模式，1h TTL 优势越大

按比例推算：一个开发者每天 8 小时使用 Claude Code（~20K token static prefix），1h TTL 相比 5min 每天可额外节省约 $2-5，每月 $40-100。

踩坑记录¶

Model ID vs Inference Profile

Claude Sonnet 4.5 不能直接用 model ID（anthropic.claude-sonnet-4-5-20250929-v1:0）调用 on-demand inference，必须使用 inference profile ID（us.anthropic.claude-sonnet-4-5-20250929-v1:0）。否则会报 ValidationException: Invocation with on-demand throughput isn't supported。

已查文档确认：这是 Bedrock 对较新模型的设计，需要通过 inference profile 路由。

boto3 TTL 字段支持

截至 boto3 1.40.61，CachePointBlock shape 只包含 type 字段，不支持 ttl。调用时会触发参数验证错误：Unknown parameter in cachePoint: "ttl"。

解决方案：使用 raw HTTP 请求 + SigV4 签名直接调用 Converse API endpoint（/model/{modelId}/converse），绕过 boto3 参数验证。

实测发现，官方未记录：预计后续 boto3 版本会添加 TTL 支持。

Cache 跨请求共享

不同 TTL 的请求共享同一前缀缓存。如果用 5m TTL 写入了缓存，后续用 1h TTL 的请求可以直接读取该缓存。

实测发现：这意味着在混合使用场景中，缓存行为可能与预期不同。

费用明细¶

测试项	请求数	费用
T1: Group A 无缓存 (5轮)	5	$0.0897
T2: Group B 5min缓存 (5轮)	5	$0.0376
T3: Group C 1h缓存 (5轮)	5	$0.0310
T4a: 1h 冷启动 (2轮)	2	$0.0144
T4b: 5min 超时测试 (2轮)	2	$0.0219
T5: 1h 存活测试 (2轮)	2	$0.0153
T6: 增强测试 Group A 无缓存 (19轮/69min)	19	$0.2219
T7: 增强测试 Group B 5min (19轮/69min)	19	$0.1231
T8: 增强测试 Group C 1h (19轮/69min)	19	$0.1017
合计	78	< $0.66

清理资源¶

本 Lab 仅使用 Bedrock API 调用，无需创建或清理任何 AWS 资源。

结论与建议¶

三种策略选择指南¶

场景	推荐策略	理由
高频连续对话（< 5min 间隔）	5min TTL	Write 更便宜，hit 率高
Agentic workflow（工具执行 > 5min）	1h TTL	避免中间步骤导致 cache 过期
交互式编码（间歇性暂停）	1h TTL	思考、测试、调试间隔常 > 5min
Batch processing	1h TTL	跨批次保持缓存
预算极敏感、连续使用	5min TTL	Write 成本更低

Claude Code 场景建议¶

对于典型的 Claude Code 使用模式：

System prompt + Tools 使用 1h TTL — 这部分最大（10-20K tokens）且完全不变，用 1h 缓存可以避免思考间隙导致的 re-write
对话历史可以用 5m TTL — 变化频繁，5min 通常够用
混合使用时 1h 必须在前 — Bedrock 要求长 TTL 的 cache entry 出现在短 TTL 之前

总结¶

Prompt Caching 1h TTL 是 Bedrock 为 真实 AI 编程工作流 量身定制的优化。在 Claude Code 场景中，它可以：

快速对话中节省 58-65% 的输入费用
在对话间隔 > 5min 时额外节省 79%（vs 5min cache miss）
只需 1 次 5-60min 间隔的 cache hit 就能回本 1h write 的额外成本