三种 API 协议

Router 数据面同时提供三种协议入口，同一个 API Key 在三种协议下通用。按你的客户端或 SDK 所属生态选择其一即可，能力上没有高低之分。

协议与接入地址

协议	接入地址（base URL）	实际端点	鉴权头
Anthropic Messages	https://routerapi.<域名>/anthropic	POST /anthropic/v1/messages	x-api-key: <Key>（或 Authorization: Bearer）
OpenAI Chat Completions	https://routerapi.<域名>/v1	POST /v1/chat/completions	Authorization: Bearer <Key>（或 x-api-key）
OpenAI Responses	https://routerapi.<域名>/v1	POST /v1/responses	Authorization: Bearer <Key>（或 x-api-key）

表中为地址格式示例，实际域名以控制台「快速接入」页展示为准。

怎么选

• Claude Code、Cline、Roo Code 等 Anthropic 生态编程工具 → Anthropic Messages 协议。这类工具通常只需要设置 ANTHROPIC_BASE_URL 与 ANTHROPIC_AUTH_TOKEN 两个环境变量。
• OpenAI SDK、LangChain、绝大多数聊天客户端与应用平台（Cherry Studio、Dify 等）→ OpenAI Chat Completions 协议。这是最通用的选择。
• 使用 OpenAI 新一代 Responses API 的应用 → OpenAI Responses 协议。

通道原生支持你所用的协议时请求原样透传，协议特有能力的保真度最好；不支持的协议由路由层自动翻译，基础对话能力不受影响。因此优先选与你客户端生态一致的协议即可。

消息字段兼容

多轮对话中，部分客户端会把模型返回的思考过程等附加字段回放进历史消息。网关对消息体内已识别的附加字段（如 reasoning_content）原样保留；无法识别的附加字段会被静默移除，不会因此报错——不同客户端生态的写法差异不影响接入。

被移除的字段名会记录在每次调用的观测数据中，运营侧可查询。若你在调试中需要网关严格暴露这类字段（让上游直接报错以便定位客户端行为），请联系运营方对该通道开启透传模式。

流式请求

三种协议都支持流式（SSE）：OpenAI 协议在请求体中带 "stream": true；Anthropic 协议带 "stream": true。网关注层面不做缓冲，token 逐块到达。

流式响应会携带本次调用的 token 用量：OpenAI 协议在流的末尾返回一个 usage 数据块（choices 为空数组的 data 行），Anthropic 协议在 message_delta 事件中携带。主流 SDK 会自动处理；自行解析 SSE 的客户端请注意跳过该数据块。用量数据同时用于计费与用量统计。

路由决策响应头

每次调用的响应头会携带本次的路由决策信息（x-veyra- 前缀），可用于排查与观测：

响应头	含义
x-veyra-routing-model	实际落地执行本次请求的模型
x-veyra-routing-type	路由形态（智能路由池 / 直调模型）
x-veyra-routing-reason	本次选路原因（如权重分配 / 健康切换 / 故障升级）
x-veyra-routing-tier	命中的路由档位
x-veyra-routing-score	选路评分（4 位小数）
x-veyra-routing-escalated	是否因上游故障升级到备用通道（true/false）
x-veyra-cls-type / x-veyra-cls-tier	智能路由池调用的任务分类结果（任务类型 / 难度档，仅分类器介入时下发）
x-veyra-cls-confidence / x-veyra-cls-mode	分类置信度 / 分类模式（同上）

不需要这些信息的客户端可以直接忽略，不影响任何功能。

错误处理

• 401：Key 缺失或无效——检查鉴权头与 Key 是否已删除
• 429：超出 Key 限额——总额模式用完即止（可在控制台清空已用量复位）；周期模式（日/周/月）响应带 Retry-After 头，到窗口重置点自动恢复
• 5xx：上游供应商故障——路由层已自动重试与切换备用通道，仍失败时请稍后重试或联系官方支持