协议与转换边界
网关能在协议之间转换，但不是万能翻译器。这一页说明边界在哪，以及遇到不支持的组合时会怎样。
四种协议§
GPT-Load 接受四种客户端协议。它们是并列关系， 一把访问密钥可以同时允许多个：
- OpenAI Chat Completions——最通用， 绝大多数兼容客户端和第三方服务都走这条
- OpenAI Responses——较新的接口形态， 支持有状态的多轮接续
- Anthropic Messages——Claude 系客户端的原生入口
- Gemini——Gemini 系客户端的原生入口
Chat Completions 和 Responses 是两个独立协议，不是一个的新旧版本。 管理台里选「OpenAI」预设时会同时勾上这两个，但它们各自有独立的入口和能力。
接口入口§
客户端按各自协议的习惯访问，不需要在路径里带分组名：
| 协议 | 主要入口 |
|---|---|
| OpenAI Chat Completions | /v1/chat/completions |
| OpenAI Responses | /v1/responses 及其资源路径 |
| Anthropic Messages | /v1/messages |
| Gemini | /v1beta/models/… |
除对话外，还提供这些接口（可用性取决于上游渠道）：
- 模型列表——
/v1/models与/v1beta/models - 向量嵌入——
/v1/embeddings - 图片生成与编辑——
/v1/images/generations、/v1/images/edits - token 计数——
/v1/messages/count_tokens及 Gemini 的countTokens
转换是怎么发生的§
客户端用的协议，和上游渠道支持的协议不一定相同。 比如你用 Claude Code（Anthropic 协议）请求一个 OpenAI 渠道的模型—— 网关会把请求转成 OpenAI 格式发出去，再把响应转回 Anthropic 格式。
这个转换对客户端是透明的。请求日志里能看到转换过程， 排查响应格式异常时先看这里，见 监控与排障。
协议相同时不发生转换，请求基本原样透传—— 这也是延迟最低、兼容性最好的路径。
不能转换的情况§
每个渠道声明自己能执行哪些协议与能力。网关只在这些声明的能力之间转换， 不会尝试把任意协议、任意 JSON 强行翻译成另一种。
常见的转换失败场景：
- 目标渠道不支持该能力—— 比如向一个纯文本模型请求图片生成
- 协议特有的参数没有对应物—— 某些参数只存在于一种协议里，转换时会被丢弃或报错
- 模型本身不支持—— 比如对不支持视觉的模型发送图片输入
遇到这类问题，最直接的解法是让客户端协议和渠道协议对齐： 用 Claude 客户端就配 Anthropic 渠道，减少中间转换。
有状态请求§
OpenAI Responses 支持靠 previous_response_id、conversation 或已有资源 ID 接续上下文。 这类请求有个前提：
上下文存在上游那一侧，且通常绑定在创建它的那个凭据上。 换一个凭据请求，上游会找不到之前的会话。
当前会话亲和依据提示词前缀，不读取 previous_response_id、conversation 或其他资源 ID，因此不能提供强一致路由保证。 可靠使用有状态资源时，请确保该分组只有一个凭据， 或确认上游允许不同凭据共享同一资源。
另一个选择是不用有状态接口—— 每次把完整上下文发过去。这样任何凭据都能处理， 调度也更均衡，代价是每次请求的输入 token 更多。
该用哪个协议§
没有绝对的优劣，按情况选：
- 客户端已经定了——用它原生的那个，转换最少。 Claude Code 就用 Anthropic，Gemini CLI 就用 Gemini
- 自己写代码——Chat Completions 兼容性最广， 换上游最省事
- 需要有状态接续——Responses， 但记得开会话亲和
访问密钥里可以同时勾选多个协议， 不确定就都勾上，用不到的协议不会有副作用。 配置见 访问密钥。