Claude API 成本优化：先找清 token 花在哪，再选对手段（2026）

Claude API 成本优化最有效的做法分两步：先读自己请求返回的 usage 对象，看清账单主要落在哪一类 token 上；再针对这一类去用对应的手段。按 Anthropic 官方价目表，当前主力模型的输出 token 单价是输入的 5 倍，所以该怎么省取决于你的成本结构，而不是一份通用清单。

多数「降低 Claude 账单」的建议一上来就讲缓存和批处理。这两招确实有用，但它们只作用于特定的计费桶：如果你的花费主要来自长回答，缓存提示词几乎没有影响；如果主要来自工具定义和图片，换便宜模型的效果也比想象中小。本文讲的是动手之前的诊断这一步。价目表本身请看我们的 Claude API 价格解析。

下文所有价格与倍率均引自 Anthropic 官方定价页（platform.claude.com/docs/en/about-claude/pricing），数据截至 2026 年 9 月。价格会调整，做预算前请回到原始页面复核。

第一步：先量清 Claude API 成本到底花在哪

每个 Messages API 响应都带一个 usage 对象。根据你用到的功能，它可能包含：

倍率来自 Anthropic 定价页。这张表的意义在于：同一个请求可能同时落进四个价位不同的桶，后面所有内容讲的都是怎么把 token 从贵的桶里挪出来。

按请求记录完整的 usage，并打上路由标签（例如 classify、chat、agent-step）。取有代表性的一天，把每个字段按路由求和，再折算成金额：

RATES = {  # 美元 / 百万 token，引自 Anthropic 定价页（2026 年 9 月）
    "claude-opus-5":    {"in": 5.0, "out": 25.0},
    "claude-sonnet-5":  {"in": 2.0, "out": 10.0},
    "claude-haiku-4-5": {"in": 1.0, "out": 5.0},
}

def cost_breakdown(model, u, cache_write_mult=1.25):
    r = RATES[model]
    parts = {
        "input":       u.get("input_tokens", 0) * r["in"],
        "cache_write": u.get("cache_creation_input_tokens", 0) * r["in"] * cache_write_mult,
        "cache_read":  u.get("cache_read_input_tokens", 0) * r["in"] * 0.1,
        "output":      u.get("output_tokens", 0) * r["out"],
    }
    return {k: v / 1_000_000 for k, v in parts.items()}

把某条路由全部流量的四个部分加总，看各自占比。通常会有一个桶占掉大头，它决定了你属于下面哪种成本结构。如果流量经过网关转发，网关的逐请求用量记录里就有同样的字段，不用额外埋点，字段对应关系见我们的 用量记录解读。

第二步：按成本结构选对手段

结构 A：输出为主

特征：output_tokens 占大头。常见于长文生成、详细解释和 Agent 循环。

按 Anthropic 价目表，Opus 5、Sonnet 5、Haiku 4.5 的输出单价都是输入的 5 倍，所以削减输出对账单的影响最快。

• 在质量可接受的路由上调低 effort。 Anthropic 文档中的 output_config.effort 有 low、medium、high（默认）、xhigh、max 五档，并说明它作用于全部输出 token，包括正文、工具调用和思考过程。请按路由在自己的评测集上逐档测试，而不是全局一刀切。
• 明确要求更短的回答。 Anthropic 特别说明，在 Claude Opus 5 上调整 effort 并不能稳定缩短可见回答，建议直接在提示词里约束长度。写清格式（「用三条要点回答」「只返回 JSON」）本身就是成本控制。
• 别把 max_tokens 当省钱手段。 它是上限而不是目标，你只为实际生成的 token 付费。上限设太低只会截断回答，截断后重试反而花两次钱。

结构 B：输入为主，且前缀稳定

特征：每次调用的 input_tokens 都很大，而且大部分是相同的系统提示词、文档或工具列表。

这正是提示词缓存的设计场景。据 Anthropic 说明，缓存命中的价格是基础输入价的 10%，5 分钟缓存读一次即可回本，1 小时缓存读两次回本。效果要在 usage 里核对：如果重复调用时 cache_read_input_tokens 一直是 0，说明缓存没命中。各种悄悄让缓存失效的原因见我们的 提示词缓存指南。

有一个相互影响值得注意：Anthropic 说明在请求之间修改顶层 effort 会使提示词缓存失效，所以在依赖缓存的对话里，effort 选定后就保持不变。

结构 C：输入为主，因为历史越来越长

特征：input_tokens 随对话或 Agent 循环的轮次逐轮上涨。

Messages API 是无状态的，每次请求都要重发完整历史。每一轮新对话都要为之前所有轮次再付一次钱，因此如果不干预，一段长对话的总成本会远快于轮次增长。可选做法，按成本从低到高：

1. 保持历史只追加、不改写，让每一轮都能复用上一轮缓存的前缀。
2. 对已经不影响任务的旧轮次做摘要或删除。
3. 精简工具返回结果。一个把整份文件或整张网页塞进上下文的工具，会在之后每一轮都重复计费。

新模型的长上下文不再额外加价：Anthropic 说明 Claude 4.6 及之后的模型以标准价格提供完整的 100 万 token 窗口。这去掉的是价格断崖，不是成本本身，90 万 token 的请求依然要付 90 万 token 的钱。窗口被什么占满，见我们的 Claude API 上下文窗口 一文。

结构 D：工具、图片和搜索带来的额外开销

特征：输入 token 明显多于你写的文字。这是最容易被忽略的一种，因为这些 token 来自功能而不是提示词。

• 工具定义。 请求里带了 tools 时，API 会自动加入一段工具使用系统提示词。Anthropic 定价页按模型列出：tool_choice 为 auto 或 none 时，Claude Opus 5 为 286 个 token，Claude Sonnet 5 为 354 个，Claude Haiku 4.5 为 496 个，另外还要加上你发送的工具名、描述和 schema。每条路由只挂真正需要的工具。
• 图片。 Anthropic 视觉文档说明，一张图片的视觉 token 数为 ceil(宽/28) x ceil(高/28)，并按模型设上限。Claude 4.7 及之后的模型长边最高处理 2576 像素（最多 4784 个视觉 token）。Anthropic 自己给的例子是：在 Opus 5 上，一张 4K 图片每千张约 23.92 美元，而 1000x1000 的图片每千张约 6.48 美元。除非需要细节，发送前先缩小尺寸。
• 网页搜索。 Anthropic 按每 1,000 次搜索 10 美元计费，另加 token，且搜索结果会作为输入 token 留在之后的轮次里。网页抓取（web fetch）不按次收费，但抓到的页面会变成输入，Anthropic 建议用 max_content_tokens 参数设上限。

结构 E：可异步处理的批量任务

特征：没人实时等结果的大任务，比如夜间数据补全、评测和批量分类。

Anthropic 的 Batch API 对输入和输出 token 都按五成计价，定价页说明这一计价倍率可以和提示词缓存叠加。代价是延迟。处理时限和结果乱序问题见我们的 批处理指南。

第三步：最后再看模型选择

模型分层确实有效。按 Anthropic 价目表，Claude Haiku 4.5 每百万 token 输入 1 美元、输出 5 美元，Claude Sonnet 5 为 2 美元和 10 美元，Claude Opus 5 为 5 美元和 25 美元。Anthropic 自己的成本建议是：简单任务用 Haiku，大多数生产负载用 Sonnet，最复杂的推理用 Opus。

之所以放在最后，是因为它和上面每一项都相互影响。切换之前先核对两点：

• 分词器差异。 Anthropic 说明 Claude 4.7 及之后的模型使用新分词器，同样的文本大约多出 30% 的 token。不同分词器下的每 token 单价不能直接横比。请用 count_tokens 接口针对目标模型重新计数；Anthropic 将 token 计数列为免费，但有单独的速率限制。
• 隐藏倍率。 在 Claude 4.6 及之后的模型上把 inference_geo 固定为 "us" 会乘以 1.1 倍；Opus 5 的快速模式按每百万 token 输入 10 美元、输出 50 美元计费。两者都是正当选择，只要确认是有意为之。

如果还在比较不同服务商，我们的 Claude 与 GPT API 对比 讲了价格之外的接入差异。

Claude API 成本优化速查表

每次只改一个手段，对比改动前后各一天的 usage。同时叠三项改动，就无法判断是哪一项起了作用，或者哪一项悄悄拉低了质量。

如果测量时用的是流式响应，注意最终的 usage 数字在 message_delta 事件里，而且是累计值，具体读法见我们的 流式输出指南。想先跑通一个可用的请求来做对照，可参考 Claude API 怎么用。

常见问题

降低 Claude API 成本最快的办法是什么？

先在 usage 数据里找到占大头的桶。输出为主就调低 effort 并要求更短的回答；稳定提示词为主就开启提示词缓存。手段用错了桶，省不了多少。

调低 max_tokens 能降低 Claude API 成本吗？

不能直接降低。计费按实际生成的 token，max_tokens 只是上限。设得太低会截断回答，往往导致重试，反而更贵。

提示词缓存和 Batch API 可以一起用吗？

可以。Anthropic 定价页说明提示词缓存的倍率可以与 Batch API 的计价叠加，带缓存前缀的批处理请求两者都能享受。

换成同价位的新 Claude 模型后账单为什么变高了？

Anthropic 说明 Claude 4.7 及之后的模型使用新分词器，同样的文本大约多出 30% 的 token。比较成本之前，先用 count_tokens 针对新模型重新计数。