一定要选 OpenAI Compatible 吗,能不能直接选 Anthropic?

看客户端。Cline 和 Roo 接第三方端点时可先按各自官方文档使用 OpenAI Compatible 配置；Claude Code 使用 Anthropic Messages 形态,应走对应的 /v1/messages 路径。跨协议转换可能改写或忽略没有对应关系的字段,是否影响工具、usage 或缓存要逐项实测,不能只凭协议名称判断。

模型名可以写厂商官方的名字吗?

取决于供应商。有的供应商做了别名映射,有的只认自己的 id。应查看供应商文档或其模型目录,把返回的准确 id 原样填入；不要假设每家都在 /v1/models 提供目录。

验证要多久做一次?

换供应商或关键客户端配置后应建立一次完整基线。之后可定期抽测 usage、长上下文、工具与缓存,并在行为明显变化时复跑。所需时间取决于模型延迟、上下文长度和复测次数；结果也可能只把范围缩小,而不是一次就定性。

多个客户端能共用一把 key 吗?

技术上可以。但建议按用途分开建 key,一个客户端一把。出问题时你能立刻定位是哪个客户端在异常消耗,而不是对着一条汇总账单猜。

检测工具会不会把我的 key 存下来?

不要仅凭页面承诺决定。对任何第三方检测工具都临时建一把额度很小的 key,不要放进 URL、截图或公开配置,测完立即删除。这个做法能把泄露后的影响限制在最小范围。

接入更新于 2026-09

在 Cline / Continue / Roo / Claude Code 里接第三方模型供应商:配置、避坑、验证(2026)

第三方模型接入不是只填一个地址:客户端协议、Base URL、鉴权方式、准确模型 ID 和可选能力必须同时匹配。这篇给出四种客户端的配置位、可复制的测试请求,以及接通后应分别验证的响应元数据、usage、长上下文、工具调用和缓存字段。

一句话结论:第三方供应商配置是客户端与端点之间的一份协议:协议形态、Base URL、鉴权头、模型 ID 和可选能力都要匹配。cocodot 在 Cline、Roo Code 和 Continue 中使用 https://cocodot.co/api/ai/v1；其他供应商必须使用其文档明确给出的 OpenAI 兼容地址,不能假设都以 /v1 结尾。Claude Code CLI 接 cocodot 时使用不带 /v1 的 https://cocodot.co/api/ai,客户端会请求 /v1/messages。先直接测试端点,再在客户端分别测试普通文本和真实工具调用。200 只证明这一笔请求成功,不证明流式、工具或所有模型专有能力都可用。模型名应从供应商目录复制,不要凭印象填写。验证 Anthropic 缓存时,使用达到最低长度的稳定前缀顺序调用:首次看 cache_creation_input_tokens,后续看 cache_read_input_tokens；不要用带与不带 cache_control 时 input_tokens 是否变化来判断字段有没有被保留。

1. 把接入看成 API 协议,不是寻找一个开关

客户端最终都要落实到五件事:它发送什么协议、怎样把 Base URL 与请求路径组合、使用哪个鉴权头、填写哪个准确模型 ID,以及所选模型和端点实际支持哪些能力。界面看起来填对了,仍可能指向错误路由。OpenAI 兼容端点没有统一规定必须以 /v1 结尾,应按供应商文档填写；不同客户端和模型也可能选择 Chat Completions 或 Responses API。Anthropic Messages 则使用对应的网关根地址。不要凭习惯增删 /v1。还要把基础文本兼容与 Agent 能力分开:普通回复成功时,工具调用仍可能不兼容,所以 hello-world 只是第一步。

2. 四个客户端的配置位对照

Cline 与 Roo Code 选择 OpenAI Compatible,填写供应商文档明确给出的兼容地址,再从模型目录复制准确 ID。对 cocodot,这个地址是 https://cocodot.co/api/ai/v1。文本回复成功后还要实际跑一次工具调用；Roo Code 依赖原生工具调用,不能用普通聊天成功替代这项验证。Continue 当前使用 config.yaml,provider 写 openai、apiBase 填供应商文档地址。当前版本对部分 o-series 与 GPT-5 名称可能默认使用 Responses API；若端点只提供 Chat Completions,应设置 useResponsesApi: false。Claude Code CLI 使用 Anthropic Messages 形态,接 cocodot 时填 https://cocodot.co/api/ai,不带 /v1。下面是 cocodot 的 Continue 配置示例。

Continue 的配置片段(~/.continue/config.yaml)

models:
  - name: 我的第三方供应商
    provider: openai
    apiBase: https://cocodot.co/api/ai/v1
    apiKey: 你的-key
    model: 从 /v1/models 查到的准确 id
    defaultCompletionOptions:
      contextLength: 200000
      maxTokens: 8192
    requestOptions:
      timeout: 600000

3. Claude Code CLI:先用临时环境变量验证

Claude Code CLI 可通过网关环境变量验证 Anthropic Messages 路由。接 cocodot 时,ANTHROPIC_BASE_URL 填 https://cocodot.co/api/ai,不带 /v1；Claude Code 会请求 /v1/messages。先在当前终端临时导出变量,从同一个终端启动 Claude Code,并用 /status 核对实际 Base URL 与凭证来源。确认成功后再按官方文档持久化,且不要把密钥提交进共享仓库。Claude Code Desktop 与 VS Code 是不同配置面,不能用 CLI 成功推断它们也走同一路由。其他第三方客户端(包括 ZCode)应按各自文档单独配置和验证,不能直接套用这组环境变量。

Claude Code CLI 的临时网关环境变量

export ANTHROPIC_BASE_URL="https://cocodot.co/api/ai"
export ANTHROPIC_AUTH_TOKEN="你的-key"
export ANTHROPIC_MODEL="你要用的模型名"

4. Base URL 要按供应商文档与客户端拼接规则填写

OpenAI 兼容服务的 Base URL 形态并不统一,不要把 /v1 当成所有供应商的通则。对 cocodot,Cline、Roo Code 与 Continue 使用 https://cocodot.co/api/ai/v1,客户端再请求 /chat/completions；Claude Code CLI 则使用 https://cocodot.co/api/ai 并请求 /v1/messages。其他供应商应同时查看它的端点文档和客户端会追加的路径。可先请求供应商提供的模型目录并复制返回的准确 id,但模型目录可能是公开的,返回成功不一定验证了鉴权。404 也不只对应一种原因:它可能来自路径组合、资源不存在或供应商自己的错误映射,应结合请求 URL 与错误体判断。

读取 cocodot 公共模型目录并复制准确模型 ID

curl -s https://cocodot.co/api/ai/v1/models \
  -H "Authorization: Bearer 你的-key" | head -c 500

5. 鉴权头、流式 usage 与超时:三个最常被忽略的设置

第一,按供应商要求选择鉴权头。OpenAI 兼容端点常用 Authorization: Bearer,Anthropic Messages 常用 x-api-key 并带 anthropic-version；不要为了“保险”同时发送两套凭证,应按文档使用一种并检查实际请求。第二,OpenAI 兼容流式接口是否需要 stream_options.include_usage 取决于客户端和端点实现；需要核对 token 时,先确认供应商文档并检查最后一个流式事件。第三,超时应按模型首字节延迟、任务长度和客户端文档分别设置,再用真实请求验证。不要把一个固定时长复制给所有模型和客户端,也不要把客户端超时直接归因于供应商不稳定。

手写测试 cocodot 的 Anthropic Messages 端点

curl -s https://cocodot.co/api/ai/v1/messages \
  -H "x-api-key: 你的-key" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"你的模型名","max_tokens":64,
       "messages":[{"role":"user","content":"回复两个字:收到"}]}'

6. 接上之后怎么验证没被降智(第一到第三步)

以下步骤建议每换一个供应商都跑一遍,并把结果记下来当基线。第一步,响应元数据:发一次非流式请求,看响应体里的 model 字段和目标端点是否与预期一致；供应商暴露 request id 时一并记录,否则使用自己的 trace id。这些字段能筛掉明显的路由错误,但单独不能证明底层模型身份。第二步,usage 一致性:把完全相同的序列化请求顺序发送多次,比较完整 usage,包括普通输入、缓存创建、缓存读取、输出以及可用时的推理 token。同一计费状态下普通输入应形成稳定基线；第一次创建缓存、后续读取缓存时分类变化是正常现象。数字不同是需要排查客户端附加消息、路由模板、模型版本或计费口径的信号,不是有人注入提示词的唯一证明。第三步,长上下文完整性:造一段长填充文本,在大约 20%、45% 和 75% 的位置分别埋入模型猜不到的随机口令,重复测试并与短文本对照。短对照成功、长文本固定位置反复失败时,再结合实际 usage 排查客户端 contextLength、网关限制或服务端截断；单次答错本身不能证明输入被截断。

7. 验证的后半段:工具调用与协议专有字段(第四到第六步)

第四步,工具调用完整性:先测一个简单函数,再测两个独立工具、嵌套对象、数组和枚举,最后把工具结果按协议要求的 call id 与角色回传,确认模型能继续执行。只有文本回复成功不能证明工具链完整。第五步,验证 Anthropic 缓存字段是否被保留:准备达到所选模型与平台最低可缓存长度的稳定前缀,把 cache_control 放在稳定部分的末尾,然后顺序发送相同请求。第一个合格请求应查看 usage.cache_creation_input_tokens,后续请求查看 usage.cache_read_input_tokens。两项一直为 0 可能是字段被忽略,也可能是前缀太短、模型或路由不支持缓存、缓存边界丢失、TTL 已过或模型可见前缀发生变化;先复现和排除这些条件,不要只凭 input_tokens 是否变化下结论。第六步可以用 probe.cocodot.co 帮助组织可复现检查。对任何第三方诊断工具都使用临时、低额度 key,测完删除,不要把真实 key 放进 URL、截图或公开配置。

8. 常见报错对照与供应商选择

404 且没有任何说明,优先核对 base_url 与客户端追加路径怎样组合,再用模型列表确认前缀。401 或 invalid api key,检查凭证是否缺失、被拒或放错鉴权头。返回 200 但行为异常,先核对准确模型 id、客户端实际发送的请求和完整 usage,不要仅凭文风断言回退。流式没有 usage,检查客户端是否需要显式 include_usage。长文件问答异常,先查客户端 contextLength、网关限制和实际输入 token;首字节前断开则检查客户端超时。供应商配置可以保留备用 profile,但每条路都要单独验证。cocodot 提供 OpenAI 兼容端点 https://cocodot.co/api/ai/v1 和供 Claude Code 使用的 Anthropic 兼容端点 https://cocodot.co/api/ai；这说明客户端可以按对应协议接入,不等于承诺所有字段在所有模型上都生效。模型、工具调用、缓存与 usage 都应按本文方法实测。充值走支付宝,主体是海外注册公司。

四个客户端的配置位对照

客户端	选哪种 Provider	Base URL 填到哪	模型名从哪来	最高频的坑
Cline	OpenAI Compatible	按供应商文档；cocodot 为 /api/ai/v1	从供应商模型目录复制	只测文本,未验证工具调用
Roo Code	OpenAI Compatible	按供应商文档；cocodot 为 /api/ai/v1	从供应商模型目录复制	所选模型或路由不支持原生工具调用
Continue	provider 写 openai,再给 apiBase	按供应商文档；cocodot 为 /api/ai/v1	写在 model 字段	端点不支持 Responses API 却未关闭 useResponsesApi
Claude Code CLI	Anthropic Messages	cocodot 填 /api/ai(不带 /v1)	从供应商模型目录复制	把 OpenAI 兼容地址直接搬过来