很多人在月底看到 Claude 账单的那一刻表情都是一样的明明感觉没调用多少次接口也没怎么高强度对话账单上的数字却比预期高出一大截。第一反应是“用得太多”第二反应是“Claude 太贵”但实际查了一圈之后你会发现 90% 的情况是设置压根没开对。我做 Claude 相关项目也有挺长时间了从 API 接入到 Claude Code 写自动化脚本再到给团队搭共享工作区账单从月初的几十美元一路飙到过几百美元最后通过系统性地调整设置把成本压回了原来的三分之一左右。这篇文章就把我自己实际用下来最管用的 18 个设置整理出来按“选模型—控上下文—调输出—工具链优化—账单审计”五个维度展开每一个都聊清楚“为什么贵”“怎么改”“改了能省多少”这不是理论推演都是真金白银试出来的。1. 账单超支的根因分析先搞清楚钱到底烧在哪1.1 按 token 计费的本质贵不是调用次数多是重复计算多Claude 的计费模型其实很简单按 token 计费输入prompt和输出completion分开计价上下文越长每次请求的输入 token 越多费用呈线性甚至超线性增长。但大多数人忽略了一个关键点相同的内容如果反复出现在每次请求里就会被反复计费。比如做一个批量文本处理任务循环里每次都带上一个 1000 字的背景说明循环 200 次这 1000 字就被计费 200 遍。很多“不贵”的模型在这种场景下也能跑出惊人的账单更别说 Claude 的价格本身就不便宜。所以成本优化的第一原则不是“少调用”而是“减少每次调用中不必要的 token”。这 18 个设置里一半以上的核心逻辑都围绕这一点展开。1.2 常见费用失控场景你大概率踩过其中一两个结合我自己的使用经验以及帮朋友排查过的案例最常见的账单失控场景有四种场景一系统提示词太长。有些人为了“稳定输出”把一整套工作流程、输出格式、几十条规则全塞进系统提示词每次调用都完整发送单次成本直接翻倍。场景二上下文没有裁剪。对话历史越积越长不清理、不压缩、不隔离话题导致 token 基数越来越大后面的每一次对话都在为前面的历史“还债”。场景三没有用缓存。Claude 的 prompt caching 功能可以大幅降低重复输入的费用但默认不开启很多人根本不知道。场景四Claude Code 之类的工具默认配置激进。自动读取一堆文件、自动重试、自动跳转看着方便实际上每个操作都在烧钱。如果你目前账单超支但又不确定具体是哪种情况先对照这四类自查一遍大概率能定位到问题。接下来我给出的 18 个设置就是针对这些场景逐项拆解出来的解决方案。2. 18 个关键设置全清单与实操逐条告诉你改什么、为什么、省多少2.1 模型选择维度别把 Opus 当默认模型用设置 1默认模型选 Sonnet 而非 Opus这是最基础也最容易被忽略的一条。Claude 家族里Opus 是最强但也是单价最高的型号Sonnet 在绝大多数日常任务上的表现已经足够好价格却低了 80% 以上。很多团队的代码里写死了model: claude-3-opus但实际上跑的任务只是简单的文本分类、信息抽取、格式整理。这类任务用 Sonnet 完成效果几乎无差别成本却天差地别。实操建议把默认模型改成claude-sonnet-4之类的中间档型号只有真正需要深度推理、复杂编程、长文档分析的时候再手动切换为 Opus。我见过太多人把 Opus 当默认选项月底账单一翻光这一项就多花了 3 到 5 倍的钱。设置 2复杂任务用 Opus日常任务强制走轻量模型光改默认模型还不够更严谨的做法是在代码里建立“任务难度分级机制”。比如简单问答、格式化、摘要 → Sonnet 或更轻量的 Haiku代码编写、逻辑推理、结构化分析 → Sonnet多步骤规划、长文档综合理解、复杂 Debug → Opus在 Claude API 请求里加一个模型路由逻辑根据任务的类型动态选择模型而不是让每个请求都打到最贵的模型上。这个策略听起来简单但实际执行下来整体成本能再降 20% 到 30%而且几乎不影响输出质量。2.2 上下文管理维度去除 token 浪费的重灾区设置 3系统提示词瘦身只保留“必须项”系统提示词是每次请求都会完整发送的这里的内容多一个 token成本就多一份。很多人喜欢把系统提示词写得像操作手册背景、目标、规则、示例、输出格式、禁忌、补充说明林林总总上千字。我的做法是系统提示词只保留三样东西——角色定位、任务目标、输出约束。其余的示例、背景知识、历史对话内容全部挪到用户消息或者仅在需要时插入。一个 300 token 的系统提示词和一个 1500 token 的系统提示词在同样调用量下费用差距是 5 倍。改完之后你会发现输出质量反而更稳定了因为干扰信息少了。设置 4控制 max_tokens防止“话痨模式”max_tokens代表单次请求允许模型输出的最大长度默认值往往偏大。模型有时候会在任务完成后继续“编”一些无关内容这些额外的输出 token 同样计费。实际操作中我通常先跑两三轮测试统计正常输出的 token 量级然后在这个基础上加 20% 左右的余量作为max_tokens上限。比如一个总结类任务正常输出 500 token就把 max_tokens 设为 600。这样既不会截断正常输出也不会让模型无限制写下去。设置 5对话历史要定期裁剪别让“历史包袱”拖垮每次请求多轮对话场景里上下文每轮都会增长如果一直不清理最后可能 80% 的 token 都是旧对话。尤其是在做客服机器人、文档问答这类应用时用户聊了 20 轮每次请求都要把前 19 轮的内容全部带上费用能不涨吗两个可落地的方案一是滑动窗口只保留最近 N 轮的对话内容二是定期摘要把前面若干轮对话交给模型提炼成一段摘要之后只携带摘要进行后续对话。前者实现简单后者信息保留更好但会额外消耗一次摘要生成的费用。我的经验是常规场景用滑动窗口配合设置 3 的瘦身系统提示词就够了复杂场景再上摘要。设置 6开启 Prompt Caching重复前缀费用直降 90%这个设置我觉得是 18 个里面最容易被忽视的省钱利器。Claude API 支持 prompt caching对请求中重复出现的相同前缀内容缓存后的 input token 计费远低于正常输入价格。具体操作是在请求头里配置cache_control把系统提示词或者多轮对话中稳定的部分标记为可缓存内容。比如你有一份固定的系统提示词、固定的产品说明、固定的示例集这些内容每次请求都相同开启缓存后第二次及后续请求中这些重复 token 的计费会大幅降低。实测下来效果非常明显。我维护的一个知识库问答项目system prompt 大约 1200 token开启缓存后每次请求的输入费用从“全量计费”变成“按缓存计费”长期运行下来光这一项就省了差不多 60% 的输入成本。如果你的请求具备“固定前缀 变化后缀”的特征强烈建议优先开启这个设置。2.3 输出质量与交互参数维度降低无效输出和重复调用设置 7temperature 别乱调稳定任务设低一点temperature控制输出随机性默认值通常是 0.7 到 1.0适合创意生成。但如果你做的是信息抽取、代码补全、数据格式化这类确定性任务较高的 temperature 反而会导致输出不稳定有时候同一段输入会生成不同的结果逼着你重复调用、人工校对成本自然就上去了。建议把这些确定性任务的 temperature 降到 0.2 或 0.3。输出更稳定返工率降低间接就省了钱。这不算是一个直接改价格的操作但通过减少“重复劳动”节省的 token 是实打实的。设置 8强制精简输出格式用结构化约束代替“自由发挥”在 API 请求中通过response_format或者其他结构化输出配置约束模型的回答格式可以从根源上避免模型输出大量无关信息。举个例子你本来只需要一个 JSON 对象但如果不加约束模型可能会输出一段完整的前言、解释、JSON再加一段后记大量输出 token 都是多余的。用结构化输出配置强制模型只返回 JSON输出 token 量会下降 30% 到 50%尤其适合大批量调用场景。设置 9请求前先做“预处理”把输入内容压缩到必需范围这个设置不属于 API 参数而是属于调用策略。很多人在把文档丢给 Claude 之前不做任何预处理原文 1 万字就直接塞进去。其实很多场景下根本不需要全文做问答先检索相关段落做分类只传关键字段做翻译只传需要翻译的句子。我习惯在调用 Claude API 之前加一个预处理步骤用规则或者轻量模型过滤掉无关章节只保留与任务相关的部分。这一步能把每次调用的输入 token 降一个量级配合设置 3 和设置 6成本下降非常明显。设置 10Batch API 走起异步任务价格直接减半Claude 提供了 Batch API可以异步批量处理非实时任务价格大约是实时请求的一半。如果你有大量离线任务——比如批量给文章生成摘要、批量做数据分析、批量文本审核——完全没有必要走实时接口把请求打包提交到 Batch API睡一觉再回来取结果就行。我目前批量任务基本都切到了 Batch API同样的任务量成本直接砍半。唯一的代价是不能实时返回结果但对于非交互场景这根本不是问题。2.4 Claude Code 与工作区设置维度工具链上的省钱细节设置 11Claude Code 的自动读取文件范围要手动收紧Claude Code 是现在非常火的终端编程工具很多人装上之后就把整个项目目录丢给它让它自己“探索”。看起来效率很高但每次它自动读取多个文件的内容这些内容都会被计费而且经常读取的是一些根本不需要的文件。正确做法是在 Claude Code 的配置里手动限定允许读取的文件目录和文件类型。比如只允许它读取src/下的代码和docs/下的文档忽略node_modules/、dist/等大型目录。这个设置不仅能让计费更可控还能减少无关信息对输出的干扰响应速度也会变快。实操下来这个改动对长期使用 Claude Code 做开发的人来说省下的钱非常可观。设置 12关闭不必要的自动重试机制Claude Code 在处理请求失败时默认可能会自动重试每重试一次就是一次完整的调用计费。如果连续重试几次一个小任务的钱可能翻好几倍。我的建议是在配置里把自动重试次数设为 0 或 1同时开启错误日志记录。一旦出现失败先看日志判断原因而不是让工具闷头重试。尤其是网络不稳定或者 API 配额不够时自动重试是最烧钱的行为之一。设置 13用 /compact 命令压缩长会话而不是抱着不放在 Claude Code 里当你跟它连续对话了很久会话上下文已经很大后续每次交互的成本都会很高。很多人不知道的是Claude Code 自带的/compact命令可以把当前会话压缩成摘要大幅缩减上下文长度然后继续后续操作。建议长期会话超过 20 到 30 轮之后就执行一次压缩把已经讨论完的细节收起来只保留仍然相关的信息和当前任务状态。我有一段时间做项目没注意这个一个会话挂了两天后续每次让它改代码都带着巨大的历史包袱费用涨得飞快后来改成定期 /compact成本才回落。设置 14会话按任务拆开别把所有事都堆在一个会话里与/compact 关联的一个习惯是会话隔离。一个会话只做一个任务做完了就新开一个会话。不同任务之间的历史信息不共享自然就不需要携带无关上下文。很多人的问题是上午让 Claude Code 写了个爬虫下午又让它改数据库结构中间所有旧对话都被带上了实际上后半段任务的 token 里有大量无关内容在重复计费。按任务拆分会话是零成本的 token 节省方式。设置 15项目级 memories / CLAUDE.md 只写关键约定Claude Code 支持通过CLAUDE.md之类的文件给项目注入长期记忆这个功能很好用但同样有被滥用的倾向。有人在里面写了几百行项目背景、开发规范、历史决策每次 Claude Code 启动都会加载这些内容token 消耗自然高。我的建议是CLAUDE.md只写反复出现的、对任务执行有直接影响的约定。比如项目的启动命令、代码风格要点、当前正在处理的核心模块控制在 50 到 100 行以内。其余的细节等需要的时候再临时告知不要全部做成常驻上下文。2.5 用量监控与预算维度别等账单出来了才心疼设置 16开启 Anthropic Console 的用量监控和预算告警Anthropic 的 Console 后台提供了 API 用量统计和余额告警功能。你可以设置每日或每月的告警阈值一旦消费超过预设值系统会通过邮件通知你。这个设置不是直接省钱但它是保障不“失控”的第一道防线。我以前有一段时间没开告警等项目做了一半才发现后端有个 bug 导致请求死循环等发现问题时账单已经涨了一截。开了阈值告警之后这类问题最多半小时内就能发现损失可以控制在小范围内。设置 17按项目维度拆分 API Key分别统计成本我这里说的“设置”是指组织架构上的一个习惯不同的项目使用不同的 API Key配合 Console 后台的标签功能每个项目的消耗情况一目了然。这样可以快速定位到“罪魁祸首”。比如你有 A、B、C 三个项目共用一个 API Key账单超支了你根本不知道是哪个项目烧的。分别用独立的 Key谁超支了就去检查谁的配置排查效率高很多。设置 18定期审计代码里的模型调用参数最后一个是所有设置里最需要养成习惯的每隔一两个星期打开你的代码仓库全局搜索一下模型调用的地方检查 model、max_tokens、temperature、上下文携带逻辑这些参数是否合理。因为项目是不断演进的代码改来改去可能某一天就把系统提示词调长了、把模型换成 Opus 了、或者把上下文限制逻辑注释掉了当时没注意月底就傻眼。定期审计是一个兜底机制确保前面 17 个设置不会被后续改动悄悄破坏。我个人的节奏是每个迭代周期结束都会检查一遍目前保持着 3 个月没有出现账单类异常的记录。3. 从 API 到 Claude Code完整工具链的降本实践3.1 API 调用层从一次请求到整套调度策略如果你是在自己的系统里调用 Claude API那么除了上面说的设置项还需要考虑一个更宏观的调度策略每一次请求发出前先问自己三个问题——用什么模型带多少上下文有没有更便宜的模型替代我目前的 API 调度逻辑是基于任务类型做分层的轻量级文本分类、实体抽取、简单翻译 → 用速度档模型 / Haiku 档位中量级代码编写、摘要生成、结构化分析 → 用 Sonnet 档位重量级复杂推理、多步骤规划、大型文档综述 → 用 Opus 档位同时配合设置 6 的缓存机制把每个档位请求中重复出现的系统提示词和固定示例都标记为缓存。这样既保证了响应质量又不会为重复内容重复付费。还有一个小技巧如果任务对“时效性”不敏感一律走 Batch API。我在项目里写了个简单的任务队列把所有非实时请求丢进去定时提交给 Batch 接口之前提到的价格减半就这样实现的。3.2 Claude Code 日常使用从开箱默认到精细调优Claude Code 是很多人接触 Claude 的入口但它的默认配置更适合“体验”而不是“经济性”。我建议拿到手之后第一件事就是按下面的顺序调整第一把项目目录白名单改小。只允许读取活跃的开发目录禁止访问依赖目录、构建产物目录、二进制文件目录。第二步调整自动重试机制别让它一失败就反复重跑同一段逻辑。第三步养成 /compact 的习惯长会话控制在一两百轮之内超了就压缩。第四步用独立的会话处理不同的任务同一时间只跟踪一个目标。四个步骤做完Claude Code 的使用费用至少能降一半左右。这是我实际对比过前后的数据得出来的结论不是拍脑袋。3.3 应急降本方案遇到账单失控时的“急救四步法”如果你打开后台一看这个月已经花了不少钱而且还在继续涨不要慌按我说的四个步骤做紧急处置第一步立即暂停官网页面的所有自动任务和历史会话的循环调用先把流量按住。第二步把实时请求全部切换为 Batch API或者直接暂时关停非核心任务减少辩护性调用。第三步把系统提示词临时瘦身最激进的做法是保留一两句核心指令先把每次调用的 token 基数降下来。第四步给 API Key 设置硬性消费上限如果控制台支持避免睡一觉起来账单又翻倍。这四步不是常规用法是救急用的。遇到问题先控住势头再慢慢调参数别一边心疼钱一边还让任务继续跑。4. 常见问题与排查技巧实录4.1 为什么我开了 Prompt Caching账单却没有明显下降这个问题我被问过很多次。最常见的原因是缓存只对“完全相同的文本前缀”生效哪怕只改了一个空格、一个标点缓存都会失效。我曾经踩过这个坑在系统提示词末尾动态拼接了一个时间戳或请求 ID导致每次请求都是“新的前缀”缓存形同虚设。排查方法也很简单把请求日志打出来对比连续请求的输入前缀是否完全一致。如果不一致检查代码里的动态部分把它们挪到用户消息里去。另外缓存有最短生效时长要求如果两次请求间隔过长缓存也会过期失效。这个属于正常情况不用太纠结。4.2 Claude Code 偶尔报错并自动重试费用飙得快怎么办这个问题本质是设置 12 里说的自动重试。Claude Code 默认在某些超时或网络错误时可能选择重试一次失败任务反复跑token 就像流水一样花出去。解决方案是去 Claude Code 的配置文件里把重试次数改为 0 或 1同时把报错内容输出到日志文件里定位根因之后再统一处理。还要注意检查是否有其他持续轮询机制比如某些插件会在后台自动保持会话心跳这种最容易在不知不觉中消耗费量。4.3 上下文已经很大了怎么快速知道下一次请求的 token 成本如果你用的是 Claude API可以在提交请求前用count_tokens这样的接口对 prompt 做预估。如果用的是 Claude Code可以用/context之类的命令查看当前上下文的占用情况。判断标准很简单当上下文超过模型最大输入的一半时就该考虑压缩或裁剪了。上下文越大后续每次请求的输入计费越高越早处理越省钱。4.4 模型输出的 token 经常超过我的预期怎么控制这个问题的直接原因通常是max_tokens没压住。不同任务的最佳输出长度差异很大我的建议是不要用同一个 max_tokens 跑所有任务而是给每类任务设一个独立的输出上限。另一个辅助手段是设置 8 的结构化输出约束强制模型按要求的格式输出。结合输出结果统计你会发现模型在不加限制的情况下确实容易“多写”加上约束之后输出精炼很多。5. 最后再分享一点我自己踩坑换来的体会说了这么多设置和参数我最想强调的其实是一个观念转变Claude 账单贵的本质不是模型单价高而是大量重复、低效的 token 消耗。模型的价格是固定不变的但每完成一个任务我们实际消耗了多少 token这个是有巨大优化空间的。我自己早期犯过的最大错误是“用最贵的模型做最简单的事”当时觉得反正调用量不大单价贵一点无所谓。结果等业务量上来一次性账单翻了十几倍才意识到这个想法多天真。后来把模型分级、上下文裁剪、缓存、批量接口这些设置全部用上之后同样的业务量成本只有原来的三分之一输出质量反而更稳定。如果你目前也被 Claude 账单困扰建议不要直接去跟模型价格较劲而是先把自己代码里的 model 参数、系统提示词长度、上下文管理逻辑对照着本文的 18 个设置逐一检查。大部分人只需要改其中的五六项月底账单就会有明显变化。省钱的核心在于精细化不在于不用把这些设置当成项目的标配基础设施以后就不会再被月底账单弄得措手不及了。