说个最近被问爆的现象：很多朋友把 Claude Code 接到 DeepSeek、GLM、Qwen 这类第三方 API 上，图的是便宜、门槛低，结果一跑起来直接傻眼——官方 API 上顺顺当当的活儿，换到第三方 API 上推理速度肉眼可见地变慢，token 消耗成倍往上翻，有时候还连着报错。这真不是你配置有问题，也不是第三方模型本身多拉胯，而是 Claude Code 这套客户端骨子里就是为 Anthropic 官方 API 设计的，它默认的行为模式在第三方 API 上会放大开销。这篇文章把“慢”和“贵”的账算清楚，再给一套可以直接抄的优化方案。
1. 症状实录：第三方 API 接入后的三大异常
1.1 推理速度断崖下降：从秒回到龟速
先说我自己的实测案例。一个带 MCP 工具的中型项目，从官方 API 切到 DeepSeek，同一句指令“把这个模块的日志改成 JSON 格式输出”，官方大约 3 秒出第一个改动意见，第三方 API 直接奔着 15 秒以上，而且不是只慢那一次请求，是整个任务链条都变慢。
问题在于，Claude Code 不是“问一句答一句”的普通聊天工具，它是“要工具—拿结果—再推理—再调工具”的自主循环。每走一步都要向 API 发一个完整请求。官方 API 首 token 延迟低、服务端排队压力小，而第三方 API 普遍在首 token 延迟上就差一个量级，再叠加工具循环，体验自然断崖式下降。
你还会观察到另一个现象：第三方模型拿到 tool_use 指令后，经常不能一次给出正确结果，而是反复试错、反复请求。本来一个简单任务 5 轮调用能结束，硬是拖成 15 轮。每一轮都多等几秒，累积起来就是从“能用”变成“忍不了”。
1.2 Token 用量成倍增长：账单越看越肉疼
慢还能忍，token 暴涨才是真肉疼。同一个任务，官方 API 可能只要 5 万 token，第三方 API 跑下来 30 万甚至 50 万都不稀奇。
Token 暴涨的核心原因之一，是很多用户以为第三方 API 单价便宜就能省钱，却忽略了第三方平台基本没有 prompt caching（上下文缓存），而 Claude Code 每次请求都会完整携带系统提示词和全部历史上下文。也就是说，Claude Code 设计上依赖的“同一段前缀不重复计费”的优化，在第三方 API 上完全不存在，每次请求都是实打实全量计费。
还有个隐藏大户是工具定义。MCP 工具的 description、参数结构、枚举值，全部会注入到系统提示词里。我见过有人挂了十几个 MCP server，光工具定义就堆了两万多 token。这可是每一轮请求都要重新计费的部分。你说它是不是比金子还贵？
1.3 失败和错乱接踵而至
除了慢和贵，接第三方 API 还常伴随各种诡异报错，比如：
no api key for provider route "deepseek-official"token exchange failed: token endpoint returned status 403 forbiddenthis model's maximum context length is 1048576 tokens. howeve...sign-in could not be completed token exchange failed: error sending request
这些报错本质是配置参数与客户端预期不匹配，但反映出的深层问题是：Claude Code 的参数体系、模型路由、上下文管理逻辑，并不认第三方 API 那套“OpenAI 兼容”的世界观。你要真在上面跑通，就必须下功夫对齐配置。
2. 根因拆解：Claude Code 为什么在第三方 API 上水土不服
2.1 被迫一笔一笔付费的系统提示词
Claude Code 每次请求都会携带一套非常庞大的系统提示词，里面包含 agent 行为规则、工具调用格式、文件操作说明、输出约定等。我实测过，这套内置提示词大约在 15000 到 20000 token 区间，而且它是每次请求都完整发送的。
在官方 API 上，这个体积不会造成太大负担，因为 Anthropic 有 prompt caching，相同的前缀内容可以缓存复用，既不额外计费、也不增加太多处理时间。但切到第三方 API，这个请求体原封不动发过去，第三方既没有同样的缓存机制，又要按实际 token 数全量计费。结果就是，你每发一次请求，都等于先背着一块两万 token 的“底料”跑路，真正干活的内容可能只占几个 token。
这就是“token 暴涨”最直白的来源。你用第三方 API 跑得越多，这部分的占比就越失控。
2.2 工具调用协议差异：被迫多走一层翻译
熟悉 API 的朋友都知道，Anthropic Messages API 的工具调用走的是tool_use/tool_result结构，而 DeepSeek、GLM、Qwen 这些模型原生基本都走 OpenAI 兼容的 function calling 格式。两边协议并不一致。
当前主流打通方式有两种：一是使用厂商提供的 Anthropic 兼容端点，比如 DeepSeek 的/anthropic路径；二是用 one-api、new-api 这类网关做协议转换转发。不管哪种方式，都会引入额外的处理延迟。转换层得先把 Claude Code 的tool_use请求翻译成 OpenAI function call 的格式，等模型返回结果后再翻译回去，一来一回至少多一个 RTT。
更麻烦的是，第三方模型对工具调用的理解能力普遍弱于 Claude 官方模型。Claude Code 期待模型能够一次规划多步工具调用，但很多第三方模型每一步都要反复确认，甚至会“脑补”出不存在的命令参数，造成无效调用。无效调用越多，delay 越大，token 消耗自然也越大。
2.3 自主代理行为把消耗放大了十倍
Claude Code 默认是高度自主的执行模式，它会自己执行终端命令、读取输出、修改文件。很多人在搜“claude code 如何直接执行终端命令”，其实这个功能默认就开着，只是行为激进程度取决于权限配置。
在官方模型上，这种自主性是真的能干活。但第三方模型能力有所下降时，这个模式就变成了 token 吞金兽。终端命令的输出短则几百 token，长则上万 token，这些输出会全部塞进下一次请求的上下文。好一点的情况是命令执行成功，模型顺利进入下一步；坏一点的情况是命令失败，模型还要再读一遍报错，再想办法重试。循环往复，token 消耗如同滚雪球。
我建议所有接第三方 API 的用户，先把权限模式收紧，改成 ask 模式或者只读模式，至少先观察模型是怎么决策的，再决定要不要放开。
2.4 官方优化机制在第三方 API 上集体失效
Claude Code 官方版本内置了上下文压缩、自动精简等优化机制，但这些机制的出发点是官方模型的行为特征。切换到第三方 API 后，这些优化不仅未必生效，有些还会产生额外的开销。
比如自动压缩功能，理论上应该把长历史摘要化，但在第三方 API 上触发时机不准，经常是对话明明不长就提前压缩，压缩后模型反而丢失了关键上下文，又要重新读取文件确认现状，白跑一趟。又有一些模型上下文很长，比如某模型上限 1048576 token，但 Claude Code 默认按官方模型参数来管理上下文，结果客户端在 20 万 token 附近就提示截断或出现请求超限的 400 错误。
一句话总结：Claude Code 的全部设计假设，是“对面一定是 Claude 官方 API”。你让它去跟第三方 API 打交道，它的默认配置和默认优化全都派不上用场。
3. 影响范围与算账：慢在哪、贵在哪、谁最受伤
3.1 延迟构成拆解
拿一次普通的工具调用请求举例，把延迟拆开看，第三方 API 的劣势非常明显：
| 环节 | 官方 API | 第三方 API（典型） |
|---|---|---|
| 网络 RTT | 低 | 较高（多一跳网关或兼容层） |
| 系统提示词处理 | 有缓存优化 | 无缓存，全量处理 |
| 协议转换 | 无 | 有，增加首 token 等待 |
| 服务端排队 | 稳定、控制好 | 波动大，高峰期更明显 |
| 模型能力 | 强，工具调用准确 | 弱，容易重复试错 |
| 单任务所需轮数 | 少 | 多，甚至成倍增加 |
把这些因素叠加起来，单次请求的延迟差距看起来可能只有两三倍，但一轮完整任务的耗时可能差出五到十倍。因为轮数本身也变多了，这是一道乘法题，不是加法题。
3.2 Token 账本怎么算
Token 消耗可以套用一个公式：
单次请求 token = 系统提示词（15000~20000）+ 历史上下文（随轮数增长）+ 工具结果（每次注入）+ MCP 工具定义 × 工具数量 + 模型输出 token
在无缓存、无压缩的第三方 API 上，总消耗 = 请求次数 × 单次请求 token。如果官方 API 一轮任务要 10 次请求，第三方因为重试和轮数膨胀变成 30 次，单次请求的 token 又因为历史堆积比官方更膨胀，总量翻了五六倍属于正常，翻十倍也不意外。
算一笔账：官方上一轮 5 万 token 的任务，第三方可能跑出 30 万 token。第三方单价即便只有官方十分之一，总成本也接近官方的一半了，再加上你必须反复调试、反复验证的时间成本，省下的钱根本没多少。
3.3 不同第三方模型表现差异巨大
不是所有第三方 API 都一个样，实际体验差距很大：
| 模型/服务 | 上下文长度 | Anthropic 协议兼容 | 工具调用稳定性 |
|---|---|---|---|
| DeepSeek V3/V4 系列 | 128K~1M 不等 | 部分兼容端点可用 | 中上，编码场景尚可 |
| GLM-4 系列 | 128K | 有兼容接法 | 中等，简单任务够用 |
| Qwen 系列 | 128K 以上 | 通常需网关转换 | 中下，接近需要反复调 |
| Kimi 系列 | 128K~256K | 需网关转换 | 中等，长文本较强 |
| LocalAI 等本地推理引擎 | 看配置 | 看配置 | 较差，不建议编码场景用 |
如果你想少踩坑，尽量选有官方 Anthropic 兼容端点的服务商，别让网关在格式转换上再吃掉一层性能。还有人折腾 LocalAI 这类本地推理引擎，说实话，编码场景我不推荐接本地小模型，工具调用和代码生成能力差距太大，速度慢是其次，无效轮次带来的 token 浪费才是无底洞。
4. 实操改造：把损耗降下来的七种手段
4.1 先给上下文“减脂”
所有改造里收益最大的一个动作，就是压缩注入的上下文。请立刻检查两处：
第一，CLAUDE.md文件的体积。很多人喜欢在里面写长篇大论的项目背景、编码规范、一堆 TODO，这些内容每轮请求都会跟着发出去，每一行都是钱。建议只保留模型必须知道的关键约束，比如技术栈、构建命令、目录约定，五六行以内最好。
第二，MCP 工具数量。每挂一个 MCP server，它的工具定义就会注入系统提示词。如果只是偶尔用一两个工具，强烈建议按需启动，不要一次性挂一堆。我之前挂过文件系统、数据库、浏览器三个 server，光工具定义就多烧了将近万 token，后来只保留数据库一个，用量立刻降下来。
常用命令：Claude Code 里用/context查看当前上下文占用，随时把无关的会话内容清掉，别让上下文越滚越大。
4.2 用环境变量把参数对齐
接入第三方 API 的核心是环境变量和模型映射。这里给一份我实测可用的示例配置，以 DeepSeek 的 Anthropic 兼容端点为例：
ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic ANTHROPIC_AUTH_TOKEN=sk-xxxx ANTHROPIC_MODEL=deepseek-chat ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-chat ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-chat ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-chat ANTHROPIC_SMALL_FAST_MODEL=deepseek-chat这几行变量很关键。ANTHROPIC_BASE_URL指定了客户端请求的地址，ANTHROPIC_AUTH_TOKEN是第三方 API 的 key，后面几个都是把官方模型名映射到第三方模型名。如果不做映射，Claude Code 会默认把消息发给“opus/sonnet/haiku”这些不存在的模型名，轻则报错，重则悄悄走错路由，token 就烧在莫名其妙的地方。
配置通过.env文件或~/.claude/settings.json里的env字段加载都可以。如果你在 Ubuntu 上跑 Claude Code，注意确认 shell 环境是否真正加载了这些变量，很多报错都是环境变量没生效导致的。
4.3 收紧工具调用与轮次
第三方 API 场景下，千万别让它放飞自我。
- 用
--max-turns限制单次会话的轮数，避免模型陷入无限循环。 - 把权限模式调成 ask 或只读，让模型先给出方案和命令，由你确认后再执行，而不是默认自动执行。
- 如果只是做代码问答、方案讨论，直接用
/init或启动时加--no-tools关闭工具调用，Token 消耗能立刻降一大截。
这些限制在官方 API 上属于可有可无，但在第三方 API 上属于保命措施。工具调用每少一轮，时间和钱都能省下一份。
4.4 用 cc switch 管理多 Provider 配置
社区里常用的cc switch本质上是帮你动态维护多份环境变量配置，在 DeepSeek、GLM、Qwen 之间快速切换，不用每天手动改.env。
它的核心价值是让 provider 路由变得清晰。很多人的报错都出在“key 和路由对不上”，比如用着 DeepSeek 的 key，却把ANTHROPIC_BASE_URL指到别的服务商，然后得到no api key for provider route。cc switch 这种工具把每套 provider 的 baseURL、key、模型映射存成独立配置，切换时一次性载入，从机制上杜绝这类低级错误。
4.5 换一个更合适的客户端
如果上面这些都做了，第三方 API 的损耗还是压不下来，我的建议很直接：换客户端。
Claude Code 本身就不是为第三方 API 设计的，它的默认行为太吃官方优化。OpenCode 这类开源终端 AI 编程工具原生支持多 provider 路由，系统提示词轻得多，对 OpenAI 兼容模型更友好，还专门有“兼容推理”设置，用来规避模型在推理模式上的差异。Aider 也是老牌选择，对多模型支持扎实。
我并不是说 Claude Code 不能接第三方 API，而是说在第三方模型上，它的效率劣势是结构性的。如果你每天都要大量跑编码任务，换一个原生支持多 provider 的工具，推理速度和 token 量会有肉眼可见的改善。
4.6 检查网络层与流式响应
很多人忽略网络层对感知延迟的影响。第三方 API 的机房、网关链路跟官方不同，如果你发现请求总是要等很久才开始返回，建议确认一下访问质量。连接不稳定时，Claude Code 会超时重连，重连本身又是一轮新的 token 消耗。
另外，Claude Code 默认走 SSE 流式响应。部分第三方 API 对流式支持不完善，客户端可能要等整段响应结束才做解析，体验上会“更慢”。这种情况下，检查网关层的流式配置，或者调整客户端的超时参数，会比无脑加机器更有效。
4.7 版本更新及时跟上
Claude Code 迭代很快，官方经常修复第三方接入相关的 bug，这些修复往往不写在更新日志里，直接体现在行为改善上。如果你还在用几个月前的版本，遇到奇怪的问题先升级到最新版再排查。安装方式还是老一套：npm 全局装@anthropic-ai/claude-code，后续用内置命令升级。
5. 常见问题与排查速查表
5.1 集中盘点高频报错
我把最近高频出现在各类反馈里的报错整理成一张表，方便照着查：
| 报错/现象 | 可能原因 | 处理办法 |
|---|---|---|
no api key for provider route "deepseek-official" | key 未写入对应 provider 路由 | 用 cc switch 或.env明确 provider 与 key 对应关系 |
token exchange failed: token endpoint returned status 403 forbidden | 认证端点配置错误，或 key 没有对应权限 | 检查ANTHROPIC_BASE_URL与ANTHROPIC_AUTH_TOKEN是否匹配 |
sign-in could not be completed token exchange failed | 登录/认证服务请求本身出错 | 检查网络连通性，确认 API 地址可访问，重新生成 key |
this model's maximum context length is 1048576 tokens. howeve... | 上下文超限或客户端截断策略与模型不匹配 | 手动/compact压缩上下文，或/clear重开会话 |
| 模型回复反复重试、不断重复相同工具调用 | 第三方模型对工具指令理解不稳 | 收紧权限模式，限制--max-turns，换成 Anthropic 兼容端点 |
| 响应迟迟不出第一个字 | 流式或网关转换导致首 token 延迟高 | 检查流式配置、网络质量，必要时换兼容端点 |
5.2 排查步骤优先级
遇到问题别一上来就改配置，按这个顺序查，能省不少时间：
第一步，确认环境变量真的加载了。很多人在.env写了配置，但没 source 或者服务没重启，等于白写。在终端里env | grep ANTHROPIC看一眼最实在。
第二步，用 curl 直接打一次 API，看返回是否正常。这一步能快速区分是客户端问题还是服务端问题。如果你连 curl 都拿到 4xx，就别折腾 Claude Code 了，先解决 API 接入问题。
第三步，检查上下文占用。用/context看当前 token 数，如果已经很高，先/compact或/clear再跑，避免把问题归因到别处。
第四步，限制变量逐项排查。把模型映射、baseURL、key、工具权限四个维度拆开，一次只改一个变量再测，能精准定位问题来源。
5.3 一些踩坑后总结的经验
最后分享几条我自己常驻的经验。
第一，接入第三方 API 时，不要追求“能跑”，要追求“配置透明”。每一条环境变量的来源和去向都要清楚，尤其模型映射，少配一个就可能在请求里发错模型名，然后得到一个让人摸不着头脑的报错。
第二，默认把工具调用权限收紧，需要时再放开。第三方模型在自由模式下容易产生大量无效操作，限制权限不是降低效率，而是避免浪费时间精力和 token。
第三，如果发现 token 用量异常，第一时间查上下文，而不是调模型。绝大多数异常膨胀，都出在系统提示词和工具定义这种“摩擦成本”上，跟模型本身关系不大。
说实话，Claude Code 接第三方 API 这件事本身不是不行，但它天生带着官方 API 的优化烙印。你能做的，就是尽量抹平这些不匹配带来的消耗。先在上下文减脂、参数对齐、权限收紧这三步上下功夫，多数问题能缓解一大半。如果还不行，就果断换原生支持多 provider 的客户端，别跟一个不合适自己的工具死磕——这年头，能干活儿、成本可控的工具才是好工具。
