在 Claude Code 里折腾了大半年最近终于把“Token 成本”这笔账算明白了。事情起因是这样的我负责的一个内部工具群原先一直用 Claude API 跑代码审查和文档生成每个月账单挺稳定。但某个季度突然涨了 40%查了半天发现不是用量爆了而是 Anthropic 在一年内调了三次价——输出 token 的单价涨了缓存读取的价格也改过。团队里没人专门盯这个账单飘了都没发现。后来我把过去一年的账单、日志、Token 用量全部拉出来做了个分析顺便把所有模型的定价矩阵整理成表格再结合不同场景的 Token 消耗特征做了一套“模型选型 成本预估”的流程。这套东西现在成了我们内部上 Claude API 前的必修课。这篇文章就把这套分析方法完整写出来怎么看懂 Claude 的定价结构、怎么统计真实 Token 用量、怎么用成本数据反推模型选型以及我踩过的坑。1. 先看懂 Claude API 的定价结构再谈省钱1.1 价格变动的核心维度不是只有“输入/输出”两个数字很多教程讲到 Claude 定价就只列两个数字输入多少钱、输出多少钱。实际上从 2024 年到 2025 年Anthropic 的定价体系已经扩展成了一张多维矩阵至少包含以下几个维度输入 Token 价格每百万 Token 多少钱输出 Token 价格每百万 Token 多少钱缓存读取价格命中缓存后读取每百万 Token 多少钱缓存写入价格写入缓存时每百万 Token 多少钱批量 API 价格使用 Batch API 时输入和输出各打几折不同模型的差异Haiku、Sonnet、Opus 各自价格不同且调整幅度也不同问题就出在这里。如果你只盯着“输入价格”做预算很容易漏掉输出 Token 的涨价——而大多数实际业务场景里输出 Token 的成本占比往往超过 60%甚至达到 80%。我见过最夸张的一次某个会话式的应用输出 Token 占总费用的 85%因为模型每次都要生成一大段结构化 JSON 返回给前端。1.2 为什么一年会调三次价背后是什么逻辑Anthropic 调价的节奏其实和 GPU 供给、模型架构升级、推理优化进度都挂钩。具体来说模型迭代新版本推理效率更高单位成本下降于是会降价但如果新版本能力更强也可能小幅涨价缓存策略调整引入 Prompt Caching 后缓存读取价格远低于普通输入价格这是为了鼓励开发者复用长上下文市场策略为了让 Haiku 占据轻量场景、Opus 占据高端场景两者之间的差价一直在拉大说白了这就是一个跟随供需和推理成本动态调整的过程。作为开发者不能假设价格是静态的每个月花十分钟看一眼定价页比年底看到账单再惊讶要划算得多。1.3 把价格矩阵做成自己的“速查表”我整理了一份常用模型的价格速查表基于我最近一次核对的数据具体请以官方定价页为准覆盖了主力模型的关键价格模型输入$/百万 Token输出$/百万 Token缓存读取$/百万 Token缓存写入$/百万 Token备注Claude Haiku较低较低约为输入价的 10%比输入价高 25% 左右适合简单分类、提取Claude Sonnet中等中等约为输入价的 10%比输入价高 25% 左右性价比主力适合多数任务Claude Opus最高最高约为输入价的 10%比输入价高 25% 左右适合复杂推理、长文档分析这张表真正的价值不在那几个价格数字而在于它提醒了我几个重要事实缓存读取价格远低于普通输入价格意味着高命中率的场景成本可以大幅下降缓存写入价格反而比普通输入贵意味着频繁写入长上下文、但命中率不高的场景成本可能会悄悄上升输出价格普遍比输入贵很多因此控制输出长度比压缩输入更有效提示价格调整时先更新你的速查表再调整模型选型。不要依赖记忆不要依赖几个月前的截图。2. 用量分析是关键中的关键先搞清楚 Token 都花在哪里2.1 三个核心指标Prompt Token、Completion Token、缓存命中率做成本分析首先要建立一套统一的统计口径。我团队内部固定用三个指标所有业务线汇报都必须统一Prompt Token输入 Token每次请求发送给模型的文本总量包括 System Prompt、历史消息、工具定义、用户输入等所有内容。Completion Token输出 Token模型生成的回复总量。这里要注意流式输出时如果你在第一次返回时就停止生成可能仍然会计费具体看 API 行为所以“生成长度”尽量在请求参数中明确限制。缓存命中率命中了缓存读到的 Token 数量占全部输入 Token 的比例。这个数字直接决定你实际付的输入单价是多少。我记得有一次排查成本发现某个服务输入 Token 量巨大但费用没想象中高因为大量长文档都命中了缓存实际计费的是缓存读取价而不是原始输入价。这个案例让我意识到光看总量没用关键要看“计费口径”下的有效量。2.2 我如何统计真实 Token 用量日志落库 定时聚合刚开始我是靠 Cloudflare 或者网关日志看的后来发现这种方式口径混乱因为日志里的 Token 数字和账单上的数字经常对不上。最终我改成这样一套流程第一在业务代码里每次调用 Claude API 后把请求和响应的 Token 使用情况完整记录下来。Anthropic SDK 返回的响应里通常带有 Token 计数字段包括输入 Token、输出 Token有时还有缓存相关字段全部落到数据库。第二按小时/天/月做聚合维度包括业务线、模型、接口类型、Prompt 来源、是否命中缓存。第三和官方账单做交叉核对。如果差异超过 5%说明有统计口径问题需要排查是否漏记了流式请求、重试请求或者异步任务。下面是我在 Python 里记录关键字段的一个简化示例# 以 Anthropic SDK 为例记录每次请求的 Token 用量 def log_usage(api_response, projectdefault, modelclaude-sonnet): usage api_response.usage log_entry { project: project, model: model, prompt_tokens: usage.input_tokens, completion_tokens: usage.output_tokens, cache_creation_input_tokens: usage.cache_creation_input_tokens, cache_read_input_tokens: usage.cache_read_input_tokens, created_at: datetime.utcnow().isoformat(), } insert_usage_log(log_entry)这里有个细节缓存字段不是每次都有的有些接口版本叫法也不一样有的叫cache_creation_input_tokens有的叫cache_read_input_tokens所以写日志时建议统一用英文原始字段名避免后续聚合时空指针。2.3 不同业务场景的 Token 消耗画像同样一个模型不同用法下 Token 的花费结构完全不同。我把我们这边的场景分成了三类模板大家可以对比一下第一类对话/客服场景。特点是输入输出相当上下文会持续累积。往往一开始便宜聊得越久历史消息越多输入 Token 不断上涨。如果不用缓存成本会随时间线性增长甚至超线性增长。这种场景适合启用 Prompt Caching把系统提示词和固定前置内容缓存住。第二类代码生成/文件改写场景。特点是输入通常可控输出可能很长。比如让模型生成一个 500 行的配置文件输出 Token 轻松破万。这种场景要重点控制输出长度或者用结构化输出避免生成无意义的解释文本。第三类文档总结/知识库问答场景。特点是输入极大输出较短。每次请求可能塞进几十万字模型只回几百字。这种场景对输入价格极度敏感凡是能缓存的长文档都建议缓存否则费用会非常吓人。这三类场景的成本优化方向完全不同。对话场景优先调缓存代码场景优先调输出长度文档场景优先调输入压缩和缓存。一套方案无法打天下一定要先给场景分类再算费用。3. 模型选型用成本画像反向决定用哪个模型3.1 先别问“哪个模型最强”先问“哪个模型最划算”我见过很多团队一上来就选 Opus理由是“效果最好”。结果过了一个月发现费用根本扛不住再切回 Sonnet又发现提示词要重新调。其实正确的顺序应该是第一步明确任务的复杂度。如果一个任务用 Sonnet 能完成 90 分用 Opus 可能只能到 95 分那要慎重考虑这 5 分是否值 3 倍以上的价格。第二步做成本预估。把你预估的月请求量 × 平均输入 Token × 输入单价 月请求量 × 平均输出 Token × 输出单价算出一个粗略月费。这一步能筛掉大部分不合理的选型。第三步跑小流量实验。用真实任务跑到 1000 次以上统计实际 Token 消耗分布再对照价格速查表修正选型。我自己在内部常用一个简化公式做预估月成本 ≈ Q × (P_input × T_input P_output × T_output)其中 Q 是月请求量P_input 和 P_output 是单价T_input 和 T_output 是单次平均 Token 数。如果启用了缓存T_input 要拆成两部分命中的部分按缓存读取价算未命中的部分按普通输入价算。3.2 主力场景Sonnet 确实是性价比之王但别忽略 Haiku以我们实际经验来看Sonnet 在绝大多数“日常任务”里是性价比最稳的选择。无论是代码解释、文档分析、中等复杂度的结构化输出它都表现不错。而 Haiku 适合那些“量大但简单”的任务比如说简单文本分类判断是否是垃圾邮件/是否涉及某个主题实体提取从短文本中抽取名字、日期、地点格式转换把用户输入转成标准 JSON但不要复杂推理大量小请求的批量处理如果只算单个请求Haiku 和 Sonnet 的差价可能只有零点几美元但一旦乘上百万级请求量差价就很可观。我做过一次对比实验在同样的任务集上Haiku 的成本只有 Sonnet 的 1/4 左右但准确率下降了约 3 个百分点。对于很多业务来说这 3 个百分点是可以接受的优化空间。注意Haiku 上下文长度和处理能力有限千万不要把复杂推理任务强行塞给 Haiku。我踩过这个坑任务复杂到一定程度Haiku 会开始输出残缺 JSON反复重试反而更贵。3.3 什么时候才需要上 OpusOpus 适合的场景我理解是两类一类是高风险决策辅助比如合同条款审查、代码安全审计、复杂的多步骤推理。这类场景出错代价远高于模型调用成本。另一类是长文本深度分析比如让模型在一个超大代码库里找潜在 bug。这种任务需要极强的上下文理解能力Sonnet 明显顶不住。这里也要提醒一句不要盲信 Opus 的“天花板能力”。如果任务本身信息量不足、提示词写得稀烂换哪个模型都白搭。先用低成本的模型把提示词调顺再上高价模型做最终效果验证这样烧的钱最少。3.4 混用多模型一种更高级的省钱套路把不同任务分给不同模型链路内部甚至可以把同一个任务拆开处理。我举个我们实际做过的例子一个用户问题进来先让 Haiku 做意图分类成本极低判断是简单问答还是复杂分析。如果是简单问答直接由 Haiku 或者预设的答案模板返回如果是复杂分析再升级给 Sonnet 处理。这样整体成本比全部用 Sonnet 节省了 60% 以上而用户体验几乎没变。这就是所谓的“路由策略”本质上是用少量 Haiku 调用来换取大量 Sonnet/Opus 调用成本的压缩。后续如果你想更自动化可以引入规则或小模型来做路由但初期用 Haiku 已经足够了。4. 成本优化的实操手段缓存、批量、输出压缩4.1 缓存最有效的省钱手段但要会设置Claude 的 Prompt Caching 机制简单说就是把一段固定的长文本预先缓存后续请求只要命中就能按极低价格收费。它适合的场景系统提示词很长、且每次请求都相同或相似。我举一个知识库问答的例子系统提示词有 2000 Token每次请求都附带历史消息累积到 5000 Token用户新问题约 200 Token如果不启用缓存每次请求输入就是 7200 Token全价计费。启用缓存后系统提示词和重复的历史前缀可以命中缓存每次实际新增计费的是用户问题那 200 Token 加上少量未命中部分。成本差距非常可观。但是缓存并不是开了就省钱有几个注意点缓存写入价比普通输入价贵。如果一段文本只被请求一次写入缓存反而亏钱。所以缓存只适合高频复用的固定内容缓存有 TTL存活时间。超过一定时间没被访问缓存会失效下次要重新写入。如果你的请求频率不够高缓存命中率会很低不同模型/不同版本缓存的粒度可能不同。建议以官方文档为准调试时可以用响应里的命中 Token 数字来验证我在内部做成本报告时会把“缓存命中率”作为一个关键 KPI。命中率低于 50% 的场景我会去查是不是日志里出现了大量未命中的长前缀请求然后针对性地优化。4.2 批量处理把非实时任务丢给 Batch APIClaude 的 Batch API 允许把大量请求打包发送价格大约是实时 API 的 50%具体折扣以官方为准适合离线处理、定时任务、批量生成。我这边有几个场景非常适合 Batch API批量总结历史工单批量生成商品描述批量把旧数据转换成结构化格式这些任务不需要实时返回晚几分钟甚至几小时完成都无所谓但请求量巨大、Token 消耗高用 Batch API 能省下一大笔费用。Batch API 的使用也有一点坑批量任务的排队时间不稳定高峰期可能要等较长时间。所以设计时一定要做好时间预算不要把实时接口的请求也塞进 Batch。4.3 输出压缩与结构化输出控制 Completion Token前面说了输出 Token 通常是成本大头。控制输出长度有三个思路第一用限制参数比如max_tokens。别让它无限制地生成下去尤其是流式输出时用户一旦满足了就可以中断但计费可能已经发生了所以更安全的做法是在请求层就设置上限。第二用结构化输出要求模型严格返回 JSON 或 XML不要附带解释。如果你只想要一个结果就明确告诉模型“只返回结果不要任何解释文字”。我试过同样一个任务加了这句提示词之后输出 Token 减少了 40%。第三用后处理让模型输出精简摘要而不是全文。有些场景不需要完整输出可以先让 Haiku 做一次摘要再传递给 Sonnet 做后续分析这样整体 Token 花费可能更低。下面是我在代码中限制输出的一个简单示例response client.messages.create( modelclaude-sonnet-4-20250514, max_tokens512, # 强制限制输出长度 messages[ {role: user, content: 请返回一个 JSON包含字段 name、summary、priority不要输出任何解释文字。} ], system你是严格的 JSON 生成器。 )4.4 错误重试与超时隐藏的成本刺客这个坑我发现很久了因为它在账单上不显眼但在日志里非常明显。Claude API 偶尔会报connection dropped或者connection lost mid-response尤其是在长输出、网络不稳定的时候。如果代码里没有完善的超时和重试策略一旦连接中断可能需要重新发送整个请求Token 就会双重计费。我的做法是设置合理的超时时间比如 30 秒到 60 秒取决于任务复杂度只在明确知道请求未到达服务端时才重试例如连接错误可以在写请求阶段重试但一旦服务端开始返回响应就谨慎重试对于长输出任务优先使用流式接口并做断点续跑避免重头再来还有一点要注意重试时如果提示词里有时间戳或者随机数会导致缓存命中率下降。我曾经排查过一个现象同一批请求缓存命中率突然骤降后来发现是某个同事在提示词里加了当前时间戳导致每次提示词都不同缓存全部失效。这个案例非常典型。5. 常见问题与排查技巧从 Token 报错到成本异常5.1 认证与地区限制403 Forbidden 是很多人碰到的第一堵墙在 Claude API 的接入过程中token exchange failed: token endpoint returned status 403 forbidden: country这类报错非常常见。它的本质是当前网络出口 IP 所在地区不在服务允许范围内认证服务器直接拒绝了 Exchange 请求。排查思路很简单先确认你所在地是否在 Anthropic 支持的服务范围内再确认 API Key 本身有效。有时候是 Key 过期、被撤销或者权限不足如果代码里有多个环境变量检查是否混用了老 Key 和新 Key用 curl 直接调用认证接口绕开本地代码看返回信息是什么我一个朋友的公司从海外节点迁移后几个月没管突然发现所有请求都 403 了。排查到最后发现是网络出口节点被服务商调整了换了一个不被支持的地区。所以遇到 403先看出口 IP再看 Key不要一上来就改代码。注意这里不讨论任何绕过地区限制的方案。正确做法是确保你的部署环境位于服务商支持的区域或者选择适合你所在区域的合规服务。5.2 登录态与 Token 刷新Access Token 失效的连锁反应日志里常见的your access token could not be refreshed、failed to refresh token: 400 bad request这类报错大多和登录态过期、refresh token 失效有关。如果你在代码里硬编码了一个 Access Token它过期后自然全部请求失效。我建议统一用一个 Token 管理模块专门负责获取、刷新和缓存 Access Token并且做好以下处理刷新 Token 失败时自动触发重新登录流程Access Token 提前预刷新避免请求时才去拿 Token 导致延迟所有请求统一从 Token 管理器获取 Token不要散落在业务代码里我也见过不少开发者把 Token 写进配置文件、提交到 Git结果被扫描工具扒出来盗刷。这里强烈建议用密钥管理系统至少也要用环境变量不要提交到仓库。5.3 成本异常飞涨三个排查方向如果某个月的成本突然暴涨我通常按以下顺序排查第一看调用量是否异常。有没有新的定时任务在循环调用有没有代码里不小心把调用写进了一个高频循环有没有用户端触发了一个死循环重试第二看单次调用 Token 是否异常。同一类任务平均输出 Token 是不是比之前大了几倍是不是有模型升级后输出风格变了开始大量输出解释文本第三看缓存命中率是否下降。如果之前命中率高现在跌到 30% 以下那输入费用会成倍上涨。重点检查提示词是否每次都在变。我曾经排查过一个项目费用连续两天翻倍最后发现是有人在代码里给所有消息都加了一个随机request_id放进提示词里导致缓存完全失效。去掉之后成本立刻回落。这种问题如果不看日志光看账单根本找不到原因。5.4 如何快速判断某个模型是否适合你的业务如果你不想做太复杂的分析可以做一个简单的“三问测试”第一问这个任务需要多少上下文如果每次要带上万字以上的文档那最好选支持长上下文的模型并且打开缓存。第二问这个任务允许延时吗如果允许用 Batch API 降低成本如果必须实时那就老老实实用实时接口。第三问这个任务结果的价值是否高于调用成本一个内部工具调用 Opus 的成本比这笔业务本身盈利还高那肯定要降级或换模型。这三个问题都答清楚后你的选型基本不会太偏。6. 我最终沉淀下来的“成本分析五步法”做完这一整套分析之后我把方法沉淀成了五个步骤现在每次新业务接入 Claude API我都会让团队先走一遍第一步定义任务画像。明确任务的复杂度、实时性要求、输入输出规模、调用频率。第二步选择候选模型。根据任务画像圈定 2 到 3 个候选模型不要一上来就锁定最贵的。第三步估算成本区间。用价格速查表和预估 Token 量算出月成本区间。如果超出预算直接调整选型方向。第四步小流量实验验证。跑 1000 次真实请求统计实际 Token 分布、缓存命中率、失败率、输出质量。这里的核心指标是“每个有效结果的实际成本”。第五步上线后持续监控。每周核对一次账单与日志发现成本波动超过 10% 就自动告警。推荐在日志系统里建立 Token 消费看板按业务线、模型、场景三个维度展示。这套流程看起来麻烦但实际跑通之后新业务的成本预估时间可以从几天压缩到半天以内。关键是我们团队再也没有出现过“账单翻倍才知道模型选错”的情况。我自己最大的感受是Claude API 的定价是动态的、多维度的你不能指望一年前算好的成本结构继续成立。每次模型发布、每次价格调整都要回头重新算一遍。与其焦虑价格变动不如把分析方法固化下来让每一次调整都有据可依。最后再分享一个小技巧我们在每次价格调整后都会把所有已上线任务的日志重新跑一遍成本模拟用新价格算一次看哪些业务受影响最大然后优先优化那些受影响最严重的场景。这个“旧用量 × 新价格”的模拟方法让我们在价格变动后总能第一时间做出响应而不是等月底账单出来才发现问题。如果你也在用 Claude API或者正准备接入希望这套分析思路能帮你少走一些弯路。价格会变但分析的方法论不会过时。