Claude Code 中转必看：Prompt Cache 透传原理与省钱验证方法

用 Claude Code 写代码，最烧钱的从来不是你输入的那几行指令，而是每一轮对话都要重新塞进去的一大坨上下文：系统提示词、项目文件、工具定义、历史消息……动辄几万甚至几十万 token。这些内容在一次会话里几乎不变，却被反复计费。Prompt Cache（提示词缓存）就是专门用来解决这个问题的机制，它是决定一个 Claude Code 中转平台到底省不省钱的核心门槛。

这篇文章把 Prompt Cache 的原理、为什么很多逆向接口做不到、KingFlow 如何透传，以及你自己怎么用一条 cURL 命令验证缓存是否真的生效，一次讲透。

一、什么是 Prompt Cache，为什么它能砍 50%-90% 成本

Prompt Cache 是 Anthropic 官方在 /v1/messages 接口上提供的能力。原理并不神秘：

你在请求里用 cache_control 标记某一段内容（比如超长的系统提示词、整个代码文件），告诉服务端"这段请稍作缓存"。
服务端对被标记的内容做哈希，把处理后的中间结果（KV cache）在短时间内（默认 5 分钟，可续期）保留下来。
下一次请求如果前缀内容完全一致、哈希对得上，服务端直接复用缓存，不再重新计算这部分 token。

关键在计费差异：命中缓存的输入 token（cache_read_input_tokens）价格通常只有普通输入 token 的约十分之一。而 Claude Code 的工作模式恰恰是"同一批上下文反复对话"——系统提示词固定、项目文件不变、只在末尾追加新指令。这种场景缓存命中率极高，所以官方给出的"砍 50%-90% 成本"在实际编码工作流里完全能兑现。

一句话：Prompt Cache 是 Claude Code 省钱的第一杠杆，没有它，你在为同样的上下文一遍遍全价付费。

二、为什么逆向接口（Cursor/Kiro 类）不支持 Cache

市面上不少便宜的"中转"，本质是逆向了某些客户端（例如 Cursor、Kiro 这类产品）的私有接口，再把流量伪装转发出去。这类方案有个绕不过去的死穴：它们走的不是官方 /v1/messages，拿不到、也不敢透传原生的 cache_control。

更深一层的技术原因在于哈希一致性。Prompt Cache 命中的前提是：服务端收到的 system、messages、cache_control 这几个字段，与上一次请求在字节级别上前缀完全一致，哈希才能对上。而逆向接口为了适配自己私有的协议格式，往往要做这些动作：

把你的 system 拆开、重新拼装成它自己的模板
把 messages 数组解析后重组、增删字段、改写顺序
直接丢弃或篡改 cache_control 标记

任何一处解析重组，都会让请求体的字节序列发生变化，哈希随之改变，缓存永远命中不了。哪怕它嘴上说"支持缓存"，实际每次都是全价重算。这就是为什么逆向接口平台看单价好像便宜，用起来账单却居高不下。

三、透传 vs 重组：一张表看懂差距

维度	官方 /v1/messages 透传（KingFlow）	逆向接口重组（Cursor/Kiro 类）
接口协议	官方原生 `/v1/messages`	逆向的私有客户端接口
request body 处理	原样透明转发，不解析重组	解析 system/messages 后重拼
cache_control	完整透传	丢弃或篡改
哈希一致性	前缀字节一致，可命中	每次变化，永不命中
cache_read_input_tokens	第二次请求非零	恒为 0
实际成本	Cache 砍 50%-90%	比透传贵 3-5 倍
稳定性	跟随官方，不怕客户端改版	客户端一改版就挂

四、KingFlow 如何透传 cache_control

KingFlow 的做法很朴素，也正因为朴素才可靠：做一个透明网关，对 Claude Code 发出的原始 request body 原样转发到官方 /v1/messages，不解析、不重组、不改写 system / messages / cache_control。 你的字节进来什么样，出去还是什么样，前缀哈希自然与上一次一致，缓存该命中就命中。

配置也只需要在 ~/.claude/settings.json 里填这么一段：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://www.kingflow.ai",
    "ANTHROPIC_AUTH_TOKEN": "在 KingFlow 控制台领取的 API Key",
    "API_TIMEOUT_MS": "3000000",
    "CLAUDE_CODE_ATTRIBUTION_HEADER": "0"
  },
  "effortLevel": "medium"
}

几个和缓存直接相关的细节：

ANTHROPIC_BASE_URL 只写根域 https://www.kingflow.ai，不带 /v1，Claude Code 自己会拼 /v1/messages。
CLAUDE_CODE_ATTRIBUTION_HEADER 设为 "0"，关掉署名头。这会让请求前缀更稳定，提升 Prompt Cache 命中率。
effortLevel 设 "medium"，省 20-30% 推理 token，遇到硬题临时调 high。
API_TIMEOUT_MS 给到 300 万毫秒，防止长任务被中途掐断。

五、动手验证：两次请求看 cache_read_input_tokens 是否非零

别信任何平台的口头承诺，自己发两次请求验一次就知道。原理是：第一次请求带 cache_control 会产生 cache_creation_input_tokens（写缓存），第二次同样内容再发一次，如果透传正常，返回的 usage.cache_read_input_tokens 会变成非零（读缓存命中）。

把下面这段 cURL 里的内容跑两遍，注意 system 那段要够长（官方对可缓存内容有最小 token 数要求，太短不会缓存），这里用重复文本凑长度演示：

curl https://www.kingflow.ai/v1/messages \
  -H "x-api-key: $KINGFLOW_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 64,
    "system": [
      {
        "type": "text",
        "text": "你是一个资深工程师。以下是需要长期缓存的项目规范（此处放足够长的重复内容以超过最小缓存 token 阈值）……重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复重复……",
        "cache_control": {"type": "ephemeral"}
      }
    ],
    "messages": [
      {"role": "user", "content": "用一句话说你收到了规范。"}
    ]
  }'

观察返回体里的 usage 字段：

// 第一次（写缓存）
"usage": {
  "input_tokens": 12,
  "cache_creation_input_tokens": 1180,
  "cache_read_input_tokens": 0
}

// 第二次（命中缓存）
"usage": {
  "input_tokens": 12,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 1180
}

第二次 cache_read_input_tokens 非零，就说明 cache_control 被完整透传、缓存真实生效。如果两次都恒为 0，那这个平台基本可以判定为逆向重组、根本没在透传缓存——直接换掉。

六、不支持 Cache 的平台实际贵 3-5 倍

把账算清楚就明白差距了。假设一段 5 万 token 的项目上下文，在一次会话里被复用 20 轮：

支持 Cache（透传）：第一轮写缓存全价，后面 19 轮走 cache_read，每轮只花约十分之一的输入成本。整段上下文的输入费用被摊薄到接近零头。
不支持 Cache（重组）：20 轮全部全价重算，5 万 token × 20 轮全额计费。

上下文越大、对话轮次越多，差距越夸张。综合真实编码工作流，不支持 Cache 的平台实际贵 3-5 倍是常态。所以选中转平台时，单价高低是障眼法，能不能透传 Prompt Cache 才是真正决定账单的变量。KingFlow 在此基础上还叠加了内部优化汇率，具体价格以官网 www.kingflow.ai 为准。

七、FAQ

Q1：Prompt Cache 会存多久？会不会一直计费？ 默认缓存约 5 分钟，期间有新请求命中会自动续期，超时自动失效。你只在"写入"那一次付缓存创建费，之后命中都是更便宜的读取费，不会持续扣钱。

Q2：为什么我第二次请求 cache_read 还是 0？ 最常见原因：被缓存内容太短没达到最小 token 阈值；或者两次请求前缀不完全一致（比如中间插了变化的字段）。先把 system 内容加长、保证两次前缀字节一致再测。如果内容够长且一致仍为 0，那多半是平台没透传。

Q3：KingFlow 会改我的 request body 吗？ 不会。KingFlow 是透明网关，原样转发原始 body 到官方 /v1/messages，不解析、不重组 system / messages / cache_control，这正是缓存能命中的前提。

Q4：关掉 CLAUDE_CODE_ATTRIBUTION_HEADER 真的能提命中率？ 能。署名头会给请求前缀引入额外变化，关掉后前缀更稳定，缓存哈希更容易对上，命中率更高。设 "0" 即可。

Q5：除了 Claude，国产模型也能通过 KingFlow 走吗？ 可以。KingFlow 同时接入 DeepSeek、智谱 GLM、通义 Qwen、Kimi 等主流国产家族，用 /model 命令切换。简单任务交给国产轻量模型、复杂任务交给 Claude，配合 Prompt Cache，整体成本还能再降一档。

官网：https://www.kingflow.ai ｜更多教程：https://yemaochuanmei.github.io/