上个月收到 Claude API 账单的时候我盯着那一串数字看了好几分钟心里只有一个念头这真的是我这个月跑出来的量吗明明感觉没怎么用为什么金额比预期高出一大截。后来我花了一个下午把账单里的每一项费用、每一个 token 的去向全部拆开核对了一遍才发现问题不在用量太多而在我根本不知道账单上的数字是怎么算出来的。Claude API 的计费逻辑并不复杂但它和传统的服务器账单完全是两种思维——不是按请求次数、不是按时间而是按 token 这种看不见摸不着的东西计费再加上缓存、多轮对话、长上下文这些概念账单会越来越难懂。这篇文章我就用自己踩过坑之后整理出来的方法分三步把 Claude API 的用量和成本彻底拆明白。不管你是刚接 API 做小工具还是已经在跑自动化脚本、做产品原型这套账单自检的方法都能直接拿来用至少能帮你省下比预期多 20% 到 30% 的冤枉钱。1. 为什么一张 Claude API 账单能让人看懵1.1 账单上十几个费用项每一行都不是请求数很多人第一次打开 Anthropic 控制台的账单页面第一反应都是完了这是不是被盗刷了其实不是你被刷了而是大模型账单天生就长这样。普通服务器的账单很好懂一台实例跑多少小时每小时的单价是多少再加带宽流量乘以单价就是总价。但 Claude API 的账单是按 token 计费的而一次 API 调用会同时产生输入 token和输出 token两类费用有的场景下还会出现缓存写入缓存读取这种附加费用项。也就是说你发一条很短的请求账单上也可能同时出现好几行费用分别对应不同的模型、不同的用量口径。我见过最极端的情况是一个小型自动化脚本一天才跑几十次请求但账单上列了六七个费用项。逐行看过去里面有一笔输入费用对应的是超长的 system prompt有一笔是输出费用还有好几笔缓存写入。如果不逐项拆开根本不知道钱到底花在了哪个环节。所以第一步不是急着优化成本而是先搞清楚账单上那些费用项各自代表什么。只有先看懂账单的构成后面谈省钱才有意义。1.2 按 token 计费和按资源计费是两种完全不同的思维要理解 Claude API 账单必须先理解大模型为什么按 token 收费。你可以把 token 简单理解成模型读一段文字时切出来的最小内容块。英文里一个单词通常等于一个 token中文里一个汉字可能是 0.5 到 1 个 token代码里的符号、空格也都要算 token。模型每一次生成内容本质上都是在预测下一个 token 是什么所以输入内容的长度、输出内容的长度直接决定了模型需要做多少计算自然也就决定了成本。这和服务器按小时收费完全不同。服务器你买的是固定资源就算跑不满 CPU钱也要照付。而 Claude API 是按实际消耗计费用多少 token 收多少钱理论上不用的时间不花钱。听起来很合理对吧问题在于token 的量非常容易被低估。我给你举个具体例子。假设你的 system prompt 有 2000 个 token每次用户提问输入 500 个 token那么一次对话请求的输入就是 2500 个 token。如果你做一个多轮对话工具用户连续聊 20 轮每轮的对话历史都会原样带上第 20 轮时你的输入可能已经膨胀到 12000 个 token。用户只看到了 20 条消息但实际上模型每轮都在重读前面全部内容每一轮都在收费。所以在理解 Claude API 成本这件事上我建议彻底忘掉请求次数这个概念把所有注意力放在每一轮请求实际携带了多少 token上。这也是看懂账单、拆解成本的核心思维转变。2. 第一步先把账单里的费用公式吃透2.1 token 是怎么算的输入和输出凭什么分开计价我在排查账单的过程中意识到一个问题很多人不是不会看金额而是不知道输入 token和输出 token是两套完全不同的价格费用公式也截然不同。Claude API 的定价逻辑是输入和输出分开计价。输入 token 的价格远低于输出 token因为模型读内容比写内容要省计算资源。以目前常见的 Sonnet 级别模型为例输入价格大约是每百万 token 几美元而输出价格往往是输入的 4 到 5 倍。这类价格细节官网随时可能调整你不用记死但要记住输出比输入贵得多这个结构性差异。这就导致一个非常关键的推论你想省成本最优先优化的不是减少用户发了多少字而是减少模型输出了多少字。同样一万美元输入可以支撑极大流量但输出稍微一多账单就会迅速拉升。我见过一个典型的输出失控案例一个自动生成周报的脚本每次都让模型输出完整 HTML 页面一次输出就有 8000 多 token。单价一乘单次成本直接拉高好几倍。后来把输出格式改成纯文字、限制 max_tokens单次成本下降超过一半。这个优化做起来极其简单但能产生立竿见影的效果。2.2 用输入 输出 缓存三个口径重新计算每一笔费用当你把一次 API 请求的所有费用项列出来你会发现实际构成比输入 输出还要多一样东西缓存。Anthropic 引入了 prompt caching 机制意思是如果你在短时间内反复使用同一段上下文比如同一个 system prompt、同一份长文档第一次请求会把这段内容写入缓存后续请求直接从缓存读取读取的单价会便宜很多。但注意缓存写入的价格通常比普通输入还要贵一点它本质上是用第一次的高成本换取后续的低成本。所以在账单上你会看到三类输入相关费用费用项计费含义价格水平相对普通输入标准输入每次请求从零开始读入的 token基准价缓存写入首次把内容存入缓存比基准价高一点缓存读取后续请求命中缓存读取内容比基准价低很多这就解释了为什么一张账单上同一类模型的费用被拆成好几行。不是平台故意把账单做复杂而是这几种 token 的计算成本确实不同。我用了一个很笨但有效的方法来核对每次请求的 response 里其实会返回 usage 字段里面精确告诉你这次请求有多少 input_tokens、output_tokens、cache_creation_input_tokens 和 cache_read_input_tokens。把一天的所有请求日志拉出来按这四个字段汇总再分别乘以对应的单价就能算出理论上应该扣多少钱然后和账单比对。这一步做下来绝大多数账单金额和预期不符的问题都能找到答案。要么是你没算缓存费用要么是你把输出 token 当成了输入 token 的价格来估算。2.3 用实际账单金额反推 token 数量的演算过程光说概念不够我拿一个实际演算的例子来说明。假设你某个月用 Sonnet 级别模型账单里标准输入这一项是 90 美元。按输入单价约 3 美元/百万 token 估算那么标准输入的总 token 量大约是90 ÷ 3 × 1000000 30000000也就是 3000 万输入 token。如果同一个月输出这一项是 150 美元按输出单价约 15 美元/百万 token 估算那么输出总 token 量就是150 ÷ 15 × 1000000 10000000也就是 1000 万输出 token。看到这组数字你可能立刻会意识到一个问题输出 token 虽然只有输入的三分之一但花的钱反而更多。这就是输出单价高的直接体现也是后面做优化的最核心抓手。当然反推 token 数量只是一个估算手段因为实际价格可能因为我用的模型版本、是否开启缓存、是否是企业合同等因素发生变化。但它能帮你快速建立账单金额 ↔ 实际用量之间的对应关系让你知道这个月的钱到底对应于多大的工作负载。否则你只知道花了 240 美元却完全不知道这 240 美元是 3000 万输入还是 1000 万输出后续就没法优化。3. 第二步让数据自己说话从账单倒推用量3.1 把账单金额翻译成 token 数量建立自己的用量基线在拆成本这件事上感觉永远不可靠必须落到数字上。我的做法是每个月固定花十分钟把上一个月的账单翻译成token 台账。台账里至少要有这几列模型名称、标准输入 token、缓存写入 token、缓存读取 token、输出 token、对应金额、估算出的平均单次请求 token 数。有了这份台账你就能回答三个关键问题这个月主要成本集中在哪个模型输入和输出哪个占比高单次请求的 token 规模是几百还是上万我自己做了三个月的台账之后发现一个非常有意思的规律多数项目的成本大头根本不在用户输入而在系统提示词 对话历史这种每次请求都要携带的固定内容上。换句话说钱不是在回答问题上烧掉的而是在重读上烧掉的。这个洞察直接改变了我后续的设计思路凡是固定不变的 system prompt全部拆出来做缓存让后续请求以极低的缓存读取价格读到它凡是历史对话只保留最近几轮而不是全部原样传给模型。这两步操作做下来成本曲线的变化非常明显。3.2 用日志里的 usage 字段做精准核对而不是只看账单总额账单上的金额是平台核算的结果它本身没有问题但要核对自己应该花多少最好还是从请求日志入手。因为只有日志能告诉你每一笔请求到底消耗了多少 token。Claude API 的响应体里自带 usage 字段通常包含这几个值输入 token、输出 token、缓存创建 token、缓存读取 token。我在自己的项目里加了一段很简单的逻辑把每次请求的 model、usage、timestamp 写入本地日志文件一行一个 JSON。这样月底统计的时候我根本不用去看账单直接统计日志就能算出理论上应该产生多少费用。有人可能会问日志统计和账单谁会准我的经验是大部分情况下两者会非常接近但账单里可能包含一些你日志里看不到的项目比如 API 请求失败但仍然产生了部分计算、或者平台内部的数据处理费用。所以我的建议是以账单总额为准以日志统计为佐证。两者差异超过 5% 时再回头排查是否有重复请求、超时重试、或者漏记的缓存消耗。3.3 一条命令搞定月度用量汇总附简单的统计脚本思路日志如果只是堆在那里不统计等于白记。我分享一个特别简单的统计思路用 Python 就能跑不需要任何额外依赖。假设日志文件里每一行都是类似这样的 JSON{model: claude-sonnet-4, input_tokens: 1200, output_tokens: 300, cache_creation_input_tokens: 0, cache_read_input_tokens: 5000, timestamp: 2025-06-01T10:00:00Z}统计脚本的核心逻辑就是按模型分组把四个 token 字段分别求和再乘上对应的单价。伪代码大概长这样import json from collections import defaultdict totals defaultdict(lambda: { input: 0, output: 0, cache_write: 0, cache_read: 0 }) with open(api_log.jsonl, r) as f: for line in f: try: item json.loads(line.strip()) except json.JSONDecodeError: continue model item.get(model, unknown) totals[model][input] item.get(input_tokens, 0) totals[model][output] item.get(output_tokens, 0) totals[model][cache_write] item.get(cache_creation_input_tokens, 0) totals[model][cache_read] item.get(cache_read_input_tokens, 0) for model, t in totals.items(): print(model, t)拿到汇总结果后再对照单价表手动加一个估算费用列。这一步不需要很精确够用来判断哪个模型最烧钱、哪类 token 占比最大就足够了。当然如果你不想自己搭这套统计逻辑Anthropic 控制台的 Usage 页面本身也能看到各模型的 token 消耗只是颗粒度没有日志那么细。我个人的习惯是两边都看控制台看趋势日志看细节。4. 第三步揪出四类隐形烧钱点4.1 长上下文是最大的成本放大器如果只能选一个成本黑洞来排查我建议优先查长上下文。因为它的放大效应实在惊人。很多项目的对话历史是无限累积的——每轮对话结束后把所有历史记录原样拼进下一次请求。我见过一个客服机器人原型会话刚开始时每请求只有 1500 token但用户聊到第 30 轮时单次请求的输入已经超过 20000 token。你以为用户只是问了 30 个问题实际上模型每次都要重新读完前面所有内容光读历史这件事就把成本放大了十几倍。这里有个特别容易踩的坑很多人觉得上下文越长回答质量越好于是无脑把所有历史都传给模型。但实测下来绝大多数任务根本不需要那么长的历史。我的经验是先看任务类型如果是问答保留最近 5 到 10 轮对话基本就够如果是文档分析把文档内容做成缓存而不是每轮重复传效果更好成本也更低。4.2 缓存读写既是省钱利器也是烧钱陷阱前面说过缓存读写有两面性用好了能大幅降低成本用不好反而会多花钱。先讲用得好的场景。假设你的应用有一个 5000 token 的固定 system prompt每次请求都原样带上按标准输入价格计算一天 10000 次请求光这一项就是5000 × 10000 50000000也就是 5000 万 token 的输入。如果每次都按标准输入价格收费这笔费用相当可观。但如果你启用了缓存第一次请求写入缓存写入价格略高后续 9999 次请求都走缓存读取价格比标准输入便宜得多总费用会显著下降。这就是缓存存在的意义。再讲陷阱场景。缓存不是自动生效的需要你在请求参数里显式指定 cache_control而且缓存的 key 是请求中的 prefix 内容只要前缀有任何一点变化缓存就可能失效重新走缓存写入流程。我遇到过一种情况system prompt 里拼接了一个动态时间戳结果每次请求的 prefix 都不一样缓存永远不命中而缓存写入的价格又高于标准输入最后账单比不开缓存时还贵。所以我的建议是启缓存之前先确认你放在缓存里的内容确实是完全不变的。任何动态内容时间、随机 ID、用户特定字段都不要放进 prefix否则缓存反而会成为烧钱陷阱。4.3 多轮对话、工具调用与失败重试的叠加效应长上下文的放大很多时候不是单次请求造成的而是多轮叠加造成的。成本最高的往往不是某一个长请求而是大量互相叠加的请求序列。举一个真实场景你在做 agent 类应用模型会调用工具。工具调用的机制是模型先生成一段工具调用指令然后你把工具结果返回给它它再继续生成下一步。一次看似简单的任务可能触发 3 到 5 次 API 往返。每一次往返都要把前面的全部对话历史重新带上token 量随着步骤增长。如果这中间某一步因为超时或网络抖动失败你又做了重试那失败的那一次请求费用可能已经产生了。更麻烦的是重试请求会把同一段历史重新计费一次成本直接翻倍。我把这类问题总结成一个公式总成本 ≈ 单次请求 token 数 × 请求次数 × 平均重试系数 × 单价。四个变量里任何一个失控账单都会很难看。通常大家只会关注单次 token 数和单价却忽略了请求次数和重试系数。优化的时候我会建议先把请求次数和重试次数降下来因为这两项往往比省几个 token 更有效。4.4 优化前后对比一个小项目省掉 60% 成本的例子理论讲再多不如一个具体例子直观。我手上有一个文档摘要小工具最初版本的成本结构是这样的成本项优化前优化后每次请求输入 token12000含完整文档 历史3000文档走缓存读取每任务请求次数5 次多轮工具调用3 次输出 token80003000单任务估算成本基准约为基准的 40%优化动作其实只有三个。第一把 8000 token 的原始文档从每次直接传改成缓存读取单次请求的输入费用大幅下降第二把工具调用链路从 5 步精简到 3 步减少无效往返第三把输出格式从详细报告改成简洁摘要并设置 max_tokens 上限防止模型话痨。三个动作叠加单任务成本直接降到原来的四成。而且优化之后因为请求更短、步骤更少响应速度也变快了。这算是省成本同时提升体验的好案例。我把优化优先级排个序供你参考优先压输出 token——输出单价最贵限制长度、精简格式立竿见影。其次压请求次数——减少工具调用轮次、合并能合并的请求。再考虑缓存——它能解决固定超大上下文的高频读取问题但要注意缓存命中率。最后才是压输入 token——比如精简 system prompt、控制对话历史轮数。5. 常见问题排查对不上账、报错与成本的关系5.1 为什么我算出来的费用和账单金额差一截这是我被问得最多的问题没有之一。用户按输入 token 单价 输出 token 单价算了一个数结果账单金额比这个数高于是怀疑是不是被多扣费了。我第一反应通常是你是不是忘了缓存费用很多人对缓存只有一个模糊概念不知道缓存写入价格比标准输入还贵。当你某个请求动态拼接了内容导致缓存反复写入时费用会在你完全没察觉的情况下溜走。第二个常见原因是账单里某个请求的输入 token 数量和你以为的数量不一样。举个例子你在控制台测试时输入显示 500 token但你的代码里实际拼接了工具返回结果、对话历史一次请求的真实输入可能是 3000 token。你按 500 估算自然对不上。第三个原因更隐蔽失败或超时的请求也可能计入费用。特别是请求已经到达服务端、模型开始生成后才中断的情况已经产生的输出 token 依然会计费。这也是日志统计和账单产生差异的主要原因之一。5.2 400 和 429 这类报错和账单有什么关系在排查成本的过程中你会不可避免地和各种 API 报错打交道。常见的 400 错误是请求参数有问题比如模型名不支持、context 超过上限。这类报错通常在请求进入模型推理之前就被拦截一般不会产生费用但会浪费你的开发时间和排查成本。和钱更相关的是 429 这类限流错误。比如请求过于频繁触发配额限制提示exceeded usage quota。这里有个容易忽略的点限流是在请求被接受并开始计算之后才可能发生的某些情况下被限流的请求也可能已经消耗了部分计算资源。我在自检时遇到过一种情况并发太高导致大量 429我以为是省钱了但实际上因为重试逻辑写得不严谨重试请求叠加了更多 token最终费用反而上升。所以我的建议是日志里不只要记录成功请求也要记录错误状态码和错误信息。尤其要关注请求失败时是否已经产生 usage——这个信息通常可以从响应头或错误详情里找到一点线索。养成记录错误日志的习惯排查对不上账的问题会快很多。5.3 月度账单自检清单我每个月都会过一遍与其每次出了问题再抢救不如固定一个自检流程。我给自己定了一个月度清单做完大概只要 20 分钟检查项检查方法正常状态账单总额是否接近日志统计日志按 usage 字段汇总与账单比对差异小于 5%是否存在异常高的缓存写入查看缓存写入 token 是否占比异常缓存写入占比小于标准输入输出 token 占比是否合理计算输出/输入比例输出费用不超过总费用的 60%单次请求平均 token 是否失控用总 token 除以请求次数多数场景应低于 5000是否有大量失败请求查看日志中的 4xx/5xx 状态码失败率低于 1%这套清单帮我在早期发现过好几次问题。印象最深的一次是我发现某个项目的缓存写入 token 占到总输入的 40%顺着日志一查发现是一段带时间戳的动态 prompt 导致缓存反复失效。改掉之后那个项目的成本立刻降了将近三成。6. 最后分享一点个人经验账单这个东西越早开始盯越好。很多人觉得等量大了再优化也不迟但大模型的费用增长是指数级的——优化动作发生得越晚你浪费的基数就越大。我第一次认真做这份账单自检时项目规模还不大但已经帮我把成本结构彻底理顺了。后来流量涨上去成本曲线依然可控靠的就是早期建立的那套看账单、对日志、查异常的循环。另外想提醒一句别过度优化。省成本的前提是不影响产品质量。我自己就试过为了压缩 token 把 system prompt 删到几乎不可用结果模型输出质量大幅下降反而要花更多时间调 prompt、加示例等于变相增加了人力成本。找到那个够用且不浪费的平衡点才是做成本管理真正的功夫所在。
Claude API 账单拆解：三步搞定 Token 用量与成本优化
上个月收到 Claude API 账单的时候我盯着那一串数字看了好几分钟心里只有一个念头这真的是我这个月跑出来的量吗明明感觉没怎么用为什么金额比预期高出一大截。后来我花了一个下午把账单里的每一项费用、每一个 token 的去向全部拆开核对了一遍才发现问题不在用量太多而在我根本不知道账单上的数字是怎么算出来的。Claude API 的计费逻辑并不复杂但它和传统的服务器账单完全是两种思维——不是按请求次数、不是按时间而是按 token 这种看不见摸不着的东西计费再加上缓存、多轮对话、长上下文这些概念账单会越来越难懂。这篇文章我就用自己踩过坑之后整理出来的方法分三步把 Claude API 的用量和成本彻底拆明白。不管你是刚接 API 做小工具还是已经在跑自动化脚本、做产品原型这套账单自检的方法都能直接拿来用至少能帮你省下比预期多 20% 到 30% 的冤枉钱。1. 为什么一张 Claude API 账单能让人看懵1.1 账单上十几个费用项每一行都不是请求数很多人第一次打开 Anthropic 控制台的账单页面第一反应都是完了这是不是被盗刷了其实不是你被刷了而是大模型账单天生就长这样。普通服务器的账单很好懂一台实例跑多少小时每小时的单价是多少再加带宽流量乘以单价就是总价。但 Claude API 的账单是按 token 计费的而一次 API 调用会同时产生输入 token和输出 token两类费用有的场景下还会出现缓存写入缓存读取这种附加费用项。也就是说你发一条很短的请求账单上也可能同时出现好几行费用分别对应不同的模型、不同的用量口径。我见过最极端的情况是一个小型自动化脚本一天才跑几十次请求但账单上列了六七个费用项。逐行看过去里面有一笔输入费用对应的是超长的 system prompt有一笔是输出费用还有好几笔缓存写入。如果不逐项拆开根本不知道钱到底花在了哪个环节。所以第一步不是急着优化成本而是先搞清楚账单上那些费用项各自代表什么。只有先看懂账单的构成后面谈省钱才有意义。1.2 按 token 计费和按资源计费是两种完全不同的思维要理解 Claude API 账单必须先理解大模型为什么按 token 收费。你可以把 token 简单理解成模型读一段文字时切出来的最小内容块。英文里一个单词通常等于一个 token中文里一个汉字可能是 0.5 到 1 个 token代码里的符号、空格也都要算 token。模型每一次生成内容本质上都是在预测下一个 token 是什么所以输入内容的长度、输出内容的长度直接决定了模型需要做多少计算自然也就决定了成本。这和服务器按小时收费完全不同。服务器你买的是固定资源就算跑不满 CPU钱也要照付。而 Claude API 是按实际消耗计费用多少 token 收多少钱理论上不用的时间不花钱。听起来很合理对吧问题在于token 的量非常容易被低估。我给你举个具体例子。假设你的 system prompt 有 2000 个 token每次用户提问输入 500 个 token那么一次对话请求的输入就是 2500 个 token。如果你做一个多轮对话工具用户连续聊 20 轮每轮的对话历史都会原样带上第 20 轮时你的输入可能已经膨胀到 12000 个 token。用户只看到了 20 条消息但实际上模型每轮都在重读前面全部内容每一轮都在收费。所以在理解 Claude API 成本这件事上我建议彻底忘掉请求次数这个概念把所有注意力放在每一轮请求实际携带了多少 token上。这也是看懂账单、拆解成本的核心思维转变。2. 第一步先把账单里的费用公式吃透2.1 token 是怎么算的输入和输出凭什么分开计价我在排查账单的过程中意识到一个问题很多人不是不会看金额而是不知道输入 token和输出 token是两套完全不同的价格费用公式也截然不同。Claude API 的定价逻辑是输入和输出分开计价。输入 token 的价格远低于输出 token因为模型读内容比写内容要省计算资源。以目前常见的 Sonnet 级别模型为例输入价格大约是每百万 token 几美元而输出价格往往是输入的 4 到 5 倍。这类价格细节官网随时可能调整你不用记死但要记住输出比输入贵得多这个结构性差异。这就导致一个非常关键的推论你想省成本最优先优化的不是减少用户发了多少字而是减少模型输出了多少字。同样一万美元输入可以支撑极大流量但输出稍微一多账单就会迅速拉升。我见过一个典型的输出失控案例一个自动生成周报的脚本每次都让模型输出完整 HTML 页面一次输出就有 8000 多 token。单价一乘单次成本直接拉高好几倍。后来把输出格式改成纯文字、限制 max_tokens单次成本下降超过一半。这个优化做起来极其简单但能产生立竿见影的效果。2.2 用输入 输出 缓存三个口径重新计算每一笔费用当你把一次 API 请求的所有费用项列出来你会发现实际构成比输入 输出还要多一样东西缓存。Anthropic 引入了 prompt caching 机制意思是如果你在短时间内反复使用同一段上下文比如同一个 system prompt、同一份长文档第一次请求会把这段内容写入缓存后续请求直接从缓存读取读取的单价会便宜很多。但注意缓存写入的价格通常比普通输入还要贵一点它本质上是用第一次的高成本换取后续的低成本。所以在账单上你会看到三类输入相关费用费用项计费含义价格水平相对普通输入标准输入每次请求从零开始读入的 token基准价缓存写入首次把内容存入缓存比基准价高一点缓存读取后续请求命中缓存读取内容比基准价低很多这就解释了为什么一张账单上同一类模型的费用被拆成好几行。不是平台故意把账单做复杂而是这几种 token 的计算成本确实不同。我用了一个很笨但有效的方法来核对每次请求的 response 里其实会返回 usage 字段里面精确告诉你这次请求有多少 input_tokens、output_tokens、cache_creation_input_tokens 和 cache_read_input_tokens。把一天的所有请求日志拉出来按这四个字段汇总再分别乘以对应的单价就能算出理论上应该扣多少钱然后和账单比对。这一步做下来绝大多数账单金额和预期不符的问题都能找到答案。要么是你没算缓存费用要么是你把输出 token 当成了输入 token 的价格来估算。2.3 用实际账单金额反推 token 数量的演算过程光说概念不够我拿一个实际演算的例子来说明。假设你某个月用 Sonnet 级别模型账单里标准输入这一项是 90 美元。按输入单价约 3 美元/百万 token 估算那么标准输入的总 token 量大约是90 ÷ 3 × 1000000 30000000也就是 3000 万输入 token。如果同一个月输出这一项是 150 美元按输出单价约 15 美元/百万 token 估算那么输出总 token 量就是150 ÷ 15 × 1000000 10000000也就是 1000 万输出 token。看到这组数字你可能立刻会意识到一个问题输出 token 虽然只有输入的三分之一但花的钱反而更多。这就是输出单价高的直接体现也是后面做优化的最核心抓手。当然反推 token 数量只是一个估算手段因为实际价格可能因为我用的模型版本、是否开启缓存、是否是企业合同等因素发生变化。但它能帮你快速建立账单金额 ↔ 实际用量之间的对应关系让你知道这个月的钱到底对应于多大的工作负载。否则你只知道花了 240 美元却完全不知道这 240 美元是 3000 万输入还是 1000 万输出后续就没法优化。3. 第二步让数据自己说话从账单倒推用量3.1 把账单金额翻译成 token 数量建立自己的用量基线在拆成本这件事上感觉永远不可靠必须落到数字上。我的做法是每个月固定花十分钟把上一个月的账单翻译成token 台账。台账里至少要有这几列模型名称、标准输入 token、缓存写入 token、缓存读取 token、输出 token、对应金额、估算出的平均单次请求 token 数。有了这份台账你就能回答三个关键问题这个月主要成本集中在哪个模型输入和输出哪个占比高单次请求的 token 规模是几百还是上万我自己做了三个月的台账之后发现一个非常有意思的规律多数项目的成本大头根本不在用户输入而在系统提示词 对话历史这种每次请求都要携带的固定内容上。换句话说钱不是在回答问题上烧掉的而是在重读上烧掉的。这个洞察直接改变了我后续的设计思路凡是固定不变的 system prompt全部拆出来做缓存让后续请求以极低的缓存读取价格读到它凡是历史对话只保留最近几轮而不是全部原样传给模型。这两步操作做下来成本曲线的变化非常明显。3.2 用日志里的 usage 字段做精准核对而不是只看账单总额账单上的金额是平台核算的结果它本身没有问题但要核对自己应该花多少最好还是从请求日志入手。因为只有日志能告诉你每一笔请求到底消耗了多少 token。Claude API 的响应体里自带 usage 字段通常包含这几个值输入 token、输出 token、缓存创建 token、缓存读取 token。我在自己的项目里加了一段很简单的逻辑把每次请求的 model、usage、timestamp 写入本地日志文件一行一个 JSON。这样月底统计的时候我根本不用去看账单直接统计日志就能算出理论上应该产生多少费用。有人可能会问日志统计和账单谁会准我的经验是大部分情况下两者会非常接近但账单里可能包含一些你日志里看不到的项目比如 API 请求失败但仍然产生了部分计算、或者平台内部的数据处理费用。所以我的建议是以账单总额为准以日志统计为佐证。两者差异超过 5% 时再回头排查是否有重复请求、超时重试、或者漏记的缓存消耗。3.3 一条命令搞定月度用量汇总附简单的统计脚本思路日志如果只是堆在那里不统计等于白记。我分享一个特别简单的统计思路用 Python 就能跑不需要任何额外依赖。假设日志文件里每一行都是类似这样的 JSON{model: claude-sonnet-4, input_tokens: 1200, output_tokens: 300, cache_creation_input_tokens: 0, cache_read_input_tokens: 5000, timestamp: 2025-06-01T10:00:00Z}统计脚本的核心逻辑就是按模型分组把四个 token 字段分别求和再乘上对应的单价。伪代码大概长这样import json from collections import defaultdict totals defaultdict(lambda: { input: 0, output: 0, cache_write: 0, cache_read: 0 }) with open(api_log.jsonl, r) as f: for line in f: try: item json.loads(line.strip()) except json.JSONDecodeError: continue model item.get(model, unknown) totals[model][input] item.get(input_tokens, 0) totals[model][output] item.get(output_tokens, 0) totals[model][cache_write] item.get(cache_creation_input_tokens, 0) totals[model][cache_read] item.get(cache_read_input_tokens, 0) for model, t in totals.items(): print(model, t)拿到汇总结果后再对照单价表手动加一个估算费用列。这一步不需要很精确够用来判断哪个模型最烧钱、哪类 token 占比最大就足够了。当然如果你不想自己搭这套统计逻辑Anthropic 控制台的 Usage 页面本身也能看到各模型的 token 消耗只是颗粒度没有日志那么细。我个人的习惯是两边都看控制台看趋势日志看细节。4. 第三步揪出四类隐形烧钱点4.1 长上下文是最大的成本放大器如果只能选一个成本黑洞来排查我建议优先查长上下文。因为它的放大效应实在惊人。很多项目的对话历史是无限累积的——每轮对话结束后把所有历史记录原样拼进下一次请求。我见过一个客服机器人原型会话刚开始时每请求只有 1500 token但用户聊到第 30 轮时单次请求的输入已经超过 20000 token。你以为用户只是问了 30 个问题实际上模型每次都要重新读完前面所有内容光读历史这件事就把成本放大了十几倍。这里有个特别容易踩的坑很多人觉得上下文越长回答质量越好于是无脑把所有历史都传给模型。但实测下来绝大多数任务根本不需要那么长的历史。我的经验是先看任务类型如果是问答保留最近 5 到 10 轮对话基本就够如果是文档分析把文档内容做成缓存而不是每轮重复传效果更好成本也更低。4.2 缓存读写既是省钱利器也是烧钱陷阱前面说过缓存读写有两面性用好了能大幅降低成本用不好反而会多花钱。先讲用得好的场景。假设你的应用有一个 5000 token 的固定 system prompt每次请求都原样带上按标准输入价格计算一天 10000 次请求光这一项就是5000 × 10000 50000000也就是 5000 万 token 的输入。如果每次都按标准输入价格收费这笔费用相当可观。但如果你启用了缓存第一次请求写入缓存写入价格略高后续 9999 次请求都走缓存读取价格比标准输入便宜得多总费用会显著下降。这就是缓存存在的意义。再讲陷阱场景。缓存不是自动生效的需要你在请求参数里显式指定 cache_control而且缓存的 key 是请求中的 prefix 内容只要前缀有任何一点变化缓存就可能失效重新走缓存写入流程。我遇到过一种情况system prompt 里拼接了一个动态时间戳结果每次请求的 prefix 都不一样缓存永远不命中而缓存写入的价格又高于标准输入最后账单比不开缓存时还贵。所以我的建议是启缓存之前先确认你放在缓存里的内容确实是完全不变的。任何动态内容时间、随机 ID、用户特定字段都不要放进 prefix否则缓存反而会成为烧钱陷阱。4.3 多轮对话、工具调用与失败重试的叠加效应长上下文的放大很多时候不是单次请求造成的而是多轮叠加造成的。成本最高的往往不是某一个长请求而是大量互相叠加的请求序列。举一个真实场景你在做 agent 类应用模型会调用工具。工具调用的机制是模型先生成一段工具调用指令然后你把工具结果返回给它它再继续生成下一步。一次看似简单的任务可能触发 3 到 5 次 API 往返。每一次往返都要把前面的全部对话历史重新带上token 量随着步骤增长。如果这中间某一步因为超时或网络抖动失败你又做了重试那失败的那一次请求费用可能已经产生了。更麻烦的是重试请求会把同一段历史重新计费一次成本直接翻倍。我把这类问题总结成一个公式总成本 ≈ 单次请求 token 数 × 请求次数 × 平均重试系数 × 单价。四个变量里任何一个失控账单都会很难看。通常大家只会关注单次 token 数和单价却忽略了请求次数和重试系数。优化的时候我会建议先把请求次数和重试次数降下来因为这两项往往比省几个 token 更有效。4.4 优化前后对比一个小项目省掉 60% 成本的例子理论讲再多不如一个具体例子直观。我手上有一个文档摘要小工具最初版本的成本结构是这样的成本项优化前优化后每次请求输入 token12000含完整文档 历史3000文档走缓存读取每任务请求次数5 次多轮工具调用3 次输出 token80003000单任务估算成本基准约为基准的 40%优化动作其实只有三个。第一把 8000 token 的原始文档从每次直接传改成缓存读取单次请求的输入费用大幅下降第二把工具调用链路从 5 步精简到 3 步减少无效往返第三把输出格式从详细报告改成简洁摘要并设置 max_tokens 上限防止模型话痨。三个动作叠加单任务成本直接降到原来的四成。而且优化之后因为请求更短、步骤更少响应速度也变快了。这算是省成本同时提升体验的好案例。我把优化优先级排个序供你参考优先压输出 token——输出单价最贵限制长度、精简格式立竿见影。其次压请求次数——减少工具调用轮次、合并能合并的请求。再考虑缓存——它能解决固定超大上下文的高频读取问题但要注意缓存命中率。最后才是压输入 token——比如精简 system prompt、控制对话历史轮数。5. 常见问题排查对不上账、报错与成本的关系5.1 为什么我算出来的费用和账单金额差一截这是我被问得最多的问题没有之一。用户按输入 token 单价 输出 token 单价算了一个数结果账单金额比这个数高于是怀疑是不是被多扣费了。我第一反应通常是你是不是忘了缓存费用很多人对缓存只有一个模糊概念不知道缓存写入价格比标准输入还贵。当你某个请求动态拼接了内容导致缓存反复写入时费用会在你完全没察觉的情况下溜走。第二个常见原因是账单里某个请求的输入 token 数量和你以为的数量不一样。举个例子你在控制台测试时输入显示 500 token但你的代码里实际拼接了工具返回结果、对话历史一次请求的真实输入可能是 3000 token。你按 500 估算自然对不上。第三个原因更隐蔽失败或超时的请求也可能计入费用。特别是请求已经到达服务端、模型开始生成后才中断的情况已经产生的输出 token 依然会计费。这也是日志统计和账单产生差异的主要原因之一。5.2 400 和 429 这类报错和账单有什么关系在排查成本的过程中你会不可避免地和各种 API 报错打交道。常见的 400 错误是请求参数有问题比如模型名不支持、context 超过上限。这类报错通常在请求进入模型推理之前就被拦截一般不会产生费用但会浪费你的开发时间和排查成本。和钱更相关的是 429 这类限流错误。比如请求过于频繁触发配额限制提示exceeded usage quota。这里有个容易忽略的点限流是在请求被接受并开始计算之后才可能发生的某些情况下被限流的请求也可能已经消耗了部分计算资源。我在自检时遇到过一种情况并发太高导致大量 429我以为是省钱了但实际上因为重试逻辑写得不严谨重试请求叠加了更多 token最终费用反而上升。所以我的建议是日志里不只要记录成功请求也要记录错误状态码和错误信息。尤其要关注请求失败时是否已经产生 usage——这个信息通常可以从响应头或错误详情里找到一点线索。养成记录错误日志的习惯排查对不上账的问题会快很多。5.3 月度账单自检清单我每个月都会过一遍与其每次出了问题再抢救不如固定一个自检流程。我给自己定了一个月度清单做完大概只要 20 分钟检查项检查方法正常状态账单总额是否接近日志统计日志按 usage 字段汇总与账单比对差异小于 5%是否存在异常高的缓存写入查看缓存写入 token 是否占比异常缓存写入占比小于标准输入输出 token 占比是否合理计算输出/输入比例输出费用不超过总费用的 60%单次请求平均 token 是否失控用总 token 除以请求次数多数场景应低于 5000是否有大量失败请求查看日志中的 4xx/5xx 状态码失败率低于 1%这套清单帮我在早期发现过好几次问题。印象最深的一次是我发现某个项目的缓存写入 token 占到总输入的 40%顺着日志一查发现是一段带时间戳的动态 prompt 导致缓存反复失效。改掉之后那个项目的成本立刻降了将近三成。6. 最后分享一点个人经验账单这个东西越早开始盯越好。很多人觉得等量大了再优化也不迟但大模型的费用增长是指数级的——优化动作发生得越晚你浪费的基数就越大。我第一次认真做这份账单自检时项目规模还不大但已经帮我把成本结构彻底理顺了。后来流量涨上去成本曲线依然可控靠的就是早期建立的那套看账单、对日志、查异常的循环。另外想提醒一句别过度优化。省成本的前提是不影响产品质量。我自己就试过为了压缩 token 把 system prompt 删到几乎不可用结果模型输出质量大幅下降反而要花更多时间调 prompt、加示例等于变相增加了人力成本。找到那个够用且不浪费的平衡点才是做成本管理真正的功夫所在。
