在 Claude Code 里泡了一上午的 AI 程序员一定有这样的切肤之痛：你敲完需求，Claude 洋洋洒洒开始输出，代码写了上百行，你认真 review 了五分钟，确认合并，继续提下一个需求——结果后端账单显示，这一轮又走了一次 full-price input token。明明上下文几乎没变，但就是没命中缓存。
这背后的罪魁祸首，正是 Anthropic 的 Prompt Cache TTL（存活时间），以及 Claude Code 与 OpenRouter 之间一个微妙的兼容性缝隙。本文将为你拆解整个成本模型，并分享一个我用 vibe coding 写的小工具 claude-openrouter-proxy，将缓存有效时间从短短 5 分钟延长到整整 1 小时，成本差距接近 10 倍。
问题溯源：缓存时效被锁死在 5 分钟
5 分钟与 1 小时之间，隔着什么？
Anthropic 的 Prompt 缓存支持两个 TTL 级别——5 分钟和1 小时，但 Claude Code 客户端本身不允许用户手动调整。TTL 由你的订阅计划决定：Pro 订阅和 API Key 用户默认获得 5 分钟 TTL，只有更贵的 Max 订阅才能享受 1 小时缓存。更致命的是，如果你为隐私起见设置了 DISABLE_TELEMETRY=1，缓存 TTL 会静默退回到 5 分钟。这是一条铁律，没有任何官方配置项可以绕过。
两档 TTL 的成本结构差异显著：5 分钟缓存写入成本为基准输入价格的 1.25 倍，1 小时缓存写入成本为 2 倍，但缓存命中后的读取成本仅为基准的 10%（约 0.1 倍）。换句话说，一次缓存命中省下的钱最多可以达到 10 倍——写缓存的额外开销几乎可以忽略不计，cache miss 才是真正的烧钱黑洞。
为什么 5 分钟完全不够用？
Claude Code 的实际工作节奏与 5 分钟 TTL 之间存在严重错配。每次你提出需求后，Claude 的思考时间加上输出时间往往要 1-2 分钟。等它写完代码，你还需要认真 review 结果，这一轮 review 轻松耗掉 2-3 分钟。在你确认效果、准备提下一个需求时，TTL 计时已经过去了 4-5 分钟——就在你即将发送下一条消息的瞬间，缓存恰好过期。然后新的请求再次触发昂贵的 cache creation，而这次写好的缓存很大概率在下一个“等待输出+review”的周期中又会安然过期，形成了“次次写入、从不命中”的恶性循环。也就是说，你几乎一直在为写缓存支付溢价，却从来没有享受过读缓存的折扣。
这正是大多数重度用户的典型使用模式：非连续的高强度请求，中间夹杂着阅读和思考的间歇。在这种模式下，5 分钟 TTL 不但不省钱，反而因为频繁的 cache creation 使你的总 token 消耗不降反升。正因如此，争取 1 小时 TTL 带来的真实账单差距，可以达到接近 10 倍的程度。
OpenRouter 的特殊性：它不是 Anthropic，不会替你兜底
OpenRouter 作为中间代理，对 Anthropic 模型的 Prompt 缓存有自己的一套处理方式。OpenRouter 支持 5 分钟和 1 小时两档 TTL 设置，但 Claude Code 发出的请求中原本的 cache_control 标记并不能直接被 OpenRouter 正确理解和使用。
这里的核心矛盾在于：Claude Code 客户端本身无法修改 TTL，而 OpenRouter 又无法自动识别客户端发来的缓存意图。两头都不接管，结果就是你的请求虽然走 OpenAI-compatible 协议成功发出了，但缓存从未被正确启用——所有 input token 都按全价计费，无论你在同一个 session 里发了多少条类似的消息。
解决方案：claude-openrouter-proxy
我的工具箱里多了个本地代理
为了解决这个问题，我用 vibe coding 写了一个本地代理工具，托管在 GitHub 上：
👉 https://github.com/helloJamest/claude-openrouter-proxy
它本质上只是一个本地 HTTP 代理（基于 Node.js），核心逻辑非常轻量——在请求转发到 OpenRouter 前做三件事：
去掉顶层 cache_control：因为 Claude Code 生成的标记格式与 OpenRouter 的预期不兼容，保留它只会产生干扰；
移除 provider.order：确保请求被路由到同一 Provider，保持 sticky routing，避免因为换节点导致缓存失效；
在稳定的 Prompt 前缀上注入一条 cache_control: {"type": "ephemeral", "ttl": "1h"}：直接指定缓存类型为“ephemeral”（上下文缓存），TTL 为 1 小时。
正是这个第三步，在请求的最前面（通常是系统提示、工具定义、CLAUDE.md 等稳定的前缀位置）打入了一个清晰的 1 小时缓存标记，让 OpenRouter 能够正确启用 1 小时 TTL，而非继续沿用默认的 5 分钟。所有其他内容毫发无伤，对 Claude Code 的功能没有任何副作用。
如何安装和使用？
工具使用极其简单，已在 macOS、Linux 和 Windows（Git Bash/MSYS2/Cygwin）上提供了安装脚本：
# 1. 克隆仓库
git clone https://github.com/helloJamest/claude-openrouter-proxy.git
cd claude-openrouter-proxy# 2. 配置环境变量
cp .env.example .env
# 编辑 .env，填入你的 OPENROUTER_API_KEY
# 可选：修改 PROXY_PORT（默认 3456）# 3. 一键安装为系统服务（开机自启）
./install.sh
安装脚本会自动注册系统服务：macOS 上注册为 LaunchAgent，Linux 上注册为 systemd 用户服务，Windows 上创建计划任务——都实现了开机自启。卸载同样简单，执行 ./uninstall.sh 即可。
然后，将 Claude Code 的 API 端点配置指向本地代理：
如果你的 Claude Code 期望标准 Anthropic 格式：http://127.0.0.1:3456
如果明确要求指定 messages 路径：http://127.0.0.1:3456/v1/messages
代理会接收任意 POST 路径，并转发到 OpenRouter 的 Anthropic 兼容端点。
效果验证
建议在启用代理前后对比一下你的 OpenRouter Dashboard 中的缓存命中率。如果你的使用模式是典型的“等待输出→review→再提需求”循环，启用 1 小时 TTL 后，缓存命中率应该有显著提升，input token 成本也会随之大幅下降。具体可以使用 OpenRouter 自带的 Activity 面板观测 cache_read_input_tokens 和 cache_write_input_tokens 的比例变化。
一些额外的省钱要点
为了让你对整个成本结构有一个完整的理解，这里给出 Claude Opus 4.1 在 OpenRouter 上的当前 API 定价速览（实际价格可能浮动）：
基准 Input Token 价格：$7.50/1M tokens（Amazon Bedrock Provider）
基准 Output Token 价格：$75.00/1M tokens
Cache Write 5 分钟 TTL：基准 Input 的 1.25 倍（约 $18.75/1M tokens）
Cache Write 1 小时 TTL：基准 Input 的 2 倍
Cache Read（缓存命中）：基准 Input 的 10%（约 $1.50/1M tokens）
缓存命中时的读取成本仅为正常输入价格的 10%，与 cache miss 的正常输入价格相比，差距刚好是 10 倍。这也是为什么“TTL 够不够长”不是一个微调问题，而是一个成本结构问题。
为什么写缓存价格更高？
这是 Prompt 缓存机制的核心权衡。Prompt 缓存的秘密在于：它并不是简单地存储 prompt 文本，而是将 Transformer 的 KV Cache（注意力计算的中间状态）保存在 GPU 内存中。每次请求如果命中缓存，服务端就可以直接复用这些已计算好的注意力矩阵，省掉重复的 prefill 计算——这也是为什么缓存不仅能省钱（只需 10% 的 input 价格），还能大幅降低延迟（页面交互感觉更快）。
但维护缓存需要占用 GPU 的 HBM 显存，对于云服务商而言，这是一项实际的硬件成本。因此写缓存的费用包含两部分：基准的 input 计算费用 + 额外的存储溢价。溢价的高低反映了存储时间的差异——5 分钟缓存意味着较短的内存占用，商家的存储溢价较低（25% 溢价）；而 1 小时缓存意味着长时间锁定 GPU 内存，溢价自然更高（100% 溢价）。将 TTL 从 5 分钟提升到 1 小时，本质上是在为更长的存储时间支付更高的写入溢价，以换取后续请求更频繁的读取折扣。
对于 Claude Code 这种需要频繁重温上下文的 Agent 使用模式，1 小时 TTL 的总成本远低于 5 分钟 TTL。原因很简单：你付出了 2 倍的写入成本，但之后一小时内所有重用的上下文都只花 0.1 倍的读取价格——只要你的 session 持续超过 5 分钟（而这对 Claude Code 来说几乎是必然的），Cache Read Token 的占比就会压倒 Cache Write，带来显著的净节省。
如果你正在使用 OpenRouter 调用 Claude Code，强烈建议检查一下当前请求链路上 prompt caching 是否真的在工作。这个问题的隐蔽性在于，它不会报错，不会警告，只会默默地从你的 API 余额里多抽走一大笔。
有了 claude-openrouter-proxy 之后，你可以安心地 review Claude 的输出，不必担心就因为多看了一两分钟代码，等来下一次请求时的 cache miss。对于重度 Claude Code 用户来说，这项优化带来的成本节约，可能是你在 LLM 开发中最具性价比的技术投入。
GitHub 项目地址：helloJamest/claude-openrouter-proxy ⭐ 欢迎 Star & 提 Issue！