Anthropic prompt cache：25% 的写入溢价什么时候能赚回来

Anthropic 的 prompt cache 是那种营销页写"省 90%"、真付过账单的人都说"看情况"的功能。这篇是 Excel 版本：25% 的写入溢价什么时候能赚回来、什么时候会让你亏钱、跑 agent 那种每几秒就重写一次缓存的工作流时该怎么办。

你实际付的是三种价

Anthropic 根据每个输入 token 的命运按三种不同费率收费：

所以"省 90%"是真的——指读取价。但每次读取的前提是先有写入，而每次写入都比无缓存基线贵。问题是：要读多少次，写入才赚得回来？

收支平衡公式

设一个可缓存的块是 T 个输入 token。按 Anthropic 基础费率 p 每百万 token，N 次调用的成本对比：

不开缓存：    N * T * p
开缓存：      1.25 * T * p   （一次性写入）
            + (N - 1) * T * 0.1 * p   （后续读取）

平衡点：      N * p = 1.25*p + (N-1) * 0.1*p
             N = 1.25 + 0.1*(N-1)
             0.9N = 1.15
             N ≈ 1.28

必须在 5 分钟窗口内至少读 2 次，缓存才划算。读 1 次净亏（你付了 1.25x，只省了 0.9x）。读 2 次刚好持平。读 3 次以上才看得到惊人的省钱效果。

什么场景缓存稳赚

三种模式能稳定产出每次写入 5+ 次读取：

1. 长 system prompt。4000 token 的 system prompt 在整个对话 session 里共享。每个用户消息读一次缓存。哪怕只有 5 轮对话也能省 70% 左右。
2. 文档问答。上传 20K token 的文档，几分钟内问 10 个相关问题。第 1 个问题写缓存，2~10 个问题读缓存。比不开缓存省 85% 左右。
3. Agent 内循环。agent 每步都重发同一套 tool 定义 + system prompt，这些都可缓存。通常每次写入对应几百次读取。

什么场景缓存让你亏钱

三种要小心的模式：

1. 一次性调用。同一个 prompt 你只调一次，标 cache_control 就是白付 1.25x。不打算复用就别标。
2. 慢 agent。多步 agent 在 LLM 调用之间夹着长时间的 tool 执行。如果某个 tool 跑了 6 分钟，缓存已经过期，你刚为这一次读付了写入溢价。
3. 自我击溃的 prompt。把当前时间戳、请求 UUID、或任何 per-call 变化的东西放进 prompt，会让缓存失效。我们见过生产代码把 new Date() 拼进 system prompt，每次都付 1.25x，跑了好几年。

谁来承担这 25% 的写入溢价？

这里是 AI 网关要做真金白银决策的地方。

选项 A：原样透传。网关按 Anthropic 一样的费率收用户——写 1.25x、读 0.1x。诚实，但引入波动——某个用户恰好错过缓存窗口就要多付钱，然后上 Reddit 问账单为什么涨了。

选项 B：吃掉写入溢价。网关写入只按 1.0x 收用户（自己吞掉那 0.25x），只把 0.1x 的读取折扣传给用户。用户角度更可预测，但网关自己承担波动。只有在平均读取次数稳定大于 1 时才可持续。

ApiLink 选了 B。两个原因：

• 缓存的合理使用通常每次写入对应 5+ 次读取，期望值上数字成立。
• 用户自己预测账单是一大摩擦点。“为什么今天这一次调用比昨天贵 25%？”这种工单我们宁可不写。

值得说一句：这种模式能跑通的前提是用户不会故意"写一次就断开"刷被吸收的溢价。我们对单次缓存写入做了速率限制堵掉这条路径。

开缓存之前的自检清单

1. 估算该工作流的平均"写入 / 读取"比。如果读取次数低于 2，不要开缓存。
2. 确认 prompt 里没有 per-call 可变数据（时间戳、UUID、某些实现里的 user ID）混进可缓存前缀。
3. 查清楚你用的网关是吸收写入溢价还是原样透传。如果是透传，缓存未命中的日子账单波动会比标价高 25% 左右。
4. 每个工作流分别记录缓存命中率。命中率掉到 50% 以下就在漏钱——下一张账单出来前查清楚。
5. 跑 agent 循环时记录调用间隔。超过 4 分钟就有风险，超过 5 分钟必丢。

收尾

Prompt cache 在它设计的场景里是真省钱，在不适合的场景里就是 25% 的隐性加价。决定性数字是"每 5 分钟窗口内每次写入的读取数"。如果你测不出这个数，先别开。能测出来、且大于等于 3，就打开然后看着账单往下掉。

ApiLink 的 admin 面板有缓存命中率的统计；如果你想知道自己的工作流在缓存下表现如何，注册后跑几千次调用，去 analytics 里看。