Claude Opus 4.7 API 收费指南：$5/$25、Prompt Caching 和 Token 怎么算

先看价格：不止 $5 和 $25

下文用 MTok 表示 1,000,000 tokens。Anthropic 的 pricing 文档把 Base Input Tokens、Cache Writes、Cache Hits 和 Output Tokens 分开列出，因此实际入账也应分项计算。

关键点是：不要用“全部 token × 一个平均价”来估算。Claude Opus 4.7 的 input、output、cache write、cache read 单价不同；只要你的产品使用 prompt caching，成本模型就必须拆开算。

成本公式：先判断有没有 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.50。这只是按 Anthropic API 的 input/output 单价做的计算，不包含其他平台可能叠加的费用或差异。

使用 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 分开计费。

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。

比较稳妥的流程是：把实际会发给 Messages API 的 payload 原样拿去跑 count_tokens，包括 system prompt、messages、tools、图片或 PDF。这样可以在正式调用模型前估算 input token 成本，也方便在产品内设置预算上限、预警或拒绝超额请求。

请求完成后：用 response usage 做真实入账

请求完成后，应记录 API response 里的 usage，不要再用输出文本长度反推。Anthropic 的 Messages API 示例显示，response usage 可包含 input_tokens、output_tokens 等字段；streaming 文档也展示了 cache_creation_input_tokens、cache_read_input_tokens 等与缓存相关的字段。

如果使用 streaming，还要特别注意：Anthropic streaming 文档指出，message_delta 中的 usage token counts 是累计值，不是每个 event 的新增量。也就是说，如果把每个 delta 的 usage 直接相加，就会重复计费同一批 token。

团队月结和对账：看 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。

实践上可以这样分工：应用端记录每次请求的 usage，用于产品内限额、告警和即时成本估算；正式财务或团队对账，则以 Usage & Cost Admin API 的历史 usage/cost 数据为准。

从旧版升级到 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。

因此，“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 和成本上限。

实务核对清单

• 确认 API model ID 使用 claude-opus-4-7。
• 重要版本发布前，用 /v1/messages/count_tokens 对代表性 payload 做成本预估。
• 把 input_tokens、output_tokens、cache write、cache read 分开入账，不要只存一个 total token 数。
• 使用 streaming 时，记住 message_delta.usage 是累计值，不能逐个 event 直接相加。
• 团队月结、workspace 分账或历史趋势分析，使用 Usage & Cost Admin API。
• 从旧版 Claude model 升级到 Opus 4.7 前，重新测试 tokenizer 对实际 prompt 的影响。

总结一句话：Claude Opus 4.7 的基础单价很好记，input $5/MTok、output $25/MTok；但要把成本算准，必须在请求前用 count_tokens，请求后记录 usage，并把 prompt caching 和新 tokenizer 的影响纳入模型。