Claude Code 第三方 API 稳不稳，测延迟切分组

Claude Code 接第三方 API，稳定不是一个开关

把 Claude Code 的接口换成第三方之后，很多人问的是“稳不稳”。这个问题不能只看一次 hello 能不能返回。Claude Code 和普通聊天窗口不一样，它会连续读文件、跑命令、带工具描述、塞入长上下文，还要把模型输出实时显示在终端里。一次请求成功，不代表十轮编辑代码都成功。更真实的稳定，至少包括成功调用、首 Token 延迟、流式吞吐、超时率、429/529 重试情况，以及会话里的工具调用是否被正确解析。

如果你刚遇到 Claude Code 卡住、报鉴权、报限流，可以先按接入与排错完全指南把基础链路确认一遍，再判断是不是渠道本身的问题。

上游渠道差异：同一个模型，为什么会忽快忽慢

第三方 API 的“渠道”不是单纯一个域名。一个域名后面可能挂着多组上游账号池、不同区域入口、不同缓存策略、不同重试次数和超时阈值。有的渠道为了便宜，把请求排到共享队列，高峰时排队时间就长；有的渠道把 Claude Code 常用的长上下文请求优先路由；有的渠道启用了 prompt cache，第二轮对话明显更快；也有的渠道没有透传缓存头，导致每次请求都像第一次冷启动。

更常见的是，你感觉“模型变笨了”，其实是超时后发生了重试。Claude Code 如果发出完整上下文，上游慢但没有返回，客户端可能等待很久，或者你中断后重新问，token 和费用都增加了。遇到 401 和 429 也不要混着查，前者多半是 key、base_url、鉴权头配置错了，后者才更像容量、分组倍率或上游限流，具体可以看 401 和 429 的区别。

先测首 Token 和吞吐，别只看“能不能回复”

想判断第三方入口是否适合 Claude Code，建议不要只在终端里随手问一句。先测三个数：首 Token 时间、总耗时、输出吞吐。首 Token 决定你按回车后有没有“开始干活”的感觉；总耗时决定一次长回答能不能等完；输出吞吐决定代码块、日志、解释说明是不是像打字一样稳定。Claude Code 在终端里如果首 Token 超过两三秒，你会明显觉得迟滞；如果吞吐低于十几 token/s，写长文档时会很折磨。

可以用 curl 做一次最小验证。命令里把 $ANTHROPIC_BASE_URL、$ANTHROPIC_API_KEY 和模型名换成你当前配置：

time curl -N "$ANTHROPIC_BASE_URL/v1/messages" -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -H "content-type: application/json" -d '{"model":"claude-sonnet-4-5","max_tokens":256,"messages":[{"role":"user","content":"只输出十行编号短句"}]}'

如果这个请求正常，但 Claude Code 卡住，问题可能不在网络，而在上下文长度、工具调用格式或客户端重试。反过来，如果这个请求本身就慢，切回 Claude Code 也没用。

真实配置片段：把入口固定，再测分组

为了减少变量，建议先用一份明确配置测试。下面是一段可直接放进 shell 的配置，适合验证第三方入口是否连通：

export ANTHROPIC_BASE_URL="https://api.yushou.xyz"
export ANTHROPIC_API_KEY="sk-your-key-here"
export CLAUDE_MODEL="claude-sonnet-4-5"
claude --model "$CLAUDE_MODEL"

这里最关键的是 base_url 和模型名。base_url 不要带末尾多余斜杠，模型名要和上游分组支持的一致。如果终端里 claude 启动正常，但请求报错，可以把同一条命令的模型名换成控制台里明确支持的名字再试。常见报错原文里会有这类片段：authentication_error、invalid_api_key、rate_limit_error。看到 authentication_error，先查 key、base_url、是否多了空格；看到 rate_limit_error，再查分组、模型、倍率和并发。

遇到慢的时候，怎么切换分组而不是盲目重启

第三方入口慢的时候，很多人第一反应是退出 Claude Code 再开一次。这个动作有时有效，但更多只是碰运气。更稳的做法是看当前请求是不是命中了慢分组。假设平台用 base_url 路径区分分组，你可以把同一个 key 切到更快或更贵的分组上测试：

export ANTHROPIC_BASE_URL="https://api.yushou.xyz/group/claude-sonnet-fast"
curl -N "$ANTHROPIC_BASE_URL/v1/messages" -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -H "content-type: application/json" -d '{"model":"claude-sonnet-4-5","max_tokens":64,"messages":[{"role":"user","content":"ping"}]}'

切分组时别只看“快”。快分组可能倍率高，长上下文任务会很快把预算烧掉。以常见的 Claude Sonnet 级模型为例，第三方分组倍率可能在 0.8 到 1.5 之间波动，缓存命中、长上下文、输出长度都会改变最终费用。动手前最好打开模型价格表看清楚实时单价和分组倍率，别等月底账单出来才发现只是测试慢请求就多花了钱。

如果你经常跑多文件编辑、读日志、让模型连续生成补丁，还可以看看上下文自动压缩实操。上下文压缩能降低一些长会话成本，但不能替代稳定上游。压缩触发得太频繁，反而会让模型忘记你刚改过的接口细节。

把“稳”落到日常：成功率、延迟、价格一起看

真正适合 Claude Code 的第三方 API，不是某一次请求最快，而是长时间写代码时少中断、少重复、少莫名超时。你可以给自己设一个简单验收线：连续十次代码任务里，首 Token 基本在 2 秒左右，长输出不卡顿，429 和 529 有明确提示，工具调用能正常返回。如果某个分组只在短请求里快，一到长上下文就排队，那它对 Claude Code 的价值有限。

想少踩坑，可以先固定好 Claude Code 的入口、key、模型名，再用同一组提示词分别测两个分组。测的时候记录三件事：第一次响应用了多久，完整输出用了多久，最终账单里 input/output/cache 三项各占多少。数据多了，你会发现“稳不稳”其实不是玄学，而是渠道策略、分组容量和你的任务类型有没有对上。

如果你正准备找一个可以直接验证的入口，可以先从寓守API 开始：拿一个测试 key，固定 base_url，跑一次 curl，再跑一次 Claude Code 的多文件任务，慢不慢、值不值，基本就能判断出来。