兼容矩阵
各客户端该填什么形状的 base URL，以及每个模型家族在哪些协议上开放。
第一次请求失败，几乎只有两个原因：base URL 的形状，和这个模型是否在客户端所讲的 协议上开放。这一页是两者的简版。
为什么各客户端的 base URL 不一样
网关在三条路径上都接受 Anthropic Messages，三者等价：
/v1/messages
/anthropic/v1/messages
/v1/v1/messages ← 容忍,给那些 base URL 末尾带了 /v1 的客户端所以你该填的 base URL 不是一个固定字符串 —— 它取决于你的客户端会往后面追加什么。 从最终路径倒推：
| 你的客户端追加 | 该填的 base URL |
|---|---|
/v1/messages（官方 Anthropic SDK —— Claude Code、Pi、OpenClaw） | https://api.routemux.com |
/messages（Vercel AI SDK 的 Anthropic provider —— OpenCode） | https://api.routemux.com/v1 |
/chat/completions 或 /responses（OpenAI 客户端） | https://api.routemux.com/v1 |
| 什么都不追加，要填完整路径 | https://api.routemux.com/v1/chat/completions |
| Gemini / Vertex 操作 | https://api.routemux.com/vertex-ai |
最常见的那个错，其实不是致命的那个
在一个已经会追加 /v1/messages 的 Anthropic base URL 上再加 /v1，会得到
/v1/v1/messages —— 我们照样会正确路由，所以这种写法通常是能用的，不是卡住大家的原因。
反方向才是：客户端只追加一个操作名，而你漏掉了 /v1，那么每条请求都会 404。
各模型家族在哪些协议上开放
一个模型只能在它真正开放的协议上调用。对你这把 key 而言，GET /v1/models 是权威；
按家族看是这样：
| 模型家族 | OpenAI Chat | OpenAI Responses | Anthropic Messages | Vertex |
|---|---|---|---|---|
anthropic/claude-* | — | — | ✅ | — |
openai/gpt-5.*、gpt-6-* | ✅ | ✅ | ✅ | — |
deepseek/* | ✅ | ✅ | ✅ | — |
minimax/minimax-m* | ✅ | ✅ | ✅ | — |
zhipu/glm-* | ✅ | ✅ | ✅ | — |
google/gemini-*（文本） | ✅ | — | — | ✅ |
google/gemini-*（出图） | — | — | — | ✅ |
xai/grok-4.5 | ✅ | — | — | — |
xai/grok-4.6 | ✅ | ✅ | — | — |
其中两条值得单独拎出来：
- Gemini 文本模型同时在两个协议上。 你可以用普通 OpenAI 客户端调，也可以用 Gemini/Vertex 客户端调。Gemini 的出图模型只有 Vertex 一条。
- 没有任何 Grok 模型在 Anthropic Messages 上。 Claude Code 形状的客户端在这里 够不着 Grok，base URL 怎么填都不行。
图片、视频、音乐模型完全不在上面三个文本协议上 —— 它们有自己的端点。
在一个模型没有开放的协议上调它，会返回
400 MODEL_PROTOCOL_UNSUPPORTED。
实际会发生的组合就两种：
- 拿 Claude 的 slug 打
/v1/chat/completions。 多半是编辑器或聊天客户端用了它那个 通用的「OpenAI Compatible」供应商。改用该客户端的 Anthropic 供应商。 - 拿 Gemini 的 slug 打
/v1/messages或/v1/responses。 Gemini 文本模型在这里走 的是 OpenAI Chat。
按客户端速查
只列本站有接入文的客户端；精确的配置键名在各自页面里。
| 客户端 | 它发的协议 | Base URL | 备注 |
|---|---|---|---|
| Claude Code | Anthropic Messages | 裸 origin | ANTHROPIC_BASE_URL + ANTHROPIC_AUTH_TOKEN |
| Codex CLI | 只有 OpenAI Responses | 带 /v1 | 在 ~/.codex/config.toml 里配自定义 provider；没有 Chat Completions 模式 |
| OpenCode | 两者皆可，按 provider 块 | 两条都带 /v1 | npm 字段决定协议 |
| Pi | 四种皆可，按 provider | Anthropic 用裸 origin，OpenAI 带 /v1 | api 字段决定协议 |
| OpenClaw | 四种皆可，按 provider | 同 Pi | 配置在 models.providers 下面 |
| Hermes Agent | 三种，按 provider | 一律带 /v1 | 会归一化末尾的 /v1；api_mode 决定协议 |
| Cline | 两者皆可，按供应商类型 | Anthropic 用裸 origin，OpenAI 带 /v1 | Claude 模型必须走 Anthropic 供应商 |
| Cursor | OpenAI Chat | 带 /v1 | 只覆盖 chat 模型；请求从 Cursor 服务器发出 |
| Gemini CLI | Vertex | 带 /vertex-ai | 用的是 Google 风格的 base URL 变量 |
| CC Switch | 按目标应用写死 | 替你填好 | 导入器里每个应用的协议是硬编码的 |
模型 id
GET /v1/models 返回的正是这把 key 能调用的全集。能被解析的方言：
- 裸名 ↔ 带
anthropic/、openai/、google/前缀的形态 - 版本号里的横线 ↔ 点号（
claude-sonnet-4-6与claude-sonnet-4.6） - 结尾的
-YYYYMMDD日期快照会被忽略 - 结尾的
[1m]上下文标记会被忽略
不能解析、而且在真实流量里反复出现的：shell 变量带进来的尾部空格、变量名没展开就原样
发出、URL 编码的斜杠（%2F）、把活动标签连着模型名一起粘进来、以及我们没有上架的模型版本。
鉴权头
Authorization: Bearer、x-api-key、x-goog-api-key 都接受。同一个 key 同时出现在两个
头里没问题 —— 我们按值去重。但发两个不同的值会返回
400 AUTH_AMBIGUOUS_API_KEY，把没在用的那个字段清掉。
超时
- 流式请求没有总时长上限。
- 有空闲看门狗：文本 180 秒，图片与视频更长。在该窗口内没有新 chunk 就中止请求并记为超时。
- 等上游第一个响应头的预算随请求体大小放宽，所以很大的会话比小请求拿到更多宽限。