上个月我把一个攒了很久的个人项目丢给 Claude Code 去重跑全量重构、改接口、补测试、顺手写一堆文档和迁移脚本。二十多天下来终端里累计跑掉了 400 万 Tokens月底打开 API 账单一看26 美元。这个数字放到企业项目里不算什么但对我这种自掏腰包做工具的开发者来说确实有点肉疼。后来我把默认模型切到了 DeepSeek 系列的最新版本——也就是标题里那个 V4 所指代的当时可用版本配合缓存、压缩、任务拆分这几件事同一批任务再跑一轮账单直接缩到了 2 美元。整个过程没有牺牲完成度该重构的重构完该修的 bug 也都修了。这篇文章就是这次降本实践的完整记录包括账单拆解、接入方式、成本控制的逻辑以及几个只有真跑过才会遇到的坑。1. 26 美元花在哪Claude Code 的计费结构与账单拆解先说一个很多人刚接触 Claude Code 时容易忽略的点它不是一个“一次对话收一次费”的工具而是一个会高频调用模型 API 的终端助手。你每让它执行一步操作它都可能发起一次新的 API 请求而每次请求携带的输入内容是整个会话从第一句话到当前的全部上下文。理解了这个机制再看账单就不会觉得“我又没拼命用怎么这么贵”了。1.1 输入和输出计价差了一个数量级模型的 API 计费从来不是按总 token 量一刀切而是把输入、输出、缓存分别计价。以我当时用的 Claude Sonnet 级别模型为例公开价大致是输入 3 美元/百万 tokens输出 15 美元/百万 tokens缓存读取则在 0.3 美元/百万 tokens 左右。也就是说同样一个 token模型“读进去”和“写出来”的成本差了 5 倍。这个差异直接决定了省钱的第一原则输出 token 尽量少输入 token 尽量精。但在 Claude Code 里“输出少”往往意味着任务完成度下降所以真正能动手的地方是输入侧——把每次请求携带的历史对话和工具定义压下去。出力方向确定后剩下的就是算一笔账看看 400 万 Tokens 到底是怎么滚到 26 美元的。1.2 从 400 万 Tokens 的构成看隐形开销我那个月的用量从平台账单里拆出来大概是这个结构计费项占比Tokens 量约按 Claude 单价估算输入缓存未命中65%260 万7.8 美元缓存读取15%60 万0.18 美元输出20%80 万12 美元缓存写入、重试、计费舍入等——约 6 美元合计100%400 万约 26 美元如果你发现自己也处于类似的构成比例那说明主要开销来源是“反复搬运上下文”而不是“模型思考太多次”。这正是 Claude Code 这类长会话工具的典型特征任务本身不难但每执行一个小工具调用都要把前面一大段对话重新发给模型。举一个实际的例子我在一个超过 100k tokens 的会话里让它改某几个文件它先列计划、再看代码、再执行修改、再跑测试一轮下来 API 调用次数能到 10 次以上而其中 8 次的输入里都背着完整的 100k 上下文。真正付费的“思考”很少大部分钱都花在了反复传输已经看过的内容上。1.3 为什么不能靠“少生成一点”省钱很多人第一反应是既然输出贵那就让模型少说废话、少输出解释性内容。这有用但天花板很低。我测试过把系统提示词改成“只输出代码不输出任何解释”输出 token 大概能节省 20% 左右但同时也把 Claude Code 原本清晰的变更记录和操作确认给砍掉了实际使用时反而容易出错。关键是输出端节省 20%20 美元的账单也就省出 4 美元离“从 26 降到 2”差了十万八千里。真正拉开差距的是输入端每轮重复传输的上下文以及模型单价本身。这两件事一个靠换引擎解决一个靠上下文治理解决。2. 接入 DeepSeek 系列模型网关、配置与兼容性改造Claude Code 的优势在交互设计但它对后端模型并没有做严格锁定它允许你把请求指向任意一个符合 Anthropic 消息协议的端点。这个特性是这次“换引擎”的基础。2.1 Claude Code 只认一种协议DeepSeek 是另一种Claude Code 原生请求格式是 Anthropic 的/v1/messages风格请求体里有一套自己的工具调用、图片和缓存标记规范。而 DeepSeek 的 API 走的是 OpenAI 风格的/v1/chat/completions。两者字段名不同消息角色定义有差异工具调用的 schema 风格也完全不一样。直接改ANTHROPIC_BASE_URL指向 DeepSeek 官方地址是不行的请求会因为格式不匹配直接报 400。所以需要一个协议转换层——也就是常说的 API 网关。我在本机跑了一个自建的轻量网关逻辑很简单Claude Code 把 Anthropic 格式的请求发给本地网关网关转换为 OpenAI 格式后转发给 DeepSeek API收到响应后再把 OpenAI 格式转回 Anthropic 格式返回给 Claude Code。整体链路对 Claude Code 来说是完全透明的会话、权限、工具调用逻辑都不用改。2.2 网关搭建与最小配置模板网关的接入核心就三个环境变量# 让 Claude Code 把请求发到本地网关 export ANTHROPIC_BASE_URLhttp://127.0.0.1:8787 # 网关侧统一拿这个 key 去调用 DeepSeek API export ANTHROPIC_AUTH_TOKENsk-your-deepseek-key # 告诉 Claude Code 当前用的模型名最终由网关做映射 export ANTHROPIC_MODELdeepseek-v4如果你不想每次开终端都手动 export也可以写到项目或用户级配置文件里。Claude Code 的配置文件是settings.json一个最小可用的写法长这样{ model: deepseek-v4, env: { ANTHROPIC_BASE_URL: http://127.0.0.1:8787, ANTHROPIC_AUTH_TOKEN: env:DEEPSEEK_API_KEY, ANTHROPIC_MODEL: deepseek-v4 } }注意env:DEEPSEEK_API_KEY这种写法表示从本地环境变量里读取真实 key避免把密钥直接写进配置文件。网关那边只需要一张简单的映射表把deepseek-v4这类模型名映射到 DeepSeek 平台当时真实可用的版本即可。2.3 最容易忽略的参数映射细节协议转换不是换个地址就完事我踩了几个很容易忽略的细节这里提前帮大家排一下雷。第一是max_tokens上限。Claude Code 默认会按 Claude 系列的风格申请较高的最大输出长度但 DeepSeek 模型对单次输出的上限有自己的一套约束。如果网关不代理处理这个字段请求会因为“要求的输出 token 数超过模型上限”直接失败。我的做法是在网关里统一把输出上限截到模型允许的范围之内。第二是工具调用的 schema 兼容。Claude Code 会一次性发一大串工具定义Anthropic 格式和 OpenAI 格式的定义方式差别很大转换时很容易出现字段丢失。最直接的缓解办法就是后面会讲到的缩小工具集不用工具的 MCP 先拆掉让网关每次转换的内容更少、更不容易出错。第三是响应格式里对stop_reason和工具调用角色的映射。OpenAI 格式用tool_calls表示工具调用Anthropic 格式用tool_use块网关需要把这部分正确翻译。如果转换代码只处理了普通文本消息碰到工具调用就会静默失败——模型一脸无辜地回答你就是不执行操作。第三部分的坑最隐蔽因为不会报红只会让你觉得“模型变笨了”。我第一次切过去的时候连续试了几次都发现模型绕开工具直接给建议排查到最后才发现是网关的工具调用转换逻辑写漏了一种边界情况。所以如果你切换后遇到模型行为突变不要急着怀疑模型能力先查一下网关的转换日志。3. 单价便宜不等于账单便宜上下文治理三板斧把模型从 Claude 换成 DeepSeek 系列之后同样 100 万 tokens 的输入成本能降到原来的十分之一左右输出成本也类似。但如果你不治理上下文只是把后端换掉那么原来 26 美元的账单大概率会变成 6 到 8 美元而不是 2 美元。原因很简单400 万 tokens 里 80% 都是输入和缓存类消耗这部分虽然单价便宜了但数量还在。真正要从 26 到 2还得靠三板斧把“总 token 消耗量”本身打下来。3.1 压缩而不是清空/compact 的正确用法Claude Code 提供了一个/compact命令作用是让模型把当前会话的历史对话浓缩成一份摘要然后从这份摘要继续往后聊。它的本质不是清空记忆而是把 100k 的对话历史压缩成 3k 到 5k 的总结让后续每次请求的输入量断崖式下降。我用它的时机有两个一是上下文即将接近模型窗口上限时二是我明显感觉到同一个会话里已经聊了太多“过去时”的内容当前要解决的问题和前面的对话关联不大了。在长任务的中段主动执行一次/compact单次请求的输入可以从 100k 以上降到 5k 左右效果非常直观。但压缩不等于无损它的副作用也很大。模型在压缩过程中可能丢掉一些关键约束比如你在一小时前说过的编码规范、某个文件的特殊处理逻辑压缩后它可能只记住了“你在做一个项目”细节全丢了。所以我现在养成了一个习惯关键约束不能被塞在对话历史里要写进项目根目录下的一个固定的规范文件让 Claude Code 每次自动读取。这样即使对话被压缩约束也还在。3.2 系统提示词与 MCP 工具瘦身Claude Code 每次请求都会携带自己的系统提示词再加上你配置的 MCP 工具定义。初看每条都只有几千 tokens但乘以一天几百次调用就是一个不小的数字而且它是每轮重复收费的。我做过一次测量在那个 400 万 Tokens 的项目里我一开始接了 4、5 个 MCP 服务工具定义加起来接近 4 万 tokens。也就是说每一次 API 请求光工具定义就要付掉 4 万 tokens 的输入费。一个普通规模的会话跑 10 次调用光工具定义就烧掉 40 万 tokens——这还不算实际的对话内容。做法很直接用不到的工具服务全部拆掉只保留当前任务真正需要的一两个。我现在的基线配置里 MCP 服务数量控制在 1 个以内大部分任务甚至不用 MCP直接把文件路径和相关代码片段手动丢给模型就够了。别小看这个动作它对成本的影响甚至比换模型还要显著。3.3 拆任务切断无效上下文传播第三个习惯是任务拆分。过去我总是开一个大会话从头跑到尾好像这样才“连贯”。后来发现代价是一个会话越长每次携带的历史越厚成本是指数级上升的。而且很多历史信息和当前任务根本没有关系纯粹是拖着走。现在的做法是把一个大的重构任务按模块或按功能切成若干子任务每个子任务开独立会话只把相关文件和上下文放进去。子任务之间通过文件系统传递结果而不是靠同一个会话的记忆。比如我那个项目里有二十多个文件要改我按功能域拆成四个会话每个会话只负责四到六个文件平均上下文只有原来的三分之一左右总成本直接降了一半以上。拆任务还能顺便提高质量——上下文短了模型不容易被不相关信息带偏工具调用也更精准。这个结论不光适用于 DeepSeek也适用于任何模型。第三章总结起来就是一句话先压缩再瘦身最后切碎。三件事叠加总 token 消耗量才能真的降下来单价便宜才真正有意义。4. 同一批任务的实测对比与接入避坑清单到了这一步我们把“换引擎”和“上下文治理”都跑了一遍用同一批任务做了前后对比。4.1 26 美元和 2 美元的账单对账下面这张表是我那个月度账单的简化版按同一个工作量和 token 构成分别用两套方案估算计费项Tokens 量约Claude 方案估算DeepSeek 方案估算输入缓存未命中260 万7.8 美元0.73 美元缓存读取60 万0.18 美元0.04 美元输出80 万12 美元0.88 美元缓存写入、重试、计费舍入等—约 6 美元约 0.35 美元合计400 万约 26 美元约 2 美元需要说明的是具体数字在不同任务、不同模型版本下会有波动但数量级是稳定的DeepSeek 系列模型的输入、输出单价都比我原来用的 Claude 型号便宜一个数量级以上再叠加上下文治理把总 token 消耗压下去三分之一以上最终才能到 2 美元这个量级。换引擎之后我并没有感受到任务完成度有明显下降。简单重构、批量替换、写单测、补文档这类占了八成的工作它完成得很干脆。剩下两成需要深度推理的架构设计或疑难 bug 定位我才切回 Claude 负责攻坚。这种组合用法既保住了长板也把均值成本彻底压低了。4.2 从报错到稳定三次典型的翻车现场接入过程中不是一帆风顺的我记录了几个比较典型的坑希望能帮你跳过它们。第一个是上下文长度报错。网关配好之后第一次大任务跑到一半就报错提示请求超过了模型的上下文窗口。原因是 Claude Code 默认按 Claude 型号的上下文上限来管理会话长度而 DeepSeek 系列的窗口相对短一些。解决方式是适当减小 Claude Code 侧的上下文阈值配合更积极的/compact策略让会话长度始终保持在目标模型的承受范围内。第二个是工具调用静默失败。现象是模型单方面输出一大段文字说我准备做某某修改但始终没有真正执行文件操作。这个坑我在前面讲网关时已经提到最终是网关里补全了工具调用转换逻辑才解决。排查手段只有一个打开网关日志看每一条请求的响应体里是普通消息还是工具调用块逐条比对转换结果。第三个是输出风格太“含蓄”。同一个改动Claude 倾向于直接改完给出结果而 DeepSeek 模型在没有明确指令时更倾向于先告诉我“建议怎么做”。它不一定是在偷懒而是指令遵循习惯不同。解决办法也很简单在系统提示词或每条指令里明确加一句“直接实施修改不要只提供建议。”这句话能让大部分“含含蓄蓄”的行为立刻消失。4.3 路由策略与成本告警别让便宜模型“全包圆”最后聊一下分工策略。便宜模型确实能覆盖大部分工作但“全包圆”并不可取。我的路由策略大致是这样的批量修改、补注释、写测试、文档生成、迁移脚本这类重复性和确定性较高的任务全部交给 DeepSeek 系列处理架构设计、跨文件重构方案、疑难 bug 根因分析这类需要很强推理能力的任务留给我原来用的 Claude 型号处理。两者的单次调用成本差异可能高达 10 倍但后者的使用次数很低所以整体账单依然非常可控。与此同时我给网关配置了成本告警单个会话消耗超过 0.5 美元、单日总消耗超过 2 美元都会发通知给我。这不是限制任务而是防止出现某种失控状态——比如某个任务陷入无限循环调用工具等我发现的时候账单已经爆了。你也不用抄我的阈值按自己的使用强度设一个“超出正常水平”的线就行。补充一个账单统计的小知识API 平台的用量统计经常有半小时到几小时的延迟千万别因为某天晚上账单没涨就以为当天没花钱。我的习惯是第二天早上看前一天的全量数据按周做环比这样既能看到趋势也能防止短时波动误判。这轮实验跑完之后我最大的体会是省钱的钥匙不在“便宜的模型”本身而在上下文治理。单价再低如果每次都在重复搬运一个 200k 的上下文月底照样会超支。我现在养成的习惯是——长任务必拆、会话每天一清、MCP 按需开、系统提示词精简。把这四件事做好选哪个模型其实都不算贵。