# OpenAI 与 Claude 缓存计费：缓存输入、写入成本与回本计算

> 对比 OpenAI cached input 与 Claude cache write/read 的当前计费方式，包含 2026-05-19 价格边界、回本示例和必须记录的 usage 字段。

- Source: https://www.aifreeapi.com/zh/posts/openai-vs-claude-prompt-caching-cost
- Language: zh
- Published: 2026-05-19
- Updated: 2026-05-19
- Publisher: AI Free API (https://www.aifreeapi.com)

OpenAI 和 Claude 都能让重复的长前缀变便宜，但它们不是同一种账单。按 2026-05-19 检查到的官方价格和文档，OpenAI 当前 GPT-5.5、GPT-5.4、GPT-5.4 mini 的标准价格行把 cached input 计为普通输入的十分之一，并且没有单独的“写入缓存”溢价；Claude 的缓存读取同样是基础输入价的 0.1 倍，但第一次创建缓存要先付写入成本：5 分钟缓存是 1.25 倍基础输入，1 小时缓存是 2 倍基础输入。

所以决策不能只问“谁折扣更高”。如果你的系统提示、工具定义、产品目录、检索上下文或代码库摘要会稳定复用，OpenAI 更像自动命中的低摩擦折扣；Claude 更像可显式控制缓存边界和 TTL 的工程工具。真正该先做的是把账单拆成普通输入、缓存写入、缓存读取、缓存输入、缓存未命中和输出 token，然后在日志里确认 OpenAI 的 `usage.prompt_tokens_details.cached_tokens`，或 Claude 的 `cache_read_input_tokens`、`cache_creation_input_tokens` 和 `input_tokens`。

| 场景 | 更先看哪边 | 原因 | 必须验证 |
| --- | --- | --- | --- |
| 长系统提示每轮都一样 | OpenAI | 自动缓存、无写入溢价，命中后 cached input 更低 | `cached_tokens > 0` |
| 需要固定工具、系统提示、消息层级缓存边界 | Claude | 可以显式控制 cache breakpoint 和 TTL | `cache_creation_input_tokens` 与 `cache_read_input_tokens` |
| 只有一两次重复请求 | 都不该高估 | 写入、命中或输出成本可能吃掉节省 | 命中率、重复次数、输出占比 |
| 提示经常插入动态内容 | 先改布局 | 前缀不稳定会导致 miss | prefix hash 与请求形状 |
| 使用 Batch、长上下文或云市场 | 单独复核 | 基础价格表不能覆盖所有修饰项 | 当前官方价格页 |

![OpenAI 与 Claude 缓存计费决策板](https://www.aifreeapi.com/posts/zh/openai-vs-claude-prompt-caching-cost/img/cover.png)

## 先给结论：谁更便宜取决于复用方式

如果你的重复前缀足够长、足够稳定，而且请求会在缓存有效窗口内连续出现，OpenAI 的优势是简单：近期支持的模型会自动尝试缓存，提示词达到 1024 tokens 以上才有资格命中，第一次未命中按普通输入计费，后续命中按该模型的 cached input 价格行计费。对很多“同一个系统提示 + 不同用户问题”的 API 服务来说，这种模型意味着你可以先改日志，再逐步优化前缀，而不必先重写整套请求格式。

Claude 的优势不是“更省”这个单一结论，而是控制更明确。你可以通过自动的顶层 cache control 或显式的块级 cache control 来告诉系统哪些部分应该形成缓存；默认 5 分钟 TTL 适合短窗口内的会话和 agent 步骤，1 小时 TTL 适合预热后的多请求复用。代价是第一次写入不是普通输入价格：5 分钟写入是 1.25 倍，1 小时写入是 2 倍。只有后续读取足够多，写入溢价才会被摊薄。

这也解释了为什么“缓存降 50%”或“缓存降 90%”这类短说法不够用。50% 多来自旧模型时期或旧文章，不能直接套到当前 OpenAI 价格行；90% 只描述命中读取或 cached input 的折扣部分，也不能覆盖首次请求、未命中和输出 token。预算时要用“这轮请求落入哪个桶”来算，而不是用一个宣传数字覆盖全部请求。

## 计费词先拆清楚

缓存计费最容易误判的地方，是把 OpenAI 的 cached input 和 Claude 的 cache read 当成同一种东西，再把 Claude 的 cache write 忽略掉。OpenAI 的 cached input 是命中后的输入 token 价格行；Claude 的缓存计费至少有两个额外桶：创建或刷新缓存时的 cache write，以及命中后读取缓存的 cache read。两者都还会同时产生普通输入 token 和输出 token，所以请求总价不是一个折扣乘法。

![缓存账单流程图](https://www.aifreeapi.com/posts/zh/openai-vs-claude-prompt-caching-cost/img/cache-billing-flow.png)

| 账单桶 | OpenAI | Claude | 预算含义 |
| --- | --- | --- | --- |
| 普通输入 | 未缓存或不合资格部分 | 新输入、未缓存部分 | 每次都可能存在 |
| 缓存写入 | 没有单独写入溢价 | 5 分钟 1.25x，1 小时 2x | Claude 首次成本必须算入 |
| 缓存读取 | cached input 价格行 | cache read 0.1x 基础输入 | 命中后才出现 |
| 缓存未命中 | 回到普通输入 | 回到普通输入或重新写入 | 动态前缀会放大成本 |
| 输出 token | 不受 prompt cache 折扣影响 | 不受 prompt cache 折扣影响 | 长输出会稀释节省比例 |

这个拆法会改变工程优先级。你不是先问“这家便宜几成”，而是先问“我的稳定前缀是不是足够长、是不是放在请求开头、是不是在 TTL 内重复、是不是被日志证明命中”。只有这些问题成立，缓存价格才会进入账单。

## 当前价格行怎么用

本文只把价格当作 2026-05-19 的快照使用。OpenAI 当前价格页显示，GPT-5.5 标准短上下文价格行为每百万 token 输入 5 美元、cached input 0.50 美元、输出 30 美元；GPT-5.4 为 2.50 / 0.25 / 15 美元；GPT-5.4 mini 为 0.75 / 0.075 / 4.50 美元。重点不是记住这些数字，而是记住 cached input 行是普通输入的十分之一，并且当前标准行没有额外写入溢价。Pro 行是否支持 cached input 要单独看当前价格表，不能从标准模型推导。

Claude 当前价格页把缓存写入和缓存读取列出来。Opus 4.7、4.6、4.5 的基础输入是每百万 token 5 美元，5 分钟写入 6.25 美元，1 小时写入 10 美元，读取 0.50 美元，输出 25 美元；Sonnet 4.6、4.5 是 3 / 3.75 / 6 / 0.30 / 15 美元；Haiku 4.5 是 1 / 1.25 / 2 / 0.10 / 5 美元。Claude 的价格表让“写入”这件事显性化，因此它更适合你主动设计缓存段，而不是盲目期待自动命中。

价格还受 Batch、Scale Tier、长上下文、数据驻留、云市场和限速策略影响。正文里的数字适合解释基础数学，不适合替代你上线前的最终报价核对。只要文章或系统要写入具体金额，就应该保留检查日期。

## 一个重复前缀的回本例子

假设你有 100k tokens 的稳定前缀，后面跟着较短的用户问题。你连续跑 10 次请求，并且输出 token 暂时先单独排除。OpenAI GPT-5.4 的普通输入价是 2.50 美元/百万 token，cached input 是 0.25 美元/百万 token。第一次没有命中时，100k 前缀大约按普通输入计 0.25 美元；后面 9 次命中，每次 100k cached input 约 0.025 美元，9 次约 0.225 美元。10 次重复前缀输入合计约 0.475 美元，再加上每次的新输入和输出。

Claude Sonnet 4.6 的基础输入价是 3 美元/百万 token，5 分钟写入是 3.75 美元/百万 token，读取是 0.30 美元/百万 token。第一次为 100k 前缀创建 5 分钟缓存大约是 0.375 美元；后面 9 次命中读取约 0.03 美元一次，9 次约 0.27 美元。10 次合计约 0.645 美元，再加普通输入和输出。如果使用 1 小时 TTL，首次写入会更贵，但跨更长窗口的复用可能更稳。

![重复前缀回本顺序](https://www.aifreeapi.com/posts/zh/openai-vs-claude-prompt-caching-cost/img/break-even-ladder.png)

这个例子只说明账单结构，不说明所有工作负载都选择 OpenAI。Claude 的显式边界可能让复杂 agent、长工具定义和多段上下文更可控；OpenAI 的自动缓存可能让高并发稳定前缀更容易先吃到折扣。最终要把命中率、TTL 内重复次数、输出占比和未命中成本放进同一张表。

## 提示布局决定能不能命中

缓存不是语义相似就会便宜。OpenAI 的规则依赖重复前缀，稳定内容要尽量放在请求前面：系统提示、工具定义、静态政策、长文档摘要、产品目录、few-shot 示例都应该在动态用户输入之前。如果你每次在开头插入时间戳、随机追踪 ID、用户昵称或会变的检索片段，前缀就会变动，命中会下降。`prompt_cache_key` 可以帮助常见前缀的路由和命中率，但高流量同前缀也可能被分散到更多机器，仍要看实际 `cached_tokens`。

Claude 的布局更像显式合约。它按 `tools`、`system`、`messages` 的层级和 cache breakpoint 来理解前缀，前面的层级变化会影响后面的缓存段。如果你把高频变化内容放进工具定义或系统提示，后面再精细设置 breakpoint 也会被破坏。Claude 的好处是你能把“稳定的大块”和“每轮变化的小块”分开设计，坏处是工程纪律不够时会频繁写入、刷新或未命中。

上线前可以做一个最小验证：为稳定前缀生成 hash，记录模型、请求路径、endpoint、工具版本、系统提示版本和用户动态内容位置。只要 hash 变了，缓存命中预期就要重新计算。只要模型或价格行变了，成本表也要重新核对。

## 日志字段比体感更可信

不要用“我重复发了同一段话”来判断缓存已经省钱。OpenAI 要看响应里的 `usage.prompt_tokens_details.cached_tokens`。如果请求低于 1024 tokens，或前缀没有匹配，通常会看到 cached tokens 为 0。你还应该同时记录总输入、输出、模型名、请求时间、前缀 hash 和是否使用了 `prompt_cache_key`，否则账单异常时很难回放。

Claude 要同时看 `cache_read_input_tokens`、`cache_creation_input_tokens` 和 `input_tokens`。`cache_creation_input_tokens` 说明本次产生了写入成本，`cache_read_input_tokens` 说明本次从缓存读取了输入，`input_tokens` 则提醒你仍然有普通新输入。把三个字段合起来，才能知道某次请求是 hit、write、miss，还是同时包含多个桶。

![缓存日志字段地图](https://www.aifreeapi.com/posts/zh/openai-vs-claude-prompt-caching-cost/img/usage-field-map.png)

一个实用的日志表至少包含这些列：provider、model、request_id、endpoint、prefix_hash、prompt_cache_key 或 cache breakpoint、input_tokens、cached_tokens、cache_creation_input_tokens、cache_read_input_tokens、output_tokens、invoice_period、estimated_cost、actual_invoice_cost。先用 24 小时小样本看命中率，再决定是否为了缓存重构提示布局。

## 价格修饰项要单独放一层

很多团队的预算错误来自把基础价格套到所有入口。Batch API 可能改变单价，但也改变延迟和作业形态；长上下文价格行可能不同；云市场、数据驻留和企业协议可能有独立价格；Claude 的 1 小时缓存可以改善某些长窗口复用，但写入价格更高；OpenAI 的扩展保留策略也要看支持模型和当前文档。把这些修饰项混进基础回本例子，会让文章看起来简单，却让上线预算失真。

限速也不能混为一谈。OpenAI 文档说明 cached tokens 仍然计入 TPM，因此“省输入钱”不等于“释放全部吞吐”。Anthropic 文档在 1 小时缓存讨论里给出了不同的 rate limit 影响描述。对生产系统来说，成本表旁边应该还有一张容量表：每分钟请求数、输入 token、缓存读取 token、输出 token、重试量和失败率。

## 什么时候选 OpenAI

优先考虑 OpenAI 的典型场景，是你有稳定长前缀、希望低改造成本地获得缓存折扣，并且不需要人工控制多个缓存段。客服机器人、固定政策问答、长系统提示的工具调用、相同 schema 的批量分析，都可能符合这个模式。你要做的工程动作是把稳定内容固定在前面，减少前缀噪声，记录 `cached_tokens`，并按模型价格行估算。

不该把 OpenAI 缓存理解成“所有重复内容都自动便宜”。低于资格阈值、前缀顺序变化、模型不支持、请求分散、动态内容插入过早，都会让 cached input 不出现。还有一个常见误区：输出 token 如果很长，输入缓存节省会被输出成本稀释。生成长报告、长代码或长推理时，输出预算仍然要单独控制。

## 什么时候选 Claude

优先考虑 Claude 的场景，是你愿意为缓存边界和 TTL 付出工程纪律。长工具定义、多阶段 agent、代码库摘要、固定系统指令、多段上下文复用、需要预热的工作流，都可能从 Claude 的 cache control 中受益。你可以明确哪些部分应该缓存、缓存多久、什么时候刷新，也可以把写入和读取分别计入指标。

Claude 的风险也来自显式控制：写入成本一定要先算，TTL 过短会导致重复写入，1 小时 TTL 写入更贵，层级前面的变化会让后面的缓存段失效。如果你的请求变化大、重复次数少，或者团队没有记录 `cache_creation_input_tokens` 和 `cache_read_input_tokens`，Claude 的“可控”会变成“误以为省钱”。

## 实施检查清单

1. 把稳定内容移到请求前缀：系统提示、工具、示例、固定上下文在前，用户动态内容在后。
2. 为前缀生成稳定 hash：任何版本变动都要能解释命中率变化。
3. 分别记录 OpenAI 和 Claude 的 usage 字段，不要只记录总 token。
4. 用同一模型、同一路径、同一前缀做小样本压测，至少覆盖首次请求和后续命中。
5. 把输出 token 单独列账，避免把输入缓存节省误当成整单节省。
6. 每次价格页、模型名、TTL 或云平台入口变化后，重新跑一遍回本表。
7. 在账单周期结束后，用发票明细对照日志估算；如果差距大，先查 miss、write、模型路由和价格修饰项。

这套检查清单比“打开缓存”更重要。缓存本身只是一个价格机制，真正的成本优化来自稳定前缀、可复现请求、可解释日志和可复核账单。

## 与相邻主题的边界

如果你要比较 OpenAI、Claude、Gemini 的整体 API 成本，可以先看[多提供商 API 成本对比](/zh/posts/gemini-api-vs-openai-vs-claude-2026-cost-guide)。那类页面应该处理模型价格、输出成本、吞吐和任务选择。本文只处理 prompt caching 计费，不评价模型质量，也不把缓存价格当成总拥有成本。

如果你要写 Claude 具体代码，需要再看 cache control、breakpoint、SDK 形状和错误处理。本文只解释为什么 Claude 的写入和读取要分开算，以及这些字段如何进入预算。把实现细节和账单边界分开，反而更容易定位问题：命不中是布局问题，写入太多是 TTL 或边界问题，账单偏高可能是输出或特殊价格问题。

## 常见问题

### OpenAI prompt caching 现在还是 50% 折扣吗？

不能这样概括。旧发布和旧文章常用 50% 描述 GPT-4o 或 o1 时代的缓存输入价格，但 2026-05-19 检查到的当前 OpenAI 标准 GPT-5.5、GPT-5.4、GPT-5.4 mini 价格行把 cached input 列为普通输入的十分之一。以后刷新文章时，应重新看当前价格页，而不是沿用旧百分比。

### Claude 为什么要把写入和读取分开？

因为 Claude 的缓存模型显式暴露了创建缓存和读取缓存两个动作。第一次把一段前缀写入缓存时会产生写入成本，后续在 TTL 内命中时按读取价格计费。这个设计让你能控制缓存边界，但也要求你把首次写入、重复读取和未命中分开预算。

### 输出 token 会被缓存折扣影响吗？

不会。Prompt caching 主要作用在重复输入前缀上，输出 token 仍然按模型输出价格计费。输出很长时，输入缓存带来的节省会被输出成本稀释，所以成本表必须把 output tokens 单列出来。

### 提示词低于 1024 tokens 还会命中吗？

OpenAI 文档把 1024 tokens 作为 prompt caching 的资格阈值；低于这个长度通常不会产生 cached tokens。Claude 的最小缓存 token 数按模型变化，当前文档列出的不同模型有不同阈值。不要把一个模型的阈值写成所有模型的永久规则。

### Claude 现在只能手动设置缓存吗？

不准确。Claude 文档现在同时支持自动顶层 cache control 和显式块级 cache control。实际区别在于 Claude 仍然需要你接受它的缓存合约和层级规则；OpenAI 则更偏自动命中 stable prefix。

### 为什么缓存命中率和账单对不上？

常见原因包括前缀 hash 变化、动态内容放得太靠前、TTL 过期、模型或 endpoint 不一致、Claude 重复写入、OpenAI cached tokens 仍计入 TPM、输出 token 占比过高，以及价格修饰项没有纳入估算。先按日志字段分桶，再查发票。

### 我应该为了缓存改供应商吗？

只有当缓存前缀足够长、重复频率足够高、输出成本可控、日志能证明命中时，才值得把缓存计费纳入供应商切换。否则先调整提示布局和日志，等有命中率样本后再比较 OpenAI 与 Claude 的真实成本。