你大概已经按客户端配置的教程把 Claude Code 指到了一个第三方接口，能跑通一次，但真拿它改代码就发现毛病：长任务半路断流、并发一上来就报错、换了个模型输出风格全变、出了问题只看得到一行红字。这篇不讲协议怎么兼容、也不讲配置项怎么写，只讲接上之后怎么把它调稳：超时怎么分档、并发怎么压、失败怎么降级、日志留哪些字段、切换后怎么验证。
你大概已经按客户端配置的教程，把 Claude Code 指到了一个第三方接口，能跑通一次。但真拿它改代码就发现毛病：长任务半路断流、并发一上来就报错、换了个模型输出风格全变、出了问题只看得到一行红字。这篇不讲协议怎么兼容，也不讲配置项怎么写，只讲接上之后怎么把它调稳。
下面按五件事展开：超时怎么分档、并发怎么压、失败怎么降级、日志留哪些字段、切换后怎么验证，最后给一套出问题时的排查顺序。如果你现在连「Claude Code 能不能接 GPT」都还没确认，先到 兼容字段解析（/guides/openai-api-compat-fields） 把字段层面的事看明白，再回来调稳定。
超时与流式：先分清是「连不上」还是「算得慢」
把超时拆成连接、首字节、整体三段看：连不上通常几秒内就失败，首字节迟迟不来是排队或网关，整体超时才是任务太长。三者对应的动作完全不同，混在一起调会把问题越调越乱。
| 现象 | 大概率原因 | 先做什么 |
|---|---|---|
| 立刻失败、秒级报错 | 地址错、密钥无效、目标站不通 | 用一个最小请求打目标地址，确认连通再谈别的 |
| 连上了但很久没第一个字 | 排队、网关缓冲、目标站负载高 | 量延迟基线，换非高峰期或换目标站对比 |
| 答到一半停了 | 整体耗时超限、流式被中途掐断 | 改走流式并处理中途断线，别当没答完反复重试 |
- 长任务优先走流式，非流式请求在长上下文下更容易被网关按整体耗时掐断。
- 流式接进来后要处理中途断线，把断流和「模型答完」区分开，否则会重复计费还改坏代码。
- 先用站内测速页量一个延迟基线，再拿基线判断这次的慢是正常波动还是目标站变差，口径见 接口测速（/tools/speed-test）。
- 不适用的情况：本地跑的小模型、局域网自建服务，首字节本来就在毫秒级，按上面分档调反而误判。
并发与限流：别让 Claude Code 自己决定发多少请求
Claude Code 会为读文件、搜代码同时发多个请求，你在终端敲一条命令，后端可能瞬间收到一串调用。所以并发要在客户端或中转侧压住，而不是等报错再降。
- 设上限在客户端或中转配置里写死最大并发数，先给一个保守值，跑一批真实任务看有没有 429。
- 加退避偶发限流用指数退避，隔开重试间隔，别在同一个时间点再次打满。
- 上队列批量任务改成排队串行或小窗口并发，把失败请求的额度省下来给真正需要调用的步骤。
- 配步数上限并发数和单次任务最大步数一起设上限，避免一次重构把预算全烧光，思路参考 Agent 跑飞之前（/guides/agent-runaway-guardrails）。
遇到限流按「先降并发、再加退避、最后才排队」的次序处理。硬扛只会把额度耗在失败请求上。不适用的情况：单人本地用、任务都是几秒的小改动，压并发带来的等待反而拖慢手感，这时保持默认即可。
降级路由：主模型挂了，下一步该切到谁
准备一个备用目标，但要按能力分层。写代码和改代码对模型要求不同，拿一个只会闲聊的模型兜底，结果比直接报错更难查。
- 触发条件
- 只在请求失败、超时、限流时切，不对「回答内容不满意」自动换模型。
- 备选分层
- 主目标负责写与改，备用目标至少能稳定处理同一类任务，别只求能连通。
- 切换前检查
- 确认新目标在协议层支持你要用的字段和流式，字段清单到 兼容字段解析（/guides/openai-api-compat-fields） 对照。
- 人工兜底
- 涉及私有代码仓库时，备选目标的数据留存条款可能不同，宁可人工切，不配自动降级。
如果自动降级后同一段代码被两个模型各改一遍，冲突会很难收拾。所以降级只对请求失败触发，不针对回答质量。另一个不适用场景：团队对数据出域有硬要求时，任何自动切换都要先过合规确认。
日志与评测：让每次变慢、变贵都能复盘
日志不要求多复杂，但字段要齐。缺了 token 量，你没法解释账单变化；缺了首字节耗时，你分不清是网关慢还是模型慢。
- 每次请求记：时间、目标站、模型名、首字节耗时、总耗时、状态码、是否流式、输入输出 token 量。
- 改完配置或换了模型后，固定跑同一组小任务做对比，别凭感觉下结论，做法见 提示词版本回归（/guides/prompt-version-regression-testing）。
- 把失败按 401、403、404、429、5xx 分类计数，一周看一次分布，能提前发现是密钥、路由还是目标站本身在坏。
- 成本波动想量化时，到 价格追踪（/price-watch） 核对当时的数字，别拿记忆里的旧值做判断。
- 不适用的情况：一次性的临时脚本、跑完就扔的验证代码，不值得铺日志，记下调用命令和结果就够了。
出问题时的排查顺序
很多人一出问题就换模型，其实大部分故障在前三步就能定位。按下面顺序走，能少走很多弯路。
- 确认连通用一个最小请求打目标地址，通了再谈模型能力，不通就是密钥或地址问题，参考 接口连通验证（/guides/relay-connectivity-verification）。
- 确认字段把请求体和你以为的协议对照一遍，很多「模型不听话」其实是参数被丢掉了。
- 确认耗时与并发看日志里首字节和总耗时的分布，再决定是压并发还是换目标。
- 最后才换模型前面三步都干净了仍不满意，再动模型选择，避免把排错问题当成选型问题。
这套顺序不适用的情况：你明确知道是目标站当天在维护，那就直接切备用目标，不必从连通开始重走一遍。是否需要换目标站，可以顺手看一眼 站点排行（/rankings） 里近期状态，再决定是等还是换。
下一步把延迟基线、并发上限和失败分类先记下来，再去挑一个稳定的目标站，比反复改配置有效得多。→常见问题
Claude Code 能不能直接用 GPT 的 API，不用中转？
技术上取决于客户端是否允许自定义地址和密钥，能改就直连，不能改就得经过一层转发。但直连同样会碰到超时、并发、字段差异这些工程问题，本文讲的调优和排查顺序两种情况都适用。
接上以后经常中途断掉，是不是模型不行？
多数时候不是模型的问题，而是流式连接被中间层掐断，或者整体超时设得太短。先看断在首字节还是中途，再看日志里的耗时分档，模型能力放到最后再怀疑。
换了第三方接口后，输出风格和原来差很多，要不要紧？
风格差异正常，要紧的是行为差异：会不会乱改无关文件、会不会跳过测试。用同一组小任务跑两遍做对比，能接受再继续用，接受不了就换目标或收窄它的操作范围。
