Anthropic API 定价怎么看:输入、输出与缓存 token 成本怎么算

Anthropic（Claude）API 按 token 计费，核心规则是：输入 token 和输出 token 分开计价，输出单价通常明显高于输入；缓存写入和缓存读取各自是独立价格档位，命中缓存能大幅压低重复上下文的成本。 估算自己的账单时，不能只记一个"每百万 token 多少钱"，而要按"输入量 × 输入单价 + 输出量 × 输出单价 + 缓存写入量 × 缓存写入单价 + 缓存读取量 × 缓存读取单价"分开算。适用前提是你已经确定要用哪个 Claude 模型档位——Haiku、Sonnet、Opus 之间的单价差距很大，选错档位比算错公式影响更大。

三个计费维度：输入、输出、缓存

Anthropic 的账单结构可以拆成四类 token 事件：

关键机制在于：输出 token 的单价高于输入 token，所以"让模型少说废话"和"让模型多读资料"对成本的影响方向相反。一个只输出 200 token 但读了 5 万 token 上下文的请求，和一个输出 5 千 token 的请求，谁更贵取决于具体单价，必须分开算。

缓存则是为重复使用的长上下文设计的。比如你把一份 3 万 token 的产品文档作为系统提示反复调用，第一次是缓存写入（较贵），之后每次命中缓存读取（便宜很多）。如果同一段上下文只用一次，缓存反而增加成本。

不同 Claude 档位单价差异大，先选模型再算钱

Anthropic 的模型按能力分档（如 Haiku、Sonnet、Opus），档位越高单价越贵。这意味着：

• 分类、抽取、简单问答这类任务，用低档模型往往够用，单价低一个量级。
• 复杂推理、长文写作、代码生成才需要高档模型。
• 同一个应用里可以混用：简单请求走便宜档，复杂请求走贵档，整体成本能显著下降。

所以正确的顺序是：先按任务难度选模型档位，再拿该档位的单价去套公式，而不是先算总价再纠结模型。

怎么核对最新单价

Anthropic 的官方定价页是权威来源，单价会随新模型发布调整。第三方对比站可以作为交叉核对，例如 pricepertoken.com 这类站点汇总了 OpenAI、Anthropic、Google、Mistral 等多家 API 的 token 单价，并标注"Updated daily with official prices"，适合快速横向比较。使用时注意两点：

• 对比站的数据有更新日期（该站页面显示 "Last updated: October 4, 2026"），核对时看清时效。
• 缓存写入、缓存读取这类细分档位，以官方文档为准，对比站不一定完整覆盖。

按自己的用量套公式估算

拿到单价后，用你真实的月均用量估算：

月成本 ≈
  月输入 token 量   × 输入单价
+ 月输出 token 量   × 输出单价
+ 月缓存写入量     × 缓存写入单价
+ 月缓存读取量     × 缓存读取单价

举例：假设某档模型输入单价为每百万 token X 元、输出为每百万 token Y 元（Y 通常大于 X）。若你每月发送 200 万输入 token、生成 50 万输出 token，且没有用缓存，成本就是 2X + 0.5Y。如果其中 150 万输入 token 是重复的长上下文并命中缓存，那部分就从输入单价换成更低的缓存读取单价，总成本随之下降。

估算时预留两块波动：

• 缓存命中率不稳定：上下文改动、请求间隔过长都可能导致缓存失效，退回按普通输入计价。
• 长上下文放大输入量：把整份文档塞进每次请求，输入 token 会成倍增长，这是最常见的超支来源。

常见卡点

• 只记一个单价：把输入和输出当成同价，估算必然偏差。
• 忽略输出占比：对话类应用输出往往比预期多，输出单价高时影响明显。
• 缓存用错场景：一次性上下文开缓存只增加写入成本，不省钱。
• 用过时单价：模型迭代快，几个月前的数字可能已失效，务必核对更新日期。