Claude Opus 4.7 的 API 价格表面上很直观：input $5/百万 token，output $25/百万 token。但如果你的应用有长上下文、工具定义、图片/PDF 输入，或者启用了 prompt caching，只看一个“总 token 数”很容易把账算偏。
Anthropic 表示，开发者可以通过 Claude API 使用模型 ID claude-opus-4-7；第三方价格索引也列出 Claude Opus 4.7 从 $5/百万 input tokens、$25/百万 output tokens 起步。[7][
9][
21] 不过，实际账单仍应以你调用的渠道为准：如果不是直接走 Anthropic API，而是通过云厂商或聚合平台接入，要查看该平台最终计费规则。[
19]
先看价格：不止 $5 和 $25
下文用 MTok 表示 1,000,000 tokens。Anthropic 的 pricing 文档把 Base Input Tokens、Cache Writes、Cache Hits 和 Output Tokens 分开列出，因此实际入账也应分项计算。[19]
| 计费项目 | 单价 | 怎么理解 |
|---|---|---|
| Base input tokens | $5 / MTok | 普通输入 token，未按 cache write/read 计费的部分。[ |
| Output tokens | $25 / MTok | Claude 生成回复时产生的输出 token。[ |
| Prompt cache write，5 分钟 TTL | $6.25 / MTok | 第一次写入可复用的 prompt cache，TTL 为 5 分钟时适用。[ |
| Prompt cache write，1 小时 TTL | $10 / MTok | 写入 1 小时 TTL 的 prompt cache 时适用。[ |
| Cache read / hit | $0.50 / MTok | 命中并读取已缓存内容时适用。[ |
关键点是：不要用“全部 token × 一个平均价”来估算。Claude Opus 4.7 的 input、output、cache write、cache read 单价不同；只要你的产品使用 prompt caching，成本模型就必须拆开算。[19]
成本公式：先判断有没有 prompt caching
不使用 prompt caching
最基础的公式是：
成本 = input_tokens ÷ 1,000,000 × 5 + output_tokens ÷ 1,000,000 × 25
例如一次请求包含 200,000 input tokens 和 20,000 output tokens，不考虑缓存时，费用就是 $1.00 + $0.50 = $1.5019]
使用 prompt caching
启用 prompt caching 后，应按不同 token 类型逐项相加：
成本 = base_input_tokens ÷ 1,000,000 × 5 + output_tokens ÷ 1,000,000 × 25 + cache_write_5m_tokens ÷ 1,000,000 × 6.25 + cache_write_1h_tokens ÷ 1,000,000 × 10 + cache_read_input_tokens ÷ 1,000,000 × 0.50
如果只使用一种缓存 TTL，就只保留对应的 cache write 项。Anthropic 的 streaming 文档示例显示，usage 中可能包含 input_tokens、output_tokens、cache_creation_input_tokens、cache_read_input_tokens 等字段；pricing 文档也将 cache write 和 cache hit 分开计费。[15][
19]
Token 怎么算最准确：请求前用 count_tokens
不要用中文字数、英文字数或字符数去粗略估 API 成本。Anthropic 的 /v1/messages/count_tokens endpoint 用于在真正发送 message 之前计算 token；文档说明，它接受与创建 message 类似的结构化输入，包括 system prompts、tools、images 和 PDFs，并返回 total input tokens；所有 active models 都支持 token counting。[18]
比较稳妥的流程是：把实际会发给 Messages API 的 payload 原样拿去跑 count_tokens，包括 system prompt、messages、tools、图片或 PDF。这样可以在正式调用模型前估算 input token 成本，也方便在产品内设置预算上限、预警或拒绝超额请求。[18]
请求完成后：用 response usage 做真实入账
请求完成后，应记录 API response 里的 usage，不要再用输出文本长度反推。Anthropic 的 Messages API 示例显示，response usage 可包含 input_tokens、output_tokens 等字段；streaming 文档也展示了 cache_creation_input_tokens、cache_read_input_tokens 等与缓存相关的字段。[15][
17]
如果使用 streaming，还要特别注意：Anthropic streaming 文档指出，message_delta 中的 usage token counts 是累计值，不是每个 event 的新增量。也就是说，如果把每个 delta 的 usage 直接相加，就会重复计费同一批 token。[15]
团队月结和对账：看 Usage & Cost Admin API
单次 response log 适合做实时监控，但团队月结、workspace 分账、长期趋势分析，应该再使用 Anthropic 的 Usage & Cost Admin API。官方文档称，该 API 提供 programmatic、granular access to historical API usage and cost data，并可按 model、workspace、service tier 等维度拆分 usage report。[16]
实践上可以这样分工：应用端记录每次请求的 usage，用于产品内限额、告警和即时成本估算；正式财务或团队对账，则以 Usage & Cost Admin API 的历史 usage/cost 数据为准。[16]
从旧版升级到 Opus 4.7：要重新跑 token budget
Claude Opus 4.7 引入了新的 tokenizer。Anthropic 文档说明，新 tokenizer 处理文本时，可能使用约为 previous models 的 1x 至 1.35x tokens，最高约多 35%，实际幅度因内容而异；同一段 input 用 /v1/messages/count_tokens 在 Opus 4.7 和 Opus 4.6 上会返回不同 token number。[20]
因此，“input $5/MTok、output $25/MTok”不代表升级后账单一定不变。如果你从 Opus 4.6 或更早模型迁移到 Opus 4.7，建议抽取高流量 prompt、长上下文 prompt、包含 tool definitions 的 payload，以及成本最高的 workflow，重新跑一遍 /v1/messages/count_tokens，再更新 alert、rate limit 和成本上限。[18][
20]
实务核对清单
- 确认 API model ID 使用
claude-opus-4-7。[9]
- 重要版本发布前，用
/v1/messages/count_tokens对代表性 payload 做成本预估。[18]
- 把
input_tokens、output_tokens、cache write、cache read 分开入账，不要只存一个 total token 数。[15][
19]
- 使用 streaming 时，记住
message_delta.usage是累计值，不能逐个 event 直接相加。[15]
- 团队月结、workspace 分账或历史趋势分析，使用 Usage & Cost Admin API。[
16]
- 从旧版 Claude model 升级到 Opus 4.7 前，重新测试 tokenizer 对实际 prompt 的影响。[
20]
总结一句话：Claude Opus 4.7 的基础单价很好记，input $5/MTok、output $25/MTok；但要把成本算准，必须在请求前用 count_tokens，请求后记录 usage，并把 prompt caching 和新 tokenizer 的影响纳入模型。[18][
19][
20]
