Claude vs GPT-5.5 提示缓存怎么省钱：2026 成本对比 + 3 个常见坑

cached-input 折扣大战已经收官。 2026 年 Anthropic 和 OpenAI 最新一代旗舰模型都把 cached 读取价砍到标准输入价的 10%——一个 9 折，最初是 Anthropic 的招牌，在 GPT-5.4 上线时被悄悄追平。真正值得问的问题不再是”谁的折扣更大”，而是哪家的 cache 机制能扛住你真实的 prompt 形态，以及哪三个错误正在无声地把你的 hit rate 压在零线。

快速行动：每条 prompt-caching 链路都通过 ofox.ai 跑——新用户首充享 ofox 折扣价，Claude Sonnet 4.6 cached read 直接打到 $0.30/M。一个 key 同时覆盖 Anthropic 和 OpenAI，不用拆两个账号 A/B。

这篇文章走一遍数学、按生产代码 review 的频次排出三个 cache-miss 模式，最后给一个能直接抄进 Python 或 Node 服务的 A/B 探针，通过 ofox 模型广场同时对比两家，不改 cache 逻辑。

30 秒答案：你的工作负载该选哪家 cache

低于 40% 的 hit rate，换提供商也救不了你。先修 §3 的模式，再算账。

TL;DR：10M cached token/天 真实月账单

口头标题是”Anthropic 9 折 vs OpenAI 5 折”——但 2026 年这条线按模型代次已经分裂：

数字假设 80% cache hit rate、5 分钟 TTL、每个命中周期 1 次写入。Sonnet 4.6 基价为示意——请以 ofox 模型广场 当前费率为准。

GPT-4.1 那一行是让团队最尴尬的——还在 2026 年跑 2024 年的代码。留在老模型上的代价不是延迟，是账单形状变了。 想系统性把每一项 LLM API 成本扒一遍，降低 AI API 成本指南 给了 cache 之外的 8 个杠杆。

那条过时的口号：9 折曾经是 Anthropic 独有，直到 GPT-5.4

Anthropic 在 2024 年 8 月以 beta 形式发了 prompt caching，经济结构干净：cache 读 0.1× 标准输入价（9 折），cache 写 1.25× 标准价（5 分钟 TTL），2× 标准价（1 小时 TTL）。9 折读取折扣成了营销口号。

OpenAI 同年晚些时候放出自动缓存。gpt-4o 系列起步折扣是 5 折——cached input 半价，开发者不用动手。这道缝就生出了”Anthropic 在 cache 定价上赢了”的共识，被几十篇博客复读，至今 2026 年还在引用。

但两件事变了：

1. GPT-5.4 和 GPT-5.5 把 cached input 降到 $0.50/M 对标 $5/M 标准价——这就是 9 折，跟 Anthropic 读取倍数一致。折扣档跟着模型代次走，不跟平台走。
2. Anthropic 仍然收 1.25× 写入费。OpenAI 自动缓存没有单独的写入项——首次调用按标准输入价计费，后续匹配前缀的部分变便宜。Anthropic 的写入费是每 5 分钟 TTL 续期时被收的一次性税。

含义：高 cache-hit 工作负载（每写入周期 ≥5 次命中）下，Anthropic 的 1.25× 写入费被摊薄，两家读取经济持平。低 cache-hit（每周期 <3 次命中）下，OpenAI 的无写入费结构赢出几个百分点。动态 prompt 完全无法持续命中前缀的，两家谁也救不了你。

规格速查：Anthropic vs OpenAI Prompt Caching

来源：Anthropic prompt caching 文档、OpenAI prompt caching 指南，2026-06-10 核实。

对成本建模最有杀伤力的一行是 Cache break point。OpenAI 的自动 cache 从请求开头锁定它能找到的最长稳定前缀。Anthropic 允许你在请求任意位置放最多四个 cache_control 标记——也就是说插在对话中间的检索文档也能缓存，system + tools 可以和下面的检索文档作为独立块分别缓存。对 RAG 工作负载这是真实的结构优势。对纯聊天无检索的场景，OpenAI 的自动模型更简单，在 GPT-5.5 上定价等价。

真实成本数学：一天 10M cached token 怎么算

假设这样一个工作负载：一个 agent 服务每天 10,000 次请求，每次 5,000 token 的 system prompt + tools + 检索上下文，加 500 token 用户消息，1,000 token 响应。前 5,000 token 是缓存目标。

每日可缓存输入： 10,000 请求 × 5,000 token = 50M token/天。其中 80% 命中暖 cache，20% 未命中（写入）。所以 40M 读取 token/天 + 10M 写入 token/天。

Anthropic Claude Sonnet 4.6（示意基价 $3/M 输入、$15/M 输出）

不开 cache：50M × $3/M = $150 + $15 用户 + $150 输出 = $315/天。节省 $100.50/天，约 32% 日账单下降。

OpenAI GPT-5.5（核实 $5/M 输入、$30/M 输出、$0.50/M cached input）

不开 cache：50M × $5/M = $250 + $25 用户 + $300 输出 = $575/天。节省 $180/天，约 31% 日账单下降。

账单对比

在这个 hit rate 下，两家节省比例几乎一致（≈31–32%）。Sonnet 4.6 和 GPT-5.5 之间的绝对金额差距，来自基础输入输出价格，不是 cache 机制。80% 命中下，‘9 折 cache 读’的标题落到现实里只剩’约 32% 总账单缩减’——因为输出 token 主导账单，写入还是要钱。

杠杆点是 hit rate，不是提供商。同一份 Sonnet 工作负载，把命中率从 80% 推到 95%，日成本再降 $7——大约再 3%。从 80% 掉到 40%，每天多 $20 写入费。下面三个模式就是命中率被吃掉的地方。

3 个先修的 cache-miss 模式

按生产代码 review 出现频次排，不是按严重程度。每一个都能在第一遍读代码时蒙混过去，无声地坏掉——唯一信号是 cache_read_input_tokens 字段贴着零线，账单照爬。

模式 1：可变 system prompt

bug 长这样：

system_prompt = f"""你是一个有用的助手。
当前时间: {datetime.utcnow().isoformat()}
可用工具: web_search, code_interpreter
用户 ID: {user.id}
..."""

每次调用 当前时间 都不同，每次字节前缀都不同。Cache hit rate：0%。修法是把动态值挪到 user message 末尾，或放到一个独立的非缓存块：

system_prompt = """你是一个有用的助手。
可用工具: web_search, code_interpreter
..."""  # 静态、可缓存

user_message = f"当前时间: {datetime.utcnow().isoformat()}\n用户 ID: {user.id}\n\n{actual_question}"

Anthropic 的话，这让你能把 cache_control 打在 system 块上。OpenAI 的话，让自动前缀探测器锁住静态 system 内容。两家收益一样。

这个 bug 还有个更隐蔽的变种：一个”静态”模板从一个字典里渲染出来，而字典的 iteration order 会因 Python 版本或一次配置 reload 而变。打印出来的字符串看起来一样；缓存哈希出来不一样。

模式 2：工具序列化字节不稳定

工具定义通常 JSON 化后发送。如果你这么构造：

tools = []
for tool_module in plugin_manager.discover_tools():
    tools.append({
        "name": tool_module.name,
        "description": tool_module.description,
        "input_schema": tool_module.schema,
    })

plugin_manager.discover_tools() 的顺序就是文件系统返回的顺序。换台机器、发一次新版、不同操作系统，顺序都不一样。同一批工具，不同字节，无命中。

修法是发送前先确定性排序：

tools = sorted(
    [tool_definition(t) for t in plugin_manager.discover_tools()],
    key=lambda t: t["name"],
)

序列化时强制 key 排序：

import json
serialized = json.dumps(payload, sort_keys=True, separators=(",", ":"))

这对 Anthropic（工具是显式缓存块的一部分）比对 OpenAI（自动检测对底层重排更宽容）更要命，但修复成本为零，两家都受益。我们见过生产系统靠这一个改动把命中率拉高 30 个百分点。

模式 3：滑窗对话历史

管长对话最自然的做法是限上下文：保留最近 N 条消息，新消息进来丢最老的。对 token 预算是对的。对 cache hit rate 是致命的。

把第 1 条丢了去加第 12 条时，前缀就变了。第 1 条之后的所有缓存字节都错位。Anthropic 的 cache_control 标记打在 system + tools 上仍然能命中；对话部分不会。

修法三选一，没有一个是免费的：

1. 只缓存 system + tools 前缀，接受对话尾巴不缓存。最简单。代价是对话历史的节省丢了。
2. 固定前缀 + 滑动尾巴：前 K 条永久保留，只在第 K+N 条之后开始滑动。K 通常 6–10，前提是老消息要么仍然相关要么已经被摘要。
3. 丢消息时把老消息摘要进 system prompt，摘要更新时刷一次 cache。命中率维持高位；system prompt 缓慢增长；cache 写入只发生在摘要边界。

Anthropic 这边选项 2 干净映射到固定前缀边界上的 cache_control 标记。OpenAI 这边只要你不动早期消息，自动 cache 会自己检测稳定前缀。

什么时候选 Anthropic 缓存

• 长检索上下文（RAG 文档 8k–50k token）：显式 cache_control 让你把文档块和 system prompt 分别缓存。文档位置浮动时 OpenAI 的自动 cache 做不到。
• 工具密集 agent，工具数 20+：Anthropic 把工具定义作为缓存块一部分。10k token 的工具目录命中一次能省真金白银。
• 预期缓存寿命 ≥30 分钟：Anthropic 的 1 小时 TTL（2× 写入费）比每 5 分钟重写一次便宜。
• 成本敏感批处理：9 折读 + 摊薄写入，是教科书级 Anthropic 案例。

模型直链：anthropic/claude-sonnet-4.6 是成本敏感工作负载的默认起点；Opus 4.8 是不计成本时的选择。中国大陆访问方式参见 Claude API 中国指南，支付支持微信/支付宝看 Claude API 支付指南。

什么时候选 OpenAI 缓存

• 聊天型工作负载，system prompt 稳定，无检索，无工具目录抖动：自动缓存开箱即用，零改动。
• 写入抖动高（cache hit rate <50%）：无写入费意味着没命中不付费。Anthropic 的 1.25× 写入费在这里咬人。
• GPT-5.4 或 GPT-5.5 已经在你的栈里：读取折扣追平 Anthropic，单纯为 cache 没必要换提供商。
• 跨大量短 prompt 路由，前缀差点点就能共享：prompt_cache_key 参数帮路由器落到自动检测可能错过的命中点。

openai/gpt-5.5 是 OpenAI 读取折扣追平 Anthropic 的那个模型。从 OpenAI 官方 SDK 切换过来的步骤，看 OpenAI SDK 迁移到 ofox.ai 指南。

两家都救不了你的时候

有几种工作负载，prompt caching 是错的工具：

• 真正无状态的单发调用 <1,024 token：两家最小阈值都在咬你，没什么可缓存。换更小更便宜的模型，跳过 cache。
• 热路径的个性化 prompt，prompt 每个字节都依赖用户（CRM 查询、实时仪表盘）：前缀真就是动态的。Cache 救不了。重构 prompt 把个性化挪到长共享框架之后，或者用 embedding 检索避免把个性化塞进 prompt。
• 跨模型 A/B 实验，cache 在两轮之间会过期：对比不公平。用 ofox 统一计费 比同 hit rate 下的同等数据，不是冷热对比。

值得知道的替代提供商：Google Gemini 在 Gemini 2.5 Pro 上提供 ~50–75% cached input 折扣（直连或走 ofox）；DeepSeek 和 Qwen 系列自动缓存，基础价更低，在输出成本上可能同时打过 Anthropic 和 OpenAI。切换模型的方式通过 ofox 一样。更广的省钱杠杆——多模型路由、批处理、流式——见 多模型路由成本优化。

通过 ofox 同时跑两家：10 行代码 A/B

Anthropic 的 cache_control 和 OpenAI 的自动缓存都可以通过 ofox 统一的 OpenAI 兼容端点访问。Model ID 字符串是唯一区别。把下面这个探针扔进服务里，并排测命中率。

Python — 一个循环同时 A/B

from openai import OpenAI
import os, json

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key=os.environ["OFOX_API_KEY"])

SYSTEM_PROMPT = open("system.md").read()  # 5k+ token，静态

def measure(model: str, query: str):
    resp = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": query},
        ],
        extra_body={"cache_control": {"type": "ephemeral"}} if "claude" in model else {},
    )
    usage = resp.usage.model_dump()
    return usage.get("prompt_tokens_details", {}).get("cached_tokens") or \
           usage.get("cache_read_input_tokens", 0)

for model in ["anthropic/claude-sonnet-4.6", "openai/gpt-5.5"]:
    cached = measure(model, "把这个 FastAPI handler 重构成 async DB 调用。")
    print(f"{model}: {cached} cached input tokens")

Node — 形态一样

import OpenAI from "openai";
import { readFileSync } from "fs";

const client = new OpenAI({ baseURL: "https://api.ofox.ai/v1", apiKey: process.env.OFOX_API_KEY });
const SYSTEM_PROMPT = readFileSync("system.md", "utf8");

async function measure(model, query) {
  const resp = await client.chat.completions.create({
    model,
    messages: [
      { role: "system", content: SYSTEM_PROMPT },
      { role: "user", content: query },
    ],
    ...(model.includes("claude") ? { cache_control: { type: "ephemeral" } } : {}),
  });
  return resp.usage.prompt_tokens_details?.cached_tokens ??
         resp.usage.cache_read_input_tokens ?? 0;
}

for (const model of ["anthropic/claude-sonnet-4.6", "openai/gpt-5.5"]) {
  const cached = await measure(model, "把这个 FastAPI handler 重构成 async DB 调用。");
  console.log(`${model}: ${cached} cached input tokens`);
}

紧挨着跑两次。第一次写 cache；第二次如果前缀真的稳定，会报一个高 cached 值。第二次还是零，说明上面三个模式之一在作怪。

企业治理：cache 是预算线的一部分

如果你团队还在按”标准输入价 × token”算月度 LLM 预算，cache 一开就要重做模型。Cache 读 + cache 写两条线必须分别建模，否则会出现”我们看似省了 30%，但月底超支 2 万”的剧本。

• 把 cache_creation_input_tokens 和 cache_read_input_tokens 单独打到 metrics 里。
• 给每个 agent 业务线分别建一个 hit rate SLO（例如对话 agent ≥75%、RAG agent ≥85%、单发 agent 不设）。
• 命中率连续 24 小时跌破 SLO 自动告警——这是上面三个模式悄悄上线的早期信号。

更完整的预算/配额治理框架在 企业 AI API 成本治理。

FAQ

（见上方 frontmatter 中的 faq 块——已渲染为页面 schema，用于 AI 搜索与 PAA 抽取。）

这次刷新核对的来源

• Anthropic Prompt Caching API 文档 —— 2026-06-10 核实读写倍数、各模型最小 token、TTL 选项
• OpenAI Prompt Caching 指南 —— 2026-06-10 核实自动激活、1024 token 起步、GPT-5.4/5.5 extended retention
• ofox 模型广场 —— 核实 live model ID anthropic/claude-sonnet-4.6 和 openai/gpt-5.5，cache 读写行项目都在
• ofox prompt caching 文档 —— 确认 Anthropic 的 cache_control 透传、OpenAI 自动激活
• 三家客户 agent 服务的内部生产 review（已脱敏）—— cache 命中率退化全部追踪到 §3 三个模式，时间窗 2026 Q1–Q2

价格和折扣率以发布时各提供商官方文档为准。开始按本文数学放量前，请在 ofox 模型广场 校对当前费率——模型定价按季度变动，GPT 系列读取倍数 2025–2026 一直在下行。§4 的数学假设 80% 命中率；上线前用你自己的工作负载重跑一遍。