本文从工程实践角度复盘 Claude API Token 消耗问题。相比单纯查看模型价格表真实项目中更需要关注 input token、output token、缓存 token、重试次数和上下文长度。尤其在长文档分析、Agent、代码审查等场景中Token 成本很容易被放大。Claude API 单次请求成本可以按下面的方式估算成本 input_tokens / 1,000,000 × 输入单价 output_tokens / 1,000,000 × 输出单价 cache_write_tokens / 1,000,000 × 缓存写入单价 cache_read_tokens / 1,000,000 × 缓存读取单价高消耗任务主要包括 6 类长文档 / PDF 分析input token 高适合分段摘要 RAG。多轮 Agent工具调用和 observation 膨胀需要限制轮数。代码仓库审查只传 diff过滤无关文件。长对话客服最近 N 轮 摘要记忆。批量内容生成限制输出长度避免整批重试。JSON 抽取压缩 schema只输出紧凑 JSON。推荐配置Haiku 用于分类、FAQ、JSON 抽取Sonnet 用于长文档、代码审查和复杂推理Opus 用于低频高价值任务。生产环境建议记录 model、task_type、input_tokens、output_tokens、retry_count、estimated_cost并监控 P95 / P99 请求。一、先说结论Claude API 最烧钱的通常不是模型而是任务形态在大多数业务里Claude API token 消耗比较高的任务基本集中在下面这几类排名任务类型典型输入 token典型输出 token主要烧钱原因推荐模型策略省钱优先级1长文档 / PDF 分析高中高原文太长、反复分析、追问时又带全文Sonnet / Haiku 分段处理极高2多轮 Agent / 工具调用中高高历史上下文、工具结果、失败重试不断膨胀Sonnet 为主极高3代码仓库审查极高中文件太多、无关上下文多、diff 过大Sonnet 检索极高4长对话客服逐轮升高中每轮都带历史知识库反复注入Haiku / Sonnet 分流高5批量内容生成中极高输出内容长而输出 token 通常更贵Haiku / Sonnet高6JSON / 结构化抽取中中schema 长、字段重复、格式冗余Haiku 优先中简单说就是长输入会烧 input token长回答会烧 output token多轮任务会烧历史上下文Agent 类任务则容易烧在工具调用和重试上。二、Claude API 到底是怎么按 token 计费的Claude API 通常是按 token 计费的主要会涉及这几类input_tokens输入 token包括 system prompt、用户消息、历史消息、工具说明、知识库片段等output_tokens模型生成出来的内容cache_write_tokens使用 Prompt Caching 时写入缓存的 tokencache_read_tokens缓存命中后读取的 tokenBatch 请求如果官方当前还支持相关折扣可以用于异步批量任务不过具体规则还是要看官方说明。很多人一开始只会盯着输入有多长但其实输出也很关键。通常来说output token 的单价会高于 input token。所以在实际优化时让模型“少说废话”往往是最直接、也最有效的省钱方法之一。成本估算公式单次请求可以先用这个公式粗算单次请求成本 (input_tokens / 1,000,000 × 输入单价) (output_tokens / 1,000,000 × 输出单价) (cache_write_tokens / 1,000,000 × 缓存写入单价) (cache_read_tokens / 1,000,000 × 缓存读取单价)如果要估每 1000 次请求的成本每 1000 次成本 单次请求平均成本 × 1000月成本则可以这么估月成本 单次请求平均成本 × 日请求量 × 30不过上线前只看“平均值”其实不太够。更建议同时看 P95、P99 请求因为真正把账单拉高的往往不是普通请求而是少量超长请求、异常重试或者 Agent 陷入循环后不断调用工具。三、实测方法怎么统计 Claude API token 消耗为了让测试结果更有参考价值建议按任务类型分别统计usage字段而不是只看最后的总账单。测试项说明统计字段input_tokens、output_tokens、cache_write_tokens、cache_read_tokens测试任务长文档、Agent、代码审查、客服、内容生成、JSON 抽取成本口径按官方或服务平台每百万 token 单价换算注意事项prompt、模型版本、输出长度、缓存命中率都会影响结果如果你用的是 Anthropic 官方 Claude API最终还是要以官方控制台账单为准。如果使用 ClaudeAPI 等第三方 Claude API 兼容接入服务就需要额外确认模型映射、计费方式、充值、开票以及技术支持规则。需要特别注意的是第三方平台并不是 Anthropic 官方它们的说明也不应该被理解成官方承诺。四、6 类最烧钱任务排行榜4.1 第一名长文档 / PDF 分析典型场景很常见上传一份 2 万字合同、研报或者 PDF让 Claude 帮你总结、提取风险点、整理表格然后还要继续追问。这类任务输入 token 通常很高因为原文会被放进上下文里。如果每次追问都重新带上全文成本会涨得非常快。输出端也不便宜尤其是你要求它同时给出“摘要、表格、行动项、原文引用”时生成内容会明显变长。常见浪费点每次请求都重新传完整文档不先分段摘要直接全文分析追问时仍然重复携带原文固定文档没有使用缓存输出格式设计得太长生成了大量解释性文本。更省钱的做法第一可以先把文档分段摘要再把摘要合并起来分析。第二建立文档索引用户追问时只检索相关片段不要动不动就塞全文。另外固定文档或者固定规则可以考虑使用 Prompt Caching。追问阶段尽量只带摘要、章节索引和相关片段。输出也要收紧比如要求模型“只列结论、证据和风险等级”不要让它自由发挥。推荐配置模型Sonnet 负责主分析Haiku 处理分段摘要或简单抽取 max_tokens按摘要长度设置不给无限输出空间 上下文用 RAG 检索相关段落避免全文重复注入 输出结构化结论并限制条数4.2 第二名多轮 Agent / 工具调用Agent 类任务贵就贵在不太可控。模型可能会先规划再调用工具读完结果后继续反思、重试、再调用下一个工具。每一步都会产生新的输入和输出token 就这么一点点堆起来了。如果工具返回的是大量日志、网页正文、数据库查询结果而下一轮又把这些 observation 原封不动塞回上下文里Claude API 的 token 消耗会非常明显。常见浪费点工具结果没有压缩直接原样返回Agent 最大轮数不设限制失败后自动重试太多次每一轮都要求模型详细解释推理过程无关日志、HTML、报错堆栈全部进入上下文。更省钱的做法先给 Agent 设置最大工具调用轮数这是底线。工具返回结果前最好先做摘要或字段筛选只保留真正有用的信息。重试次数也要有硬上限不能让它无限尝试。遇到长日志时只截取错误附近的内容即可。更稳一点的做法是按request_id记录累计 token一旦超过预算就直接终止或降级处理。推荐配置模型Sonnet 为主简单工具路由可以用 Haiku max_tokens设置为中等避免输出长篇反思 上下文只保留关键 observation 预算按 request_id 记录累计成本4.3 第三名代码仓库审查代码审查的主要问题通常不是输出太长而是输入太大。很多团队会把整个仓库、多个文件、依赖清单、lock 文件甚至构建产物一起丢给模型input token 很容易飙升。常见浪费点一次性上传整个仓库把node_modules、dist、日志、lock 文件也传进去diff 很大但没有筛选重点仓库结构说明每次重复传让模型同时做安全、性能、代码风格、架构等多种审查。更省钱的做法默认只传 diff而不是全量文件。依赖目录、构建产物、日志文件这些内容应该在进入模型前就过滤掉。可以先用脚本筛选变更文件再把真正需要模型判断的部分交给 Claude。低价模型可以先做简单初筛高价模型再审关键代码。像仓库结构、编码规范这类固定前缀也可以考虑缓存。推荐配置模型Sonnet 做主审查Haiku 做简单 lint 类初筛 max_tokens中等要求输出问题列表 上下文只传 diff 必要相关函数 输出按严重程度列出不要生成完整长篇报告4.4 第四名长对话客服客服机器人看起来每轮输入都不长但多轮对话会不断把历史叠进去。如果每轮都携带完整聊天记录、完整 system prompt再加上多个知识库片段成本就会一轮比一轮高。常见浪费点每轮都带全部历史消息system prompt 太长而且不能复用RAG 每次塞入太多知识库片段用户只是闲聊也调用高价模型FAQ 和复杂工单没有区分处理。更省钱的做法只保留最近 N 轮对话老历史压缩成摘要记忆。system prompt 要尽量精简而且保持稳定。RAG 的top_k不宜一开始设太大通常可以先从 3-5 个片段开始测试。FAQ、分类、意图识别这类低风险任务优先用 Haiku复杂问题再升级到 Sonnet。推荐配置模型Haiku 优先复杂问题转 Sonnet max_tokens低到中 上下文最近 N 轮 摘要 输出简短回答必要时给下一步操作4.5 第五名批量内容生成批量写标题、商品描述、邮件、SEO 段落时真正贵的往往是 output token。生成内容越长版本越多语气要求越复杂费用就越容易上去。常见浪费点一次生成 10 个版本每个版本都要求详细解释没有字数限制让模型自由发挥输出大量铺垫失败后整批重试。更省钱的做法先明确字数上限。复杂内容可以先生成大纲再选择性扩写。只要最终内容就不要让模型解释创作思路。低风险的大批量任务优先考虑 Haiku。对于异步批量任务也可以关注官方 Batch 能力以及对应折扣规则。推荐配置模型Haiku / Sonnet 按质量要求分流 max_tokens严格限制 输出只给正文不给解释 批处理失败重试按单条重试不要整批重跑4.6 第六名JSON / 结构化抽取JSON 抽取看起来简单但实际也会消耗不少 token。schema 描述、字段名、缩进、解释文本都会增加长度。尤其是字段很多、数组很长的时候输出成本并不低。常见浪费点schema 描述写得过长字段名重复而且字段名本身很长要求漂亮缩进JSON 前后还附带解释数组长度没有上限。更省钱的做法schema 能压缩就压缩。提示词里要明确写清楚“只输出 JSON不要解释”。如果系统允许可以使用短字段名后处理时再映射成业务字段。数组也要限制最大长度。至于格式化完全可以交给程序处理不必让模型输出漂亮排版。推荐配置模型Haiku 优先 max_tokens按字段数量估算 输出minified JSON 或紧凑 JSON stop sequences可用于截断无关尾巴五、Claude API 费用优化按任务选模型不要只选最强模型模型选择不应该只看“哪个最强”还要看任务价值、错误成本和返工率。有些任务用强模型当然效果好但从成本角度看并不一定划算。任务HaikuSonnetOpus简单分类推荐可用但可能浪费通常不推荐FAQ 客服推荐复杂问题升级通常不推荐长文档分析可做预处理推荐高价值场景再考虑代码审查简单初筛推荐关键代码、低频高风险复杂推理不建议主用推荐高价值、低频任务更稳妥的策略是低价模型做预处理高价模型做最终判断。比如先用 Haiku 做分类、摘要、候选提取再让 Sonnet 处理复杂推理或最终审核。这样既能控制成本也不至于明显牺牲结果质量。六、省钱配置方案上线前建议先设好这 8 项策略作用设置max_tokens防止输出失控要求“只输出必要内容”减少解释性废话JSON 禁止解释文本降低结构化输出成本使用 stop sequences控制尾部冗余精简 system prompt每轮都会计入越短越好固定前缀使用 Prompt Caching适合长 system prompt、固定文档、工具说明长对话摘要记忆避免无限携带历史记录 usage 并设置告警及时发现异常消耗这里顺便说一句temperature本身不是直接计费参数。但如果随机性太高模型输出可能更发散失败重试也可能变多最后间接增加成本。生产环境里通常更建议优先保证稳定、简洁、可解析。七、Prompt Caching 不是万能省钱开关Prompt Caching 很有用但它不是所有场景都适合。比较适合的情况包括固定 system prompt固定长文档固定工具说明固定业务规则高频重复前缀。不太适合的情况则是每次 prompt 都变化很大用户输入很短而且随机性很强请求频率很低前缀没法稳定复用缓存命中率很低。判断缓存值不值得开不能只看“有没有启用”关键要看命中率、缓存写入成本、读取成本和请求频率。比如长文档问答、固定合同模板、固定工具说明就很值得测试缓存效果但如果只是短文本分类缓存带来的收益可能就比较有限。八、月成本估算模板上线前可以用下面这张表先做预算任务模型平均输入 token平均输出 token单次成本日调用量月成本FAQ 客服Haiku长文档问答Sonnet代码审查Sonnet内容生成Haiku / SonnetJSON 抽取Haiku除了平均值还建议额外记录 P95 输入 token、P95 输出 token、失败重试率和缓存命中率。平均值只能帮你看日常成本P95、P99 才更容易暴露账单风险。九、成本监控怎么发现 token 异常消耗每次 Claude API 请求建议至少记录这些字段modeltask_typeinput_tokensoutput_tokenscache_write_tokenscache_read_tokensuser_idrequest_idretry_countestimated_cost常见告警规则可以包括第一单次 input token 超过阈值第二单次 output token 超过阈值另外某个用户的日消耗超过预算、某类任务成本环比突然上涨也都应该触发告警。Agent 场景还要关注工具调用轮数是否异常以及重试次数有没有突然升高。缓存命中率如果突然下降也很可能导致成本上升。排查时可以按这个顺序来先看 output 有没有失控再看上下文是不是变长了然后看重试次数是否增加最后再检查缓存是否失效。十、总结Claude API 省钱优先级如果你要做 Claude API 费用优化可以按下面这个顺序来第一先限制输出长度。设置max_tokens并明确要求只输出必要内容。第二压缩上下文。长文档要分段问答用 RAG 检索多轮对话用历史摘要。第三做好模型分流。Haiku 处理低风险任务Sonnet 处理复杂任务Opus 留给高价值、低频场景。第四再考虑缓存。固定 system prompt、固定文档、工具说明都可以优先测试 Prompt Caching。最后把监控和治理补上。记录 usage设置预算拦截异常请求。按具体场景来看做客服优先用 Haiku 最近 N 轮对话 摘要记忆做长文档用 RAG 分段摘要 缓存固定内容做代码审查只传 diff并过滤无关文件做内容生成限制字数尽量模板化输出做 Agent限制轮数压缩工具结果并设置预算告警。Claude API token 消耗本身并不可怕真正危险的是没有统计、没有限制、也没有模型分流。只要把任务拆清楚把 usage 记录下来再把输出长度和上下文规模管住Claude API 的成本通常都能进入一个比较可预测的范围。
本文从工程实践角度复盘 Claude API Token 消耗问题。相比单纯查看模型价格表真实项目中更需要关注 input token、output token、缓存 token、重试次数和上下文长度。尤其在长文档分析、Agent、代码审查等场景中Token 成本很容易被放大。Claude API 单次请求成本可以按下面的方式估算成本 input_tokens / 1,000,000 × 输入单价 output_tokens / 1,000,000 × 输出单价 cache_write_tokens / 1,000,000 × 缓存写入单价 cache_read_tokens / 1,000,000 × 缓存读取单价高消耗任务主要包括 6 类长文档 / PDF 分析input token 高适合分段摘要 RAG。多轮 Agent工具调用和 observation 膨胀需要限制轮数。代码仓库审查只传 diff过滤无关文件。长对话客服最近 N 轮 摘要记忆。批量内容生成限制输出长度避免整批重试。JSON 抽取压缩 schema只输出紧凑 JSON。推荐配置Haiku 用于分类、FAQ、JSON 抽取Sonnet 用于长文档、代码审查和复杂推理Opus 用于低频高价值任务。生产环境建议记录 model、task_type、input_tokens、output_tokens、retry_count、estimated_cost并监控 P95 / P99 请求。一、先说结论Claude API 最烧钱的通常不是模型而是任务形态在大多数业务里Claude API token 消耗比较高的任务基本集中在下面这几类排名任务类型典型输入 token典型输出 token主要烧钱原因推荐模型策略省钱优先级1长文档 / PDF 分析高中高原文太长、反复分析、追问时又带全文Sonnet / Haiku 分段处理极高2多轮 Agent / 工具调用中高高历史上下文、工具结果、失败重试不断膨胀Sonnet 为主极高3代码仓库审查极高中文件太多、无关上下文多、diff 过大Sonnet 检索极高4长对话客服逐轮升高中每轮都带历史知识库反复注入Haiku / Sonnet 分流高5批量内容生成中极高输出内容长而输出 token 通常更贵Haiku / Sonnet高6JSON / 结构化抽取中中schema 长、字段重复、格式冗余Haiku 优先中简单说就是长输入会烧 input token长回答会烧 output token多轮任务会烧历史上下文Agent 类任务则容易烧在工具调用和重试上。二、Claude API 到底是怎么按 token 计费的Claude API 通常是按 token 计费的主要会涉及这几类input_tokens输入 token包括 system prompt、用户消息、历史消息、工具说明、知识库片段等output_tokens模型生成出来的内容cache_write_tokens使用 Prompt Caching 时写入缓存的 tokencache_read_tokens缓存命中后读取的 tokenBatch 请求如果官方当前还支持相关折扣可以用于异步批量任务不过具体规则还是要看官方说明。很多人一开始只会盯着输入有多长但其实输出也很关键。通常来说output token 的单价会高于 input token。所以在实际优化时让模型“少说废话”往往是最直接、也最有效的省钱方法之一。成本估算公式单次请求可以先用这个公式粗算单次请求成本 (input_tokens / 1,000,000 × 输入单价) (output_tokens / 1,000,000 × 输出单价) (cache_write_tokens / 1,000,000 × 缓存写入单价) (cache_read_tokens / 1,000,000 × 缓存读取单价)如果要估每 1000 次请求的成本每 1000 次成本 单次请求平均成本 × 1000月成本则可以这么估月成本 单次请求平均成本 × 日请求量 × 30不过上线前只看“平均值”其实不太够。更建议同时看 P95、P99 请求因为真正把账单拉高的往往不是普通请求而是少量超长请求、异常重试或者 Agent 陷入循环后不断调用工具。三、实测方法怎么统计 Claude API token 消耗为了让测试结果更有参考价值建议按任务类型分别统计usage字段而不是只看最后的总账单。测试项说明统计字段input_tokens、output_tokens、cache_write_tokens、cache_read_tokens测试任务长文档、Agent、代码审查、客服、内容生成、JSON 抽取成本口径按官方或服务平台每百万 token 单价换算注意事项prompt、模型版本、输出长度、缓存命中率都会影响结果如果你用的是 Anthropic 官方 Claude API最终还是要以官方控制台账单为准。如果使用 ClaudeAPI 等第三方 Claude API 兼容接入服务就需要额外确认模型映射、计费方式、充值、开票以及技术支持规则。需要特别注意的是第三方平台并不是 Anthropic 官方它们的说明也不应该被理解成官方承诺。四、6 类最烧钱任务排行榜4.1 第一名长文档 / PDF 分析典型场景很常见上传一份 2 万字合同、研报或者 PDF让 Claude 帮你总结、提取风险点、整理表格然后还要继续追问。这类任务输入 token 通常很高因为原文会被放进上下文里。如果每次追问都重新带上全文成本会涨得非常快。输出端也不便宜尤其是你要求它同时给出“摘要、表格、行动项、原文引用”时生成内容会明显变长。常见浪费点每次请求都重新传完整文档不先分段摘要直接全文分析追问时仍然重复携带原文固定文档没有使用缓存输出格式设计得太长生成了大量解释性文本。更省钱的做法第一可以先把文档分段摘要再把摘要合并起来分析。第二建立文档索引用户追问时只检索相关片段不要动不动就塞全文。另外固定文档或者固定规则可以考虑使用 Prompt Caching。追问阶段尽量只带摘要、章节索引和相关片段。输出也要收紧比如要求模型“只列结论、证据和风险等级”不要让它自由发挥。推荐配置模型Sonnet 负责主分析Haiku 处理分段摘要或简单抽取 max_tokens按摘要长度设置不给无限输出空间 上下文用 RAG 检索相关段落避免全文重复注入 输出结构化结论并限制条数4.2 第二名多轮 Agent / 工具调用Agent 类任务贵就贵在不太可控。模型可能会先规划再调用工具读完结果后继续反思、重试、再调用下一个工具。每一步都会产生新的输入和输出token 就这么一点点堆起来了。如果工具返回的是大量日志、网页正文、数据库查询结果而下一轮又把这些 observation 原封不动塞回上下文里Claude API 的 token 消耗会非常明显。常见浪费点工具结果没有压缩直接原样返回Agent 最大轮数不设限制失败后自动重试太多次每一轮都要求模型详细解释推理过程无关日志、HTML、报错堆栈全部进入上下文。更省钱的做法先给 Agent 设置最大工具调用轮数这是底线。工具返回结果前最好先做摘要或字段筛选只保留真正有用的信息。重试次数也要有硬上限不能让它无限尝试。遇到长日志时只截取错误附近的内容即可。更稳一点的做法是按request_id记录累计 token一旦超过预算就直接终止或降级处理。推荐配置模型Sonnet 为主简单工具路由可以用 Haiku max_tokens设置为中等避免输出长篇反思 上下文只保留关键 observation 预算按 request_id 记录累计成本4.3 第三名代码仓库审查代码审查的主要问题通常不是输出太长而是输入太大。很多团队会把整个仓库、多个文件、依赖清单、lock 文件甚至构建产物一起丢给模型input token 很容易飙升。常见浪费点一次性上传整个仓库把node_modules、dist、日志、lock 文件也传进去diff 很大但没有筛选重点仓库结构说明每次重复传让模型同时做安全、性能、代码风格、架构等多种审查。更省钱的做法默认只传 diff而不是全量文件。依赖目录、构建产物、日志文件这些内容应该在进入模型前就过滤掉。可以先用脚本筛选变更文件再把真正需要模型判断的部分交给 Claude。低价模型可以先做简单初筛高价模型再审关键代码。像仓库结构、编码规范这类固定前缀也可以考虑缓存。推荐配置模型Sonnet 做主审查Haiku 做简单 lint 类初筛 max_tokens中等要求输出问题列表 上下文只传 diff 必要相关函数 输出按严重程度列出不要生成完整长篇报告4.4 第四名长对话客服客服机器人看起来每轮输入都不长但多轮对话会不断把历史叠进去。如果每轮都携带完整聊天记录、完整 system prompt再加上多个知识库片段成本就会一轮比一轮高。常见浪费点每轮都带全部历史消息system prompt 太长而且不能复用RAG 每次塞入太多知识库片段用户只是闲聊也调用高价模型FAQ 和复杂工单没有区分处理。更省钱的做法只保留最近 N 轮对话老历史压缩成摘要记忆。system prompt 要尽量精简而且保持稳定。RAG 的top_k不宜一开始设太大通常可以先从 3-5 个片段开始测试。FAQ、分类、意图识别这类低风险任务优先用 Haiku复杂问题再升级到 Sonnet。推荐配置模型Haiku 优先复杂问题转 Sonnet max_tokens低到中 上下文最近 N 轮 摘要 输出简短回答必要时给下一步操作4.5 第五名批量内容生成批量写标题、商品描述、邮件、SEO 段落时真正贵的往往是 output token。生成内容越长版本越多语气要求越复杂费用就越容易上去。常见浪费点一次生成 10 个版本每个版本都要求详细解释没有字数限制让模型自由发挥输出大量铺垫失败后整批重试。更省钱的做法先明确字数上限。复杂内容可以先生成大纲再选择性扩写。只要最终内容就不要让模型解释创作思路。低风险的大批量任务优先考虑 Haiku。对于异步批量任务也可以关注官方 Batch 能力以及对应折扣规则。推荐配置模型Haiku / Sonnet 按质量要求分流 max_tokens严格限制 输出只给正文不给解释 批处理失败重试按单条重试不要整批重跑4.6 第六名JSON / 结构化抽取JSON 抽取看起来简单但实际也会消耗不少 token。schema 描述、字段名、缩进、解释文本都会增加长度。尤其是字段很多、数组很长的时候输出成本并不低。常见浪费点schema 描述写得过长字段名重复而且字段名本身很长要求漂亮缩进JSON 前后还附带解释数组长度没有上限。更省钱的做法schema 能压缩就压缩。提示词里要明确写清楚“只输出 JSON不要解释”。如果系统允许可以使用短字段名后处理时再映射成业务字段。数组也要限制最大长度。至于格式化完全可以交给程序处理不必让模型输出漂亮排版。推荐配置模型Haiku 优先 max_tokens按字段数量估算 输出minified JSON 或紧凑 JSON stop sequences可用于截断无关尾巴五、Claude API 费用优化按任务选模型不要只选最强模型模型选择不应该只看“哪个最强”还要看任务价值、错误成本和返工率。有些任务用强模型当然效果好但从成本角度看并不一定划算。任务HaikuSonnetOpus简单分类推荐可用但可能浪费通常不推荐FAQ 客服推荐复杂问题升级通常不推荐长文档分析可做预处理推荐高价值场景再考虑代码审查简单初筛推荐关键代码、低频高风险复杂推理不建议主用推荐高价值、低频任务更稳妥的策略是低价模型做预处理高价模型做最终判断。比如先用 Haiku 做分类、摘要、候选提取再让 Sonnet 处理复杂推理或最终审核。这样既能控制成本也不至于明显牺牲结果质量。六、省钱配置方案上线前建议先设好这 8 项策略作用设置max_tokens防止输出失控要求“只输出必要内容”减少解释性废话JSON 禁止解释文本降低结构化输出成本使用 stop sequences控制尾部冗余精简 system prompt每轮都会计入越短越好固定前缀使用 Prompt Caching适合长 system prompt、固定文档、工具说明长对话摘要记忆避免无限携带历史记录 usage 并设置告警及时发现异常消耗这里顺便说一句temperature本身不是直接计费参数。但如果随机性太高模型输出可能更发散失败重试也可能变多最后间接增加成本。生产环境里通常更建议优先保证稳定、简洁、可解析。七、Prompt Caching 不是万能省钱开关Prompt Caching 很有用但它不是所有场景都适合。比较适合的情况包括固定 system prompt固定长文档固定工具说明固定业务规则高频重复前缀。不太适合的情况则是每次 prompt 都变化很大用户输入很短而且随机性很强请求频率很低前缀没法稳定复用缓存命中率很低。判断缓存值不值得开不能只看“有没有启用”关键要看命中率、缓存写入成本、读取成本和请求频率。比如长文档问答、固定合同模板、固定工具说明就很值得测试缓存效果但如果只是短文本分类缓存带来的收益可能就比较有限。八、月成本估算模板上线前可以用下面这张表先做预算任务模型平均输入 token平均输出 token单次成本日调用量月成本FAQ 客服Haiku长文档问答Sonnet代码审查Sonnet内容生成Haiku / SonnetJSON 抽取Haiku除了平均值还建议额外记录 P95 输入 token、P95 输出 token、失败重试率和缓存命中率。平均值只能帮你看日常成本P95、P99 才更容易暴露账单风险。九、成本监控怎么发现 token 异常消耗每次 Claude API 请求建议至少记录这些字段modeltask_typeinput_tokensoutput_tokenscache_write_tokenscache_read_tokensuser_idrequest_idretry_countestimated_cost常见告警规则可以包括第一单次 input token 超过阈值第二单次 output token 超过阈值另外某个用户的日消耗超过预算、某类任务成本环比突然上涨也都应该触发告警。Agent 场景还要关注工具调用轮数是否异常以及重试次数有没有突然升高。缓存命中率如果突然下降也很可能导致成本上升。排查时可以按这个顺序来先看 output 有没有失控再看上下文是不是变长了然后看重试次数是否增加最后再检查缓存是否失效。十、总结Claude API 省钱优先级如果你要做 Claude API 费用优化可以按下面这个顺序来第一先限制输出长度。设置max_tokens并明确要求只输出必要内容。第二压缩上下文。长文档要分段问答用 RAG 检索多轮对话用历史摘要。第三做好模型分流。Haiku 处理低风险任务Sonnet 处理复杂任务Opus 留给高价值、低频场景。第四再考虑缓存。固定 system prompt、固定文档、工具说明都可以优先测试 Prompt Caching。最后把监控和治理补上。记录 usage设置预算拦截异常请求。按具体场景来看做客服优先用 Haiku 最近 N 轮对话 摘要记忆做长文档用 RAG 分段摘要 缓存固定内容做代码审查只传 diff并过滤无关文件做内容生成限制字数尽量模板化输出做 Agent限制轮数压缩工具结果并设置预算告警。Claude API token 消耗本身并不可怕真正危险的是没有统计、没有限制、也没有模型分流。只要把任务拆清楚把 usage 记录下来再把输出长度和上下文规模管住Claude API 的成本通常都能进入一个比较可预测的范围。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
