协议与转换边界

四种对话协议§

GPT-Load 接受四种对话协议。它们是并列关系，一把访问密钥可以同时允许多个；图片、向量、重排序、决策、语音合成和实时语音另有独立协议权限。

• OpenAI Chat Completions——最通用， 绝大多数兼容客户端和第三方服务都走这条
• OpenAI Responses——较新的接口形态， 支持有状态的多轮接续
• Anthropic Messages——Claude 系客户端的原生入口
• Gemini——Gemini 系客户端的原生入口

接口入口§

客户端按各自协议的习惯访问，不需要在路径里带分组名：

除对话外，还提供这些接口（可用性取决于上游渠道）：

• 模型列表——/v1/models 与 /v1beta/models
• 向量嵌入——/v1/embeddings；Gemini 原生使用 /v1beta/models/…:embedContent 或 :batchEmbedContents
• 图片生成与编辑——/v1/images/generations、/v1/images/edits
• token 计数——/v1/messages/count_tokens 及 Gemini 的 countTokens
• 纯文本重排序：POST /v1/rerank，独立使用 rerank 协议，不支持流式或协议互转。
• JEV 决策：POST /v1/decisions，由 Jev 或 OpenRouter 渠道原生执行，独立使用 decisions 协议。
• 语音合成：POST /v1/audio/speech，独立使用 audio-speech 协议，按渠道原生格式处理普通或 SSE 响应，不做协议互转。
• Codex 实时语音：独立使用 codex-live 协议，不是 Responses WebSocket 的另一种文本模式。

语音合成支持 OpenAI、OpenRouter 与 Mistral。请求必须是含 model 的 JSON，voice、voice_id、response_format、instructions 等参数遵循所选渠道。普通响应中，OpenAI 与 OpenRouter 可返回音频字节，Mistral 可返回含 audio_data 的 JSON；客户端应按实际 Content-Type 处理响应。语音凭据探测不受支持。

OpenAI 设 stream_format 为 sse，Mistral 设 stream 为 true，即可使用原生 SSE；OpenRouter 仅支持普通响应。事件按渠道格式实时透传，客户端需按 text/event-stream 消费；speech.audio.done 表示完成，错误事件或意外中断按失败记录。

OpenAI 语音合成的 Base URL 留空时使用官方地址；自定义地址按 OpenAI 渠道约定填写，不含末尾 /v1，网关保留原有路径前缀并追加 /v1/audio/speech。

Gemini、Google Vertex AI、New API 与 GPT-Load 支持原生 gemini-embeddings；Gemini 与 Vertex AI 渠道还可将 OpenAI Embeddings 的文本请求转成 Gemini 原生批量嵌入，支持 dimensions 及 float／base64 输出，不支持 token ID 输入。

Vertex AI 沿用服务账号 JSON 与 location 配置，适用于 Gemini 嵌入接口模型，如 gemini-embedding-2。模型名可使用短名、google/ 或 publishers/google/models/ 前缀；不支持数字自定义端点及使用 :predict 的旧式向量模型。多模态输入需使用原生 Gemini 嵌入格式，具体能力仍取决于模型。

Codex 实时语音接入指南 →

GET /v1/models 携带非空 anthropic-version 请求头时返回 Anthropic 模型列表；否则返回 OpenAI Chat Completions 格式。直接调接口时按客户端协议带上对应请求头。

查看逐渠道协议与 Operation →

原生搜索入口为 POST /v1/alpha/search，使用 openai-responses 协议，支持 CLIProxyAPI、New API 与 GPT-Load 渠道。它不是聊天协议转换，也不意味着任意上游账号都能搜索。

转换是怎么发生的§

客户端用的协议，和上游渠道支持的协议不一定相同。 比如你用 Claude Code（Anthropic 协议）请求一个 OpenAI 渠道的模型—— 网关会把请求转成 OpenAI 格式发出去，再把响应转回 Anthropic 格式。

这个转换对客户端是透明的。请求日志里能看到转换过程， 排查响应格式异常时先看这里，见 监控与排障。

协议相同时不发生转换，请求基本原样透传—— 这也是延迟最低、兼容性最好的路径。

不能转换的情况§

常见的转换失败场景：

• 目标渠道不支持该能力—— 比如向一个纯文本模型请求图片生成
• 协议特有的参数没有对应物—— 某些参数只存在于一种协议里，转换时会被丢弃或报错
• 模型本身不支持—— 比如对不支持视觉的模型发送图片输入

遇到这类问题，最直接的解法是让客户端协议和渠道协议对齐： 用 Claude 客户端就配 Anthropic 渠道，减少中间转换。

带 Anthropic advisor 工具的请求仅走原生路由；子模型的开放、访问限制与价格配置见 模型管理。

有状态请求§

OpenAI Responses 支持靠 previous_response_id、conversation 或已有资源 ID 接续上下文。 这类请求有个前提：

转换或无状态响应、明确 store:false 的新响应不会登记；网关外创建或归属记录已过期、淘汰、未恢复的 ID 会在本地拒绝。只有正常停机成功保存后才能恢复绑定，不保证异常退出后的恢复。

查询、输入项列表、删除、取消和资源子路径都要求使用创建响应时的同一访问密钥，并固定到记录的原凭据；仍需满足当前权限、渠道能力和凭据健康状态，不会因失败换号。未知或非本密钥拥有的 ID 统一返回本地 404 response_resource_not_found，不请求上游。

conversation 与其他非响应 ID 引用仍不保证回到原凭据；可用单凭据分组，或确认上游支持共享。中转渠道只保证回到原下一跳。POST 创建、compact 与 input_tokens 保持各自原有的行为。

GET /v1/responses 支持原生 WebSocket，当前适用于 OpenAI、Codex、xAI、GPT-Load、CLIProxyAPI、Sub2API。连接固定上游 Session，Codex 仅支持原连接内续接；不提供 WS→HTTP 转换，也不保证重连恢复上下文。开关见运行时设置。

Codex WebSocket 支持在生成期间发送 response.interrupt，携带同一连接中当前响应的 response_id；网关在原上游连接立即转发，中断确认后可用 previous_response_id 续接。已结束响应的迟到或重复中断会被忽略，不会影响下一轮。若上游以 response.incomplete 返回中断且没有输出、output_tokens 为 0，连接仍会关闭，不能续接。

另一个选择是每次发送完整可读上下文，减少对原账号存储的依赖； 历史中的加密内容和条目 ID 仍可能与原账号绑定，不能保证任意凭据都能接续，输入 token 也可能更多。

HTTP/SSE 与 WebSocket Responses 在向客户端输出前被上游明确拒绝历史加密内容或条目 ID 时，可尝试一次同凭据清理重放；WebSocket 仅限新连接首轮。重放计入 retry_count，并遵守错误规则与凭据冷却。已有内容或工具活动后不重放，compaction 与 item_reference 不会被自动删除。

清理重放后仍被同类拒绝时，HTTP 返回 400 encrypted_content_recovery_exhausted；可用可读完整历史重发或新建会话。WebSocket 已绑定的上游连接失效时，仍需客户端重新连接并重发。

CLIProxyAPI 与 New API 的 Responses 扩展透传不包含响应资源的查询、删除、取消、输入项或 Input Tokens。普通 previous_response_id 续接仍依赖上游存储；需要未声明资源能力的输入会在本地拒绝，不会先发给上游试探。

该用哪个协议§

没有绝对的优劣，按情况选：

• 客户端已经定了——用它原生的那个，转换最少。 Claude Code 就用 Anthropic，Gemini CLI 就用 Gemini
• 自己写代码——Chat Completions 兼容性最广， 换上游最省事
• 需要有状态接续——Responses； 注意响应 ID 续接与其他资源引用的不同边界

访问密钥里可以同时勾选多个协议， 不确定就都勾上，用不到的协议不会有副作用。 配置见 访问密钥。