← Back to Blog

Claude API 降本实操:Prompt Caching 与 Batch API 怎么省

(no oficial)

Esta guía la mantiene la comunidad de forma independiente. No está afiliada, respaldada ni patrocinada por el proveedor de la herramienta de terceros que trata. Todas las marcas de terceros son propiedad de sus respectivos titulares.

November 3, 2026

Claude API 降本实操:Prompt Caching 与 Batch API 怎么省

TL;DR: Claude API 的账单高,多数不是模型单价贵,而是调用方式贵。官方给了三板斧:Prompt Caching 把重复前缀的读取价压到基础输入价的 0.1 倍、Batch API 把全部用量打五折、再加上一批省 token 的写法。本文把三者的计费规则、适用边界和代码写法一次讲清,每个数字都标了官方出处与核对日期。

一、钱花在哪:两类最常见的浪费

先定位问题。Claude 按 token 计费,一次请求的账单 = 输入 tokens × 输入单价 + 输出 tokens × 输出单价。多数人账单失控,卡在两个地方。

第一类:重复前缀。 每次请求,system prompt、工具定义、长对话历史都被完整计费。一段 2 万 token 的稳定前缀跑 100 轮对话,就是 200 万 token 的输入费用——而这 2 万 token 一个字都没改过。

第二类:用同步通道跑批量任务。 数据集打标、回归评测、离线清洗,这些活不需要当场出结果,却走了和线上聊天一样的全价通道。

这两类浪费各有一个官方工具:对应用 Prompt Caching 和 Batch API。第三板斧在写法层面,对两者同时有效。

二、Prompt Caching:命中规则与计费

Prompt Caching 让 API 记住请求前缀,重复部分不再按全价计费。按 2026-10-30 核对的官方文档(Prompt caching),倍率是:

  • 缓存写入(5 分钟 TTL):基础输入价的 1.25 倍
  • 缓存写入(1 小时 TTL):基础输入价的 2 倍
  • 缓存命中(读取):基础输入价的 0.1 倍,即命中部分省 90%

新一代模型的命中价更低:Claude Opus 5.5 与 Claude Sonnet 5.5 为 0.05 倍,Claude Fable 5.1 与 Claude Mythos 5.1 为 0.025 倍,其余模型沿用 0.1 倍。官方原文:5 分钟档在一次缓存读之后即回本。

以 Opus 5.5 官方牌价(每百万 token,2026-10-30 核对)为例:基础输入 $4、5 分钟缓存写 $5、1 小时缓存写 $8、缓存读 $0.20、输出 $20。

算笔账。2 万 token 稳定前缀跑 100 轮:不缓存 = 200 万 token 输入,约 $8.00;开缓存 = 一次写入约 $0.10,99 次读取约 $0.40,合计约 $0.50——不到原来的十六分之一(按上表牌价推算)。

三条命中规则要记住:

  1. 前缀必须逐字稳定。 缓存是前缀哈希,前缀里混进一个变动的字(时间戳、随机 ID、每次不同的检索结果),整段失效。
  2. 有最小长度门槛。 官方口径:512 token(Opus 5.5、Sonnet 5.5、Haiku 5.5、Opus 5、Fable 5 系列等)、1,024 token(Opus 4.8、Sonnet 5、Sonnet 4.6 等)、2,048 token(Opus 4.7、Mythos Preview 等)、4,096 token(Opus 4.6、Opus 4.5、Haiku 4.5 等)。低于门槛按普通请求处理,不报错——但你会以为缓存生效了,实际没有。
  3. 回溯窗口是 20 个 block。 对话变长时断点被推离上次写入位置超过 20 个 block,就找不到旧条目了;这时要在更早的位置再加一个断点。

另外两个容易忽略的细节:缓存断点本身不额外计费,加更多断点不会让账单变高(只按真正被缓存和被读取的内容计费);缓存默认 5 分钟 TTL,每次命中会免费刷新,所以高频对话不需要额外花钱维持。

三、把稳定内容放前面:可复制的写法

排序决定生死:system prompt → 工具定义 → 长期知识与记忆 → 对话历史 → 本轮新问题。越稳定的内容越靠前。

在稳定前缀的末尾打一个断点即可,官方文档的写法是给 content 块加 cache_control:

json
{
  "system": [
    {
      "type": "text",
      "text": "稳定的系统提示词与规则",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "本轮的问题" }
  ]
}

需要 1 小时 TTL 时,在断点上写 "cache_control": { "type": "ephemeral", "ttl": "1h" }——官方口径是 1 小时档按 2 倍基础输入价写入。

如果走 SDK,同样的语义这样表达:

python
import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": STABLE_SYSTEM_PROMPT,          # 逐字不变的部分
        "cache_control": {"type": "ephemeral"},  # 断点打在这里
    }],
    messages=[{"role": "user", "content": user_input}],
)
print(resp.usage.cache_creation_input_tokens, resp.usage.cache_read_input_tokens)

最后两行是验收位:cache_creation_input_tokens 和 cache_read_input_tokens 都是 0,就说明这次根本没命中缓存(多半是没到最小长度门槛),不是缓存"坏了"。

四、Batch API:不赶时间的任务直接五折

Message Batches API 把请求打包异步执行。按 2026-10-30 核对的官方文档(Batch processing):

  • 全量五折:输入、输出、特殊 token 一律按标准价的 50% 计
  • 时效:多数批次 1 小时内完成,24 小时未完成即过期作废
  • 规模:单批最多 100,000 条请求或 256 MB,先到者为准
  • 结果保留:创建后 29 天内可下载
  • 不支持:stream、speed、fallbacks,以及 max_tokens: 0(批量下的缓存预热不支持)
  • 叠加:Batch 折扣与 Prompt Caching 折扣可叠加

批量场景下的缓存命中是尽力而为——官方原文:用户实际经历的命中率在 30%–98% 之间,取决于流量形态。所以想让批量也吃到缓存,两个动作:一是每条请求里放完全相同的 cache_control 块,二是保持请求流稳定不断档。

可复制的提交方式:

bash
# 1) 准备一个 JSONL 文件,每行一条 {"custom_id": "...", "params": {...}}
curl -s https://api.anthropic.com/v1/messages/batches \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  --data-binary @batch.jsonl

提交后拿 results_url,轮询该地址取回每条请求的结果。适合"今晚跑完、明早要结果"的活:数据集打标、回归评测、批量翻译、文档抽取。要用户当场看到响应的,别用 batch。

五、第三板斧:省 token 的写法清单

折扣之外,写法直接决定 token 总量:

  • system prompt 写短写稳:不复述用户已能看到的信息,不放会变的内容
  • 长对话定期摘要:把上百轮历史压成一段摘要再继续,别让上下文无限滚
  • 给 max_tokens 设上限:不让模型把简单问题答成长文
  • 按需给上下文:不整库粘贴代码,先检索再贴相关片段
  • 工具定义固定成一套:稳定地放在前缀里吃缓存,而不是每次拼新的

这不是玄学,是计费表的直接推论:输入按 token 计费,前缀稳定才命中缓存;输出比输入贵得多——Opus 5.5 输出 $20、输入 $4(每百万 token,2026-10-30 核对),管住输出长度和上下文长度同样值钱。

六、三板斧怎么选

场景用什么效果
交互式产品,多轮对话Prompt Caching命中部分输入价 ×0.1(Opus 5.5 / Sonnet 5.5 为 ×0.05)
离线批量,1 小时后要结果Batch API全量 ×0.5
写完就不改的固定前缀缓存断点一次 1.25× 写入,换长期 0.1× 读取
怎么调都贵先改写法token 总量降了,折扣才有意义

三件事不互斥:批量任务可以同时吃缓存折扣,所有请求都受益于更省的写法。

七、在 CodeGateway 上把成本看清楚

先把定位说清楚:CodeGateway 是多模型聚合网关,在上游官方刊例价之上叠加统一倍率计费——它是加价渠道,不是折扣渠道。 省钱的主体是本文这三板斧,网关解决的是"接入"和"看得见"这两件事。

已交付的能力有三个(数字以站内页面为准,2026-10-30 核对):

  • 一把 key 多模型:同一把 API Key 调 Claude、GPT、Gemini、DeepSeek 等多家模型,模型清单见模型目录。不用为每家厂商分别注册、绑卡。
  • 透明计费口径:消费倍率固定 1.07×(相对上游官方刊例价),充值另收 2% 服务费,构成见统一倍率详解。上游调价时基础价同步调整,倍率本身不变。
  • 余额与用量可查:登录 Dashboard 概览可看余额、近期用量与按模型的费用拆分,充值与计费细节见充值与费用指南。一个项目一把 key,账单天然按 key 拆开。

优化前先看一周账单,优化后再看一周——三板斧有没有真省下来,用数据说话。想先对齐单价口径,可对照 Claude API 定价与 Token 计费指南。

八、常见问题

Prompt Caching 什么时候反而更贵? 写多读少:前缀只用一两次,或每次都变。付了 1.25 倍写入费,却没有足够的 0.1 倍读取来摊薄。

Batch 结果能流式拿吗? 不能,batch 不支持 stream,整批返回。

前缀长度不够会报错吗? 不会。低于最小长度时按普通请求处理,官方文档明说不返回错误——用 cache_read_input_tokens 是否为 0 来判断有没有命中。

Batch 折扣和缓存折扣能叠加吗? 能。官方文档明确写明两种折扣可组合使用;但批量下的缓存命中是尽力而为。

在哪能看到缓存有没有命中? 响应的用量统计会把缓存创建与缓存读取的 token 数分开列出。

九、现在就去领一把 key

没有官方 Key,或者不想绑外卡?⇒ 直接在 CodeGateway 领一个。 注册即用,一把 Key 打通 Claude / GPT / Gemini 等多家模型;按量计费,用多少扣多少,余额可查,没有月费门槛。计费与充值细节见定价页与充值与费用指南。

Author:CodeGateway 团队

Resuelve los límites de claves de API y de facturación con CodeGateway

¿Sin clave de API oficial o con problemas para pagar con tarjeta internacional? Crea una clave sk-cg- al instante. Una sola clave para Claude, GPT, Gemini y DeepSeek: los modelos de texto de Claude y Gemini usan el protocolo Anthropic Messages (/v1/messages); los endpoints de texto compatibles con OpenAI no los aceptan. Incluye enrutamiento inteligente y créditos de prueba.

Crear cuenta gratis