Claude Code 成本暴跌 92%：从 26 美元到 2 美元的 API 降本实践

上个月我把一个攒了很久的个人项目丢给 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 的构成看隐形开销

我那个月的用量，从平台账单里拆出来大概是这个结构：

如果你发现自己也处于类似的构成比例，那说明主要开销来源是“反复搬运上下文”，而不是“模型思考太多次”。这正是 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_URL="http://127.0.0.1:8787" # 网关侧统一拿这个 key 去调用 DeepSeek API export ANTHROPIC_AUTH_TOKEN="sk-your-deepseek-key" # 告诉 Claude Code 当前用的模型名，最终由网关做映射 export ANTHROPIC_MODEL="deepseek-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 构成，分别用两套方案估算：

需要说明的是，具体数字在不同任务、不同模型版本下会有波动，但数量级是稳定的：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 按需开、系统提示词精简。把这四件事做好，选哪个模型其实都不算贵。