我把 DeepSeek 接进 Claude Code一个改 bug 的小任务跑了快十分钟回来一看用量统计token 消耗是用官方 API 时的十几倍。这是我最近在开发者群里看到频率最高的抱怨之一。说实话Claude Code 本身并没有“针对第三方 API 变慢”的功能但当你把任何 Anthropic 兼容端点接到这个 CLI 工具里就会发现模型推理变慢、token 用量暴涨几乎是必然的。这个现象不是玄学也不是某个 API 服务商故意限速而是 Claude Code 的架构设计、提示词协议、工具调用机制加上第三方模型的格式遵循能力共同作用的结果。这篇分享我会从根因拆到实操先讲清楚为什么慢、为什么烧 token再给一套我实测过、可复现的调优与基准测试方案。适合正在把第三方模型接入 Claude Code 做日常编程辅助的人也适合被 token 账单吓到、想搞清楚钱花在哪的人。1. 先盘现象慢在哪个瞬间token 又是怎么“暴涨”的1.1 三个典型现场帮你对号入座先别急着调参先确定你遇到的是哪一种“慢”。我观察到的第三方 API 接入 Claude Code 后的异常基本可以归成三类。第一类是“首响应极慢”。你发出一个指令Claude Code 界面上的状态指示器转了好几圈几十秒甚至一两分钟都没有任何输出。这种慢不是模型生成慢而是请求在服务端排队、或者在 prefill预填充处理阶段花掉了大量时间。第二类是“过程卡顿”。任务执行倒是没有完全卡死但每完成一个小步骤都要停顿几秒甚至十几秒才开始下一步整体节奏像老式幻灯片。如果你在日志里打开 verbose 模式会发现每个工具调用之间都有明显的空白期。第三类是“空转”。模型在反复读取同一个文件、反复列出同一个目录或者生成了大段解释性文字但迟迟不调用工具。这种情况下 CPU 没闲着但做的都是无用功。至于 token“暴涨”大部分人的体感是同样一个任务用官方 API 跑一遍可能消耗 200k token换成第三方模型直接飙到 1M 甚至更多或者任务没干多少事上下文的滚动速度却快得吓人聊着聊着就触发 context compaction上下文压缩然后压缩后又很快再次触顶。1.2 “慢”和“token 暴涨”是同一个根因的两面我最早排查这个问题时也一度把它们当成两个独立故障结果发现是同一个根因的两面。Claude Code 的工作方式决定了每一次模型调用都要携带一份庞大的上下文。系统提示词、工具定义、历史消息、项目文件内容全都堆在一次请求里。第三方 API 在服务端要读完这么厚的请求才能开始生成于是你感受到的“慢”就出现了而同一份请求每多调用一次模型就多计一次完整 token 费。当模型因为不理解工具格式而反复试探、反复出错时请求轮数成倍增加token 自然就“暴涨”了。所以后面所有分析都围绕同一个核心问题第三方模型在 Claude Code 的协议框架下用比官方模型更多的轮数、更大的上下文体量完成了相同的事情。轮数多了总耗时增加每一轮携带的内容多了总 token 增加。这两者在数学上是相乘的关系不是相加。2. Claude Code 的 harness 架构为什么专为官方模型“定制”2.1 两层提示词协议orchestrator 与 task agent想要理解 token 为什么涨先得理解 Claude Code 不是“一个模型在跟你对话”而是一套多代理协作系统。当你给它一个稍微复杂的任务时它内部会拆出 orchestrator总控和多个 task agent子代理。总控负责规划、拆解任务、决定下一步调用哪个工具子代理被派去改文件、读代码、执行命令然后把结果回传。这个架构的代价是子代理需要继承主上下文总控又需要等待子代理的结果。每一次任务切换、每一次子代理启动都会带来额外的上下文拷贝token 就在这些交接中不断膨胀。第三方模型如果本身对“子代理指令遵循”不敏感还会出现总控让子代理跑偏、子代理返回一堆无关信息、总控再重新规划的情况等于白白消耗了一整轮的输入 token。更麻烦的是这个架构默认是为 Claude 系列的指令遵循能力设计的。官方模型被训练成“拿到子代理指令就立刻执行只在必要时汇报中间结果”但不少第三方模型更习惯“长篇解释再做决定”于是它们会在子代理环节输出大段推理而这些推理对任务没有任何帮助只会堆进上下文。2.2 工具调用协议XML 式的函数调用对第三方模型并不友好Claude Code 的工具调用走的是 Anthropic 生态的 XML 风格协议模型需要输出结构化的 tool_use 块Claude Code 再解析这些块去真正执行工具。问题在于Anthropic 官方模型对这种协议的训练量非常充足模型天然知道“该给函数传哪些参数、如何在多个工具之间抉择、什么时候需要 parallel tool use”。而第三方模型大多是在 OpenAI 风格的 function calling 数据上训练的接到 Anthropic 格式后虽然通常也能生成可解析的块但稳定性差很多。我实测中最常见的情况有三种一是模型生成了格式合法但语义错误的调用比如读文件时把路径参数写错Claude Code 执行报错模型被迫重新生成二是模型倾向于“一次只调一个工具”而官方模型会并行调用多个独立工具这导致相同任务下第三方模型的轮数多出好几倍三是模型有时会生成两套工具调用一段放在思考里一段放在正式回复里Claude Code 只认正式部分思考里的那部分成了纯浪费。这些差异累积起来很可怕。每多一次报错重试就要重新发送整段上下文每少一次并行就多一轮完整请求。第三方模型在工具协议上的不熟练是 token 膨胀的第一大来源。2.3 官方模型被“调教”过的行为习惯第三方模型很难复刻除了工具协议本身Claude 系列在代码场景还有一些“行为习惯”这些习惯其实是 Anthropic 在训练时特意强化的用户往往感知不到但换到第三方模型时就会立刻露出破绽。比如官方模型倾向于“只读必要片段”。它拿到一个文件路径后会先读文件头部、搜索关键符号、再看相关函数定义而不是把整个文件全部灌进上下文。第三方模型更常见的是“读全文件、列全目录”生怕漏掉信息。一次两次没关系当代码库规模一大行为差异直接体现在上下文总量上。再比如官方模型有很好的“错误恢复习惯”。工具执行报错时它会基于错误信息做小步修正而不是重新读一遍所有材料。第三方模型在遇到报错时往往会“退回到更大范围的上下文”——重新列出目录、重新读文件、把之前所有结论推翻重来。这种回退式行为是 token 消耗的第二大来源。所以你会发现即便第三方模型本身能力不差放进 Claude Code 这个“为官方模型量身定制”的框架里也会因为行为模式不匹配而显得又笨又贵。3. 把一次请求拆开看 token 到底流向了哪里3.1 请求体的四个组成部分谁在持续膨胀很多人以为 token 用量主要由“我说的自然语言”决定这是误解。在 Claude Code 里你每一次模型调用请求体由四部分构成系统提示词Claude Code 内置的一整套行为规范包含角色定位、工作方式、输出要求这部分是非常大的固定开销。**工具定义**所有可用工具的 schema 描述也就是“模型可以调用哪些函数、函数长什么样、参数有哪些”这也是一块很大的固定开销。会话历史从任务开始至今的所有消息包括你的话、模型的回复、工具执行结果。当前上下文刚读入的文件内容、最新执行命令的输出、最近一次工具报错等。前两部分对官方模型来说可以通过 Anthropic 的 prompt caching 大幅降低费用对不支持缓存的第三方 API 来说它们会原封不动地出现在每一次请求里。而会话历史是线性增长的任务执行越久、工具调用越多这部分就越膨胀。3.2 输出侧思考块、工具调用文本与重复啰嗦输入侧已经够大了输出侧的问题更隐蔽。Claude 官方模型有一种“预算式思考”的机制在后台用专门的 reasoning 通道进行推理而 CLaude Code 可以设置是否让用户看到推理过程。但当你换成第三方模型时往往不存在这个隐藏通道——模型的思考会以普通文本的形式直接生成出来然后这些文本又成为下一轮请求的输入。换句话说官方模型可以“偷偷想”第三方模型只能“大声想”。想得越多token 就越多而且这些想法还会污染后面的上下文。如果第三方模型还有长推理解码能力比如用了 CoT 风格的数据训练输出长度会更失控。我见过一个极端的例子让模型修一个简单的正则错误它在动手前足足输出了几千 token 的“推理”其中包括了它对正则表达式语义的完整分析而这段分析对工具的最终调用没有任何帮助。3.3 一个第三方模型接入后的实测 token 画像示例数据下面用我做过的一组粗糙实测来说明任务统一是“在一个大约 1.5 万行的中型 Python 项目里定位一个数据竞态 bug 并修复”模型分别用官方 Claude 和某第三方代码模型都能完成但画像完全不同观测项官方 Claude第三方模型总请求轮数38 次117 次工具调用次数31 次142 次总输入 token约 900k约 2.8M总输出 token约 180k约 960k总耗时约 4 分钟约 22 分钟注意这不是严谨的评测任务不同结果差异极大但趋势非常稳定第三方模型的请求轮数、工具调用次数和输出 token 都会有数量级的上升。输入 token 的上升主要靠轮数驱动输出 token 的上升则是模型“爱写解释”的体现。这张表也解释了为什么很多人在账单出来后会吓一跳第三方 API 往往单价确实比官方便宜但消耗量是官方的好几倍甚至十几倍最后总成本不一定省多少速度还慢了五倍。3.4 缓存机制差异放大了三到十倍的成本差官方 Claude 费用并不是你印象中的“每百万 token 多少美元”那么贵因为 Anthropic 有 prompt caching同一段系统提示词和工具定义在短时间内重复使用可以按缓存命中的低价计费并且缓存命中的请求响应也更快。第三方 API 绝大多数不支持这个机制或者即便支持缓存策略也和 Anthropic 的风格不一样。比如有的模型服务是按字符数直接计费有的把“缓存 token”也按原价收有的缓存过期时间非常短Claude Code 一次任务跑十几分钟缓存早就失效了。这意味着同样的固定开销系统提示词 工具定义官方模型可能只按几十 k token 的有效成本计算第三方模型则每次请求都按全价算。这部分差距不是模型能力造成的纯粹是计费机制错配。你在对比“官方贵还是第三方贵”时如果只比较单 token 单价会严重低估官方模型的性价比。这也是“token 暴涨”里最冤的一部分。4. 为什么第三方 API 在 Claude Code 里感觉“特别慢”五个硬瓶颈4.1 TTFB 与 prefill上下文越长等第一个字越久当你发出一个请求第三方模型的 API 要做的事是接收请求体 - 处理前缀提示prefill- 开始逐字生成。prefill 阶段需要把所有输入的 token 跑一遍 transformer上下文越长这个阶段越慢。Claude Code 恰恰是“把大量上下文塞进一次请求”的专家于是你在第三方 API 上遇到了最糟的组合足够长的上下文加上不够快的 prefill 引擎。生活类比一下你请一位师傅修水管每次都要先让他读完整本维修手册再加一大叠历史维修记录他才能动手。手册越厚、记录越多他进入正题就越慢。官方模型等于已经把这本手册背熟了第三方模型每次都要从头翻一遍。这个延迟差异你跟模型自己的 prompt playground 对比时尤其明显在网页上随便问一句第三方模型挺快的一旦通过 Claude Code 接入上下文从几百 token 变成几十万 tokenprefill 时间就开始以秒甚至分钟计。4.2 流式输出的缺失不是不响是“攒着一口气说完”Claude Code 默认走流式SSE输出期望模型一边生成一边吐结果。官方 API 对这个模式的适配非常到位用户看到的是“字在蹦出来”的即时反馈。第三方 API 的流式实现往往不稳定或者压根只是“伪流式”服务端等全部生成完再一次性吐给你。表现就是你这边半天没动静突然整段文本刷出来然后立刻进入工具调用阶段。由于 Claude Code 的工具执行依赖完整输出块模型要先把全部文本生成完harness 才能解析并执行工具所以你感知到的延迟就是“完整生成全部回复”的耗时而不是首 token 延迟。4.3 上下文触顶后的连锁反应裁剪、遗忘、重读Claude Code 默认按官方模型的大上下文窗口设计会话管理策略。它假设模型能容纳非常长的对话历史所以“聊到一半自动压缩”这件事并不常发生。但不少第三方模型的上下文窗口更小比如 64K、128K在 Claude Code 生成长会话时很容易触顶。一旦触顶第三方 API 通常会返回 contextual timeout 或者 context length exceeded 错误Claude Code 的应对方式就是裁剪历史compaction只保留总结后的精华再重新发起请求。这个总结过程本身又是一轮大输出。更糟的是裁剪后的摘要经常丢掉关键细节导致模型后续对代码的理解出错于是又回到“重读文件、重跑命令”的循环里。这就是为什么有些任务越跑越慢它在反复做“触顶 - 压缩 - 遗忘 - 重读”的循环每一步都在烧 token每一步都在拉长耗时。4.4 并发调用与限流多个子代理互相抢额度Claude Code 在执行任务时如果并行度允许会同时发出多个工具调用或同时运行多个子代理。这个设计在官方 API 的高配额下毫无压力但第三方 API 的配额通常按 RPM每分钟请求数和 TPM每分钟 token 数限制远低于官方。一旦并发数撞上第三方限流API 会返回 429 或者连接超时。Claude Code 收到错误后会退避重试而重试意味着同一份请求再发一遍token 再计一次。如果任务规模大并发触顶几乎是必然的。这时候你看到的“慢”是排队慢请求在服务端排队或者在客户端退避等待。表面看起来是模型不行实际上是配额被自己的并发策略吃光了。4.5 单次输出限制的错配模型被迫用更多轮次完成同一件事官方模型的单次最大输出 token 可以设得很高Claude Code 默认给的输出预算也比较宽松。第三方模型服务里有些会把单次输出限制在 2K、4K 之类的低档位理由是避免超额算力消耗。这个小限制在普通对话里无所谓但在 Claude Code 里是致命的模型本来就话多还要在有限的输出额度里完成“思考 工具调用 结果说明”往往没说完就被截断Claude Code 拿到的输出块可能是不完整的。结果就是模型需要分两轮、三轮才能把本可以一轮干完的事干完轮数翻倍token 也随之翻倍。5. 实操优化把第三方 API 在 Claude Code 里的成本速度调到能用的程度5.1 模型选型标准代码专项能力优先于通用 chat 能力不是所有第三方模型都适合塞进 Claude Code。我踩过几次坑之后总结出的选型优先级是代码专项能力 格式遵循能力 上下文窗口 价格 通用对话能力。一个模型在工具体系里的“格式遵循能力”往往比它的通用智商更重要因为它直接决定了工具调用的稳定性和轮数。选型时哪怕模型推理能力稍弱只要工具调用准确率高整体体验反而更好。我建议用小规模的“重活”测试比如让它用 Claude Code 改一个已知 bug观察它调用工具的链路是否短路。5.2 必须改的配置项和环境变量这里列一份我实测后收益最大的配置清单。首先是环境变量在接入第三方兼容端点时这样设置export ANTHROPIC_BASE_URLhttps://your-third-party-endpoint export ANTHROPIC_MODELyour-model-id export ANTHROPIC_AUTH_TOKENyour-api-key这里有个容易被忽略的点确认你的第三方端点是否对/v1/messages这个路径做了完整的 Anthropic 兼容。有些服务只兼容了简单的对话补全工具调用和流式支持得很差直接决定了慢和 token 浪费的程度。其次是输出限制如果账号允许把单次输出调高一些export CLAUDE_CODE_MAX_OUTPUT_TOKENS8192这个值通常能缓解 4.5 里提到的“没说完就被截断”问题。我甚至见过有文章把它调到 16000效果更彻底但对模型的输出稳定性要求更高。第三方模型如果容易在超长输出下偏离格式就维持 8192 最稳。再次是在交互界面里调整 thinking budget。Claude Code 有/config命令里面可以设置思考预预算。第三方模型往往没有官方的隐藏推理通道把 thinking 预算调低或直接关闭反而能减少“大声想”的文本量。最后删掉不必要的 Prompt 附加内容、关闭自动更新检查之类的杂项能小幅降低请求体。虽然这部分不是大头但每一个 token 在第三方 API 的高轮数模式里都会被放大。5.3 会“省 token”的会话管理习惯调参数只能解决固定开销真正决定 token 总量的是会话历史的管理习惯。我这里说的不是魔法而是一套省 token 的工作流。第一及时拆任务。Claude Code 的会话历史是滚动的一个会话里塞的任务越多历史越臃肿。单个任务做完就/clear让下一次任务从零开始。第二善用上下文压缩。感到对话变卡、token 消耗变快时手动执行/compact比让系统自动压缩更可控你可以选择保留哪些关键结论。第三控制文件读取范围。先让模型读目录结构再精确读目标文件不要一上来就整个大文件夹。Claude Code 里大文件的直接注入非常烧 token很多人的 token 暴涨就是这么来的。第四别让模型“确认”每一件事。Claude Code 默认会在关键操作前征求确认这个交互过程非常烧 token。如果你对工具行为有信心可以在会话里让它开启自动批准相关操作省掉一长串确认对话。5.4 中间层代理能解决什么、不能解决什么有人会建议你在 Claude Code 和第三方 API 之间再加一层代理把请求格式转换、缓存、限流、密钥管理都包起来。这类方案确实能解决一些问题但你要分清哪些是它能解决的哪些不能。能解决的是缓存。如果你自己构建的代理层对相同请求体做了一层缓存可以明显降低重复的 prefill 时间和输入 token 费用。不过要注意Claude Code 每次请求体几乎都不同历史的滚动导致缓存命中率实际没有想象中高。能解决的还有格式转换把 Anthropic 风格工具调用转换成符合目标模型的格式这能提升工具的稳定性还有配额调度通过排队和重试策略消化并发限制。不能解决的是模型本身在工具协议上的不稳定和“话痨”倾向。代理可以把格式转正确但没法让模型少说话、少犯错、少走弯路。所以中间层是优化手段不是银弹。5.5 什么时候该果断放弃第三方 API 路线聊到这一步我给你泼点冷水。第三方 API 适合的是“低频、轻量、对成本高度敏感”的代码辅助场景。比如你只是偶尔让 Claude Code 帮你补全片段、做简单解释、写测试用例这类任务闭环短、轮数少第三方模型的吃相还看得过去。但如果你要让 Claude Code 做复杂的跨文件重构、长链路排错、多文件迭代第三方模型在协议遵循和行为习惯上的短板会被放大到不可接受。我测过几个场景结论很一致代码库越大、任务链路越长第三方模型相对官方模型的效率差距越大。刚开始一个简单的改动差距可能只有两倍但当任务复杂度上升差距能拉到五倍以上。一个低成本判断方法任务超过 20 个工具调用还没收敛果断换回官方模型。第三方 API 的省钱逻辑在长任务里几乎不成立。6. 自己动手做一个接入基准测试替换前先量化6.1 固定任务、固定代码库、固定观测指标我强烈建议你在正式把某个第三方 API 接入 Claude Code 之前先跑一遍标准化的基准测试。这套基准我用了很久关键点就是“三个固定”固定一个小代码库比如开源项目里一个几十文件的中型模块固定的一个任务比如“解释数据流并修复一个内存泄漏”固定的观测指标。观测指标至少要有完成耗时、总输入 token、总输出 token、工具调用次数、请求轮数、报错重试次数。前两个是结果后四个是根因。你拿到手后会发现不同模型在同一个任务上的差异非常直观。对比时还要加一组“对照组”同一个任务先用官方模型跑一遍再换第三方模型。没有对照组你很难说清慢和贵是模型问题还是任务本身的问题。6.2 一张表格跑完三组对照实验我习惯用下面这样的表格记录你直接抄就行指标官方模型第三方模型 A第三方模型 B总耗时分钟3.215.88.1请求轮数269451工具调用次数2313168报错重试次数1245输入 tokenk7802,1001,150输出 tokenk170720490估算费用按各平台价约 X 元约 2X 元约 1.2X 元注意费用换算不要只看单价要把总 token 乘单价再加报错重试的惩罚。第三步我会讲这个公式。6.3 如何把 token 用量换算成费用并预估重试惩罚很多人的成本核算方法是错的他们拿官方模型和第三方模型各自的每百万 token 单价直接对比然后得出“第三方便宜 90%”的结论。但真正算成本要按“一次完整任务的加权消耗”来算任务总费用 ≈ 输入 token × 输入单价 输出 token × 输出单价 每条报错重试的输入 token × 输入单价重试惩罚尤其容易被低估。一次工具报错意味着上一轮输出白费还要重新发送整段上下文让模型重新生成。第三方模型的报错重试率如果从 1% 涨到 20%对总费用的影响是指数级的。我见过一个很搞笑的项目一个第三方 API 单 token 单价确实只有官方的十分之一但在 Claude Code 里跑同样的任务token 用量是官方的十二倍报错重试率还高得吓人最终实际花费反而更多。基准测试的意义就在这里帮你提前避开这种“看着便宜、用着更贵”的坑。7. 我自己的选择与一点额外提醒跑完这么多对照我现在采用的双轨策略是日常轻量任务走第三方模型用/clear频繁切会话严格控制任务长度token 成本确实能压到官方模型的五分之一以内但一旦遇到跨文件重构、疑难 bug 排错、大范围代码审查这类“重任务”我立刻切回官方模型绝不犹豫。这个切换的成本比在第三方模型上反复折腾要低得多。最后提醒一个容易忽略的细节登录和刷新 token 报错与 API 鉴权 token 是两码事。Claude Code 里有自己的账号登录机制报错会提到 refresh token 或 sign-in could not be completed这属于 CLI 自身的认证流程问题跟你接入第三方 API 时设置的ANTHROPIC_AUTH_TOKEN没有关系。别混在一起排查否则会浪费大量时间。第三方 API 接入 Claude Code 这件事本质上不是不能做而是别在长任务上硬扛。掌握上下文管理、合理配置参数、先基准后接入就能把它真正变成省钱的工具而不是烧钱又费时的计时炸弹。