最近我把 Claude Code 的接入方式从官方 API 切到了第三方 API 服务本想省点成本结果发现两个特别头疼的问题推理响应明显变慢token 用量呼呼往上涨。跑了不到两天一个本来很简单的代码库扫描任务账单比官方直连还贵速度还慢了一倍不止。这个现象在社区里其实挺常见很多人一遇到就怪第三方服务不稳定但实际排查下来问题往往出在 Claude Code 自身的调用策略和第三方 API 的兼容层上。我花了两天时间把整个链路重新梳理了一遍从网络请求到会话上下文管理再到本地推理引擎localai、LMStudio 这类的配置最后总算是把速度拉了回来token 消耗也降到了原来的三分之一左右。这篇文章不打算讲官方文档里那些套话只想把踩过的坑、排查的思路、以及最后真正有效的配置改动都摊开说希望能帮到正在用 Claude Code 接非官方 API 的朋友。1. 先从根上理解为什么第三方 API 会同时拖累速度和 token1.1 Claude Code 的调用机制和你想的可能不太一样很多人以为 Claude Code 就是一个把聊天窗口搬到终端里的工具每次提问就发一次请求然后等结果。实际不是这样。Claude Code 是一个编码代理coding agent它的工作方式是你给它一个任务它会自己规划步骤然后反复调用工具读文件、跑测试、执行命令每一步都可能触发一次完整的 API 请求。这意味着一个简单的“找出项目里所有遗留的 TODO 并汇总”任务可能产生 5-10 次 API 往返。每次往返都会把当前会话的完整上下文重新发一遍——系统提示词、工具定义、历史消息、文件内容片段全都要跟着请求走。这就是 Claude Code 的 API 请求模式不是单次对话而是多轮、大上下文、高频的序列请求。明白了这一点再看第三方 API 变慢和 token 暴涨就顺理成章了。任何影响“单次请求响应速度”或“单次请求上下文计费规则”的因素都会被放大 5 倍、10 倍。1.2 第三方 API 的三种常见形态问题各不相同我梳理了一下大家常用的第三方接入无非这三种本地推理引擎localai、LMStudio、ollama 这类跑在自己机器上通过兼容 OpenAI 或 Anthropic 协议的接口给 Claude Code 用。统一接入服务企业或者个人自建的一层聚合入口背后接多个模型按路由规则分发请求。模型服务商提供的兼容接口本身不是 Anthropic 官方但提供了 Anthropic 协议兼容的 endpoint。这三种形态各有利弊。本地推理引擎的好处是数据不出本机但硬件算力有限slow 是常态统一接入服务方便多模型切换但如果它的兼容层实现得不完整各种诡异问题就来了第三方兼容接口通常最便宜但上下文缓存、流式传输这类细节往往支持不全。我这次遇到的典型组合是Claude Code 默认走官方协议但接到本地推理引擎localai上同时某些请求又被路由到了第三方兼容接口。两边行为不一致token 统计和服务端缓存的逻辑全乱了看起来就像是“API 让推理变慢、token 暴涨”。1.3 慢和贵其实是两个独立的问题但会互相强化先说慢。推理慢的本质是请求在网络上多绕了几跳加上服务端排队、模型 prefill 和 decode 的时间。第三方 API 如果支持流式输出Claude Code 可以在第一个 token 生成时就拿到数据体感上就不会太差但如果不支持流式或者网关把流式响应缓存成了完整 JSON 再一次性返回那么你等到的就是“全部生成完网络传输完”的时间体感差距会非常大。再说贵。token 暴涨的根源几乎都出在上下文重发上。Claude Code 的会话上下文本来就大官方 API 会利用 prompt caching 让重复发送的前缀打折扣但第三方 API 如果不支持缓存每一轮请求都按完整 token 数全额计费多轮会话一累积token 用量就会爆炸式增长。更麻烦的是慢和贵还会互相强化。因为响应慢用户往往会让 Claude Code 重试或者重复提交每次重试都是一次新的上下文重发token 继续涨。token 涨多了之后上下文接近模型窗口上限又会触发压缩或截断导致信息丢失、模型重新生成不必要的内容又更慢。这就是一个恶性循环。2. 推理变慢别急着甩锅给 API先按这条路排查2.1 先把“慢”拆开TTFB 和生成速度是两码事我调试这类问题有个习惯先把一次请求拆成两个阶段看第一个阶段是“首 token 等待时间”TTFB也就是你发出请求到收到第一个 token 的时间第二个阶段是“生成阶段”也就是第一个 token 到最后一个 token 的时间。这两个阶段慢的原因完全不同。TTFB 慢通常不是模型本身的问题而是网络链路、服务端排队、以及请求的 prefill 处理慢。生成阶段慢才是模型推理算力的问题。怎么拆很简单用 curl 直接打第三方 API 的接口开流式把时间戳打出来看。我试过用一个固定 prompt比如“写一首关于秋天的诗”先测官方 API 的 TTFB 和总耗时再测第三方 API 的。两者一对比问题在哪一段就清楚了。2.2 第三方 API 慢的真正原因prefill 耗时、流式关闭、并发排队从我的实测来看第三方 API 变慢最常见的原因有三个。第一个是 prefill 阶段太慢。LLM 处理请求时要先把你发来的所有输入 token 算一遍注意力这个过程叫 prefill。上下文越大prefill 越慢。Claude Code 的请求动不动就几万 token第三方服务如果架构上对长上下文支持不好prefill 时间可能占据整个请求的 70%。你可以把 prefill 类比成考试前把整张卷子从头读一遍如果题目有 5 万 token读题就要读半天还没开始写答案呢时间已经过去不少了。第二个是流式传输被吞掉了。有些第三方接入层为了做计费统计或者日志记录会把模型的流式输出攒成完整一段再返回给 Claude Code。表面上你调的是支持流式的接口实际上拿到的是整个 JSON 一次性返回。Claude Code 本身是流式渲染的一旦变成非流式它必须等全部内容到达才能开始显示体验自然就特别拖。第三个问题是并发排队。Claude Code 的很多操作是并发的——比如同时读多个文件、同时跑多个搜索。第三方 API 如果限制了并发数后面的请求就得排队。排队久了Claude Code 会超时重试重试又加剧排队恶性循环。2.3 实测排查清单五分钟定位卡点我整理了一份自己的排查顺序照着走基本能定位到问题层先裸测接口用 curl 直接请求第三方 API加上--no-buffer参数观察流式输出是否正常记录 TTFB 和总耗时。换一个极小的上下文测试用一个只有几个 token 的 prompt 请求相同模型看 TTFB 是否明显下降。如果上下文小的时候很快、上下文大的时候突然变慢说明瓶颈在 prefill/上下文处理不在网络。看服务端日志localai 和 LMStudio 都会打印请求处理时间重点看 prefill 时间和 decode 时间分别用了多少。用/status查看当前上下文占用如果上下文已经用了 80% 甚至 100%先/compact压缩会话再继续测试排除上下文过满导致的重试和截断。我遇到的实际情况是本地推理引擎的 prefill 占了总耗时的 80% 以上而且因为显存带宽不够长上下文处理特别吃力。后来我把上下文从“无限”手动限制到 32k 以内速度立刻提升了一个档次。3. token 暴涨的元凶上下文重发、缓存缺失和工具调用开销3.1 为什么同一个任务官方 API 便宜第三方 API 就爆token 暴涨这事我第一次意识到严重性是在跑了一个 30 分钟的小任务后看了一眼统计震惊了——消耗的 token 量竟然是任务里实际生成内容的一百多倍。问题就出在“重复发送的上下文”上。Claude Code 是多轮代理式调用每执行一个工具调用就要把到目前为止的整个对话历史重新发给模型。如果一次任务产生了 20 次工具调用而对话历史在不断增加那么最终消耗的 token 大体等于“每一次请求的累计上下文之和”而不是“最终那一次请求的上下文”。我举个例子假设任务开始时上下文是 60k token之后每轮新增 5k一共 20 轮。总消耗大约是每轮上下文之和大概是 20×60k 5k×(12...19)等于 1.2M 950k合计约 2.15M token。也就是说你只写出了大约 100k 的内容账单上却是两百万 token。官方 API 之所以便宜是因为它对重复的前缀做了 prompt caching缓存的输入 token 计费大约只有非缓存价格的十分之一。一个连续多轮的会话里大量前缀是重复的命中缓存就是省钱。但第三方 API 如果没实现 prompt caching这些重复前缀全都按全价计费这就是 token 暴涨最直接的元凶。3.2 工具定义和系统提示词也是一个隐藏大户我一度以为是历史消息撑大了上下文后来用/cost一查发现工具定义的开销同样惊人。Claude Code 自带的工具非常多——文件编辑、搜索、执行命令、网页搜索每个工具都有完整的 JSON Schema 描述。这些工具定义是每轮请求都要发的加起来就有 3-5k token。系统提示词也一样。Claude Code 每次启动都要加载系统提示词如果你配置了 CLAUDE.md 和自定义指令系统提示词会更长。在 20 轮请求的任务中光系统提示词工具定义就要重发 20 次积少成多3k token 也会变成 60k。这还不算一些第三方 API 会在服务端额外注入自己的系统提示词比如“你是某某模型的翻译器”这类说明。这些注入的隐藏 token 不会显示在你本地的 cost 统计里但会算在消费里导致你看到用量和实际计费对不上。3.3 怎么算清楚一笔 token 账手动拆解一个实战案例光说理论太虚我拿一个真实任务拆给你看。任务内容是“扫描当前项目所有 Python 文件找出没有类型注解的函数定义”。这个任务看起来很小但 Claude Code 的运作方式是先发送一次请求包含系统提示词、工具定义、用户任务初始上下文约 65k token然后调用工具Grep搜索文件工具结果返回约 2k token此时上下文变成 67k连续请求接着调用Read读取某个文件文件内容返回约 8k token上下文变成 75k又读第二个文件累计 83k最后汇总结果写回复累计 85k。一共 5 轮请求实际生成的内容只有最后那一段回复约 1.5k token。算一下总消耗第 1 轮65k第 2 轮67k第 3 轮75k第 4 轮83k第 5 轮85k合计大约 375k token。如果官方 API 带缓存重复前缀可以打一折实际计费可能只有纯新增部分的 token大约 30-40k而第三方 API 没有缓存的话就是 375k 全额计费。同样一个任务差距 10 倍。我后来用/cost查了一下这个任务实际消耗是 38 万 token 出头和估算吻合。如果你也有“任务明明很小token 却大得离谱”的困惑十有八九就是上下文重发没有缓存的问题。4. 实操优化把第三方 API 的配置调成“省钱省时”模式4.1 先检查环境变量接入地址和模型路由别搞错很多时候慢和 token 暴涨其实是环境变量配置不规范。我整理了一份推荐配置放在 Claude Code 的settings.json里{ env: { ANTHROPIC_BASE_URL: http://127.0.0.1:8080/anthropic, ANTHROPIC_AUTH_TOKEN: local-dev-token, ANTHROPIC_MODEL: local-model, ANTHROPIC_SMALL_FAST_MODEL: local-model }, apiKeyHelper: local-dev-token }说几个容易踩的坑。ANTHROPIC_BASE_URL一定不要加多余路径具体对接的是/v1/messages还是/anthropic/v1/messages要以第三方服务的文档为准。路径差一层请求直接 404然后 Claude Code 会无限重试看起来像是“API 变慢”其实根本没通。ANTHROPIC_MODEL也要和第三方服务的模型列表对齐。我遇到过一个报错提示llm-deepseek: no api key for provider route deepseek-official查了半天原因是我把模型名填成了服务商内部的 provider 路由名但接入层找不到对应的 API key 配置。正确做法是填你在该服务里实际创建的模型别名。4.2 限制工具爆炸减少无效往返就能省大量 token上一节算过账工具调用轮次是最主要的 token 消耗驱动者。那么为了省 token核心手段就是减少无效的工具调用。我试过几个有效办法。第一是清理不必要的工具。Claude Code 支持在settings.json里配置允许的工具白名单比如我只让它用Read、Grep、Glob和Bash把网页搜索、文件编辑这类在这个项目里用不到的工具全部关掉。工具定义少了每轮请求的 token 就少了模型也不容易瞎调用。第二是在 CLAUDE.md 里写清楚约束。比如写上“先使用 Glob 和 Grep 搜索再决定是否读取文件不要一次性读取整个目录不要用 Bash 运行项目无关命令”。模型会遵守这些约定减少很多无意义的工具调用。第三是检查第三方服务端的注入逻辑。localai 这类引擎通常是中立的但有些统一接入层为了保证下游兼容性会额外往请求里塞系统提示词。你可以在服务端日志里看到实际转发给模型的完整请求体检查里面有没有你不需要的注入内容。4.3 流式传输和超时参数让慢请求变成可容忍的普通请求推理慢的体验问题很大程度可以通过调流式传输和超时来缓解。第三方 API 如果支持流式要确保 Claude Code 请求时带了stream: true。有些服务商的 Anthropic 协议兼容层默认把流式关掉你需要到服务端配置里打开。以 localai 为例安装 Anthropic 兼容层后需要在它的配置里明确启用STREAMING选项否则收到的是非流式响应。超时设置也同样讲究。Claude Code 默认的请求超时时间是 60 秒还是 10 分钟不同版本不太一样但如果你接的是本地推理引擎生成长文本时一次请求可能超过 3 分钟。我建议把超时时间加大到 300 秒或更长同时让 Claude Code 等待响应的重试次数降下来——因为重试一次就是一次完整的上下文重发token 消耗直接翻倍。4.4 压缩会话和拆分任务细水长流的省 token 技巧最后一个手段是改变使用习惯。这里有几个体感明显的小技巧定时/compact上下文到了七八成的时候就手动压缩把历史摘要化而不是等它自动触发。自动触发压缩时往往上下文已经爆满压缩本身还会产生一次额外的大上下文请求。任务拆分一个大型重构任务不要一个会话从头跑到尾让 Claude Code 先输出方案和文件清单你确认后再让它分批执行。这样能显著降低单会话的上下文天花板。在/status里观察上下文用量变化趋势如果增长太快说明模型在反复读取和重写同一个大文件。这时候给它更明确的指令例如“修改函数体时只读取该函数所在的 50 行不要读取整个文件”。5. 常见报错速查与排查实录接第三方 API 时报错基本集中在认证、上下文长度、路由配置这三类。我把最近遇到的几个整理成了一张速查表。报错信息原因排查方法no api key for provider route deepseek-official模型路由到了某个 provider但没配对应 key检查模型别名与接入层 provider 映射确认该 provider 的 key 已设置token exchange failed: error sending request认证服务器网络不通或地址错误检查 auth endpoint 配置、DNS 解析、证书是否正确确认请求能到达认证服务token endpoint returned status 403 forbidden账号或服务区授权校验不通过确认账号是否具备该服务访问权限检查服务方对调用区域或组织策略的限制联系服务商处理maximum context length is 1048576 tokens请求总 token 超过了模型窗口或模型上下文设置过大用/compact压缩会话检查第三方模型实际支持的 context 长度对齐配置invalid refresh_token: empty string本地持久化的凭据丢失或失效重新执行登录流程生成新的凭据检查配置文件中的 token 字段your organization has disabled claude subscription access组织策略禁止通过订阅方式使用 Claude Code改用 API key 方式认证或联系组织管理员调整策略sign-in failed: token exchange failed登录态过期且刷新失败退出登录后重新登录检查系统时间是否准确时间偏移会导致 JWT 校验失败逐个展开说。权限和地区策略出现 403 时我踩过几次坑——本以为是网络问题反复刷接口都没用后来发现是账号在服务商那里的授权范围没覆盖当前调用来源。这个一般需要联系服务商解决不是你在本地改几行配置能绕过的安全合规优先。上下文超限是另一个高频问题。有时候模型窗口显示 1M token但第三方服务实际处理不了那么长的上下文有时候是 Claude Code 的会话已经膨胀到极大再发一次请求就超限。处理方式都是先/compact压缩再检查模型服务端的 context 设置。本地推理引擎的话还要看显存够不够显存不足半途会 OOMClaude Code 那边表现为请求被切断、下一轮重发全部上下文token 又消耗一波。凭据失效这类问题我在用统一接入服务时遇到过几次。具体表现就是刷完登录状态之后过几小时又报refresh_token失效。这通常是服务端的 refresh token 有效期设得太短纯粹的认证策略问题你只能重新登录顺手检查系统时间是否准确——时间偏移会导致 token 签名校验直接失败出现莫名其妙的token exchange failed。在实际操作中的几个体会这类问题排查到最后我的体会是不要把第三方 API 当成官方 API 的“平替”来对待它的行为方式不一样需要主动适配。如果发现慢和 token 暴涨同时出现先怀疑流式传输和缓存支持再怀疑上下文管理最后才考虑是不是模型本身不行。另外建议平时开一个终端专门跑claude --cost或者用/cost看单次任务的 token 分布统计。很多问题刚发生的时候看统计就能看出端倪——举个例子如果输入 token 和输出 token 的比值超过 100:1那基本就是上下文重发太频繁了而不是模型输出太多。用第三方 API 和本地推理引擎图的是成本可控和数据可控但前提是上面这些参数都对齐了否则省下来的钱会被无效 token 慢慢吃回去。至少我现在这套配置已经跑了一周速度和 token 消耗都稳定在可接受范围希望这篇文章也能帮你少走几步弯路。