dsh-relay-models

使用

1. 打开 DSH 设置。
2. 进入“中转模型”（在“模型”和“插件”之间）。
3. 点击“添加中转站”。
4. 填写 Provider ID、显示名称、Base URL、默认协议和 API Key（自建无鉴权网关可留空）。
5. 点击“发现模型并添加”。
6. 在“模型”里修改映射、协议或排除状态。

Base URL 可以带或不带 /v1。插件会为不同协议生成对应调用地址，并尝试 /models 与 /v1/models 进行发现。

Codex Responses

匹配到官方 openai-codex 元数据的模型会自动使用 Codex Responses。pi-ai 会把请求打到 {origin}/backend-api/codex/responses（CLIProxyAPI 的 Codex 别名，和 /v1/responses 同一个 handler）。连接设置里的 Codex 传输 默认 auto：先 WebSocket，失败再 SSE。需要纯 SSE 时把该模型协议覆盖成 OpenAI Responses，或把传输设为 SSE。

CLIProxyAPI 上游还要在对应 Codex 凭证里打开 "websockets": true，否则下游即使是 WS，上游仍走 SSE。

这条协议的鉴权和另外三种不一样。pi-ai 先把 API Key 当 ChatGPT OAuth token 解码、取出 chatgpt-account-id，之后才选传输，所以中转站那种普通 Key 会在任何请求发出之前就报 Failed to extract accountId from token——WS 和 SSE 一样到不了。中转站并不需要这个头：它用自己的 Key 认下游，再注入自己的上游 Codex 凭证，收到一个不是它签发的 chatgpt-account-id 也照样放行。所以插件按路由名合成一个未签名 token 交给 pi-ai，本该当 bearer 的真 Key 改走 x-api-key（pi-ai 原样透传）。留空 Key 的自建网关同样会收到这个合成 token，因为 pi-ai 没有 token 就建不出请求头。

只认 Authorization 的中转站会拒掉这种请求——它本来也跑不通这条协议，只是报错更早、更难懂。Key 本身就是带 chatgpt_account_id 的 JWT（中转站转发真 ChatGPT token）时，插件原样放过，不改 Authorization。

Fast 模式（Codex 速度模式）

Fast 模式在协议层就是请求体里的 service_tier，而且只有一个正确取值：priority。

OpenAI 在 2026-07-30 把 Priority processing 改名为 Fast mode，公开 API 因此同时接受 service_tier: "fast" 和 "priority"，但规范值仍是 priority。Codex CLI 也是这样：/fast 走的是 ServiceTier::Fast.request_value()，值为 "priority"；config.toml 里写 service_tier = "fast" 只是别名，加载时被归一化成 priority。它另外把哨兵值 default 在构造请求时整体剔除，所以 Codex 线上只有两种形态：带 service_tier: "priority"，或者根本不带这个字段。

DSH 自己从不发它（dsh-llm-pi-ai 里没有任何 service_tier），所以连接设置里新增了 Codex 速度模式，两档：

• 不设置（默认）——请求体里没有 service_tier，与本插件之前的行为一致。
• Fast 快速 —— 发送 service_tier: "priority"。速度与计费由上游决定：走 ChatGPT 凭证时按 OpenAI 文档提速约 1.5 倍并按更高倍率扣 credits；走 API Key 时是 Fast mode 的溢价单价。同一个字段值，计费面取决于上游用的是哪种凭证，而不是取决于你发哪个字符串。

不提供 fast 拼法，因为 pi-ai 的成本换算和回显纠正都只认 priority / flex（getServiceTierCostMultiplier、resolveCodexServiceTier）：发 fast 请求体等价，但 DSH 会把这一轮按标准价记账，界面上的实际档位也会显示成 default。也不提供 flex——那是更慢更便宜的档，方向与"速度模式"相反。

只有 Codex Responses 协议的模型会带这个字段，其余三种协议忽略它。

上游认不认要自己确认：ChatGPT 的 Codex 后端对这个字段既不校验也不回显（响应里的 service_tier 一律是 default，pi-ai 对这个回显本身就有 workaround），连 service_tier: "turbo" 都返回 200。CLIProxyAPI 转发 codex 请求时只删 parallel_tool_calls，字段会原样带到上游；它的 Keeper 请求日志有一列"速度模式"，显示"请求值 / 实际值"（例如 快速 / 标准），以那一列为准。

配置和凭据

插件设置使用命名空间 llm-relay-models。每个中转站保存 Base URL、模型列表、元数据映射、协议覆盖、排除列表、可选额外请求头、Codex 传输、流空闲超时和重试策略。API Key 使用从 Provider ID 生成的 credentials 引用，例如 relay-example 对应 RELAY_EXAMPLE_API_KEY，由 DSH credentials provider 管理。

请求图片上限沿用 dsh-llm-pi-ai 自己的取值（20 MiB / 2048² 像素 / 1 MiB），不再作为每个中转站的配置项：ResolvedPiAiProviderProfile 要求这三个数字，而 dsh-llm-pi-ai 既没导出它们也没导出自己的 resolver，所以插件按同样的值传入。

不要使用官方路由名作为 Provider ID，应使用 relay-*。保留名不再是插件里的硬编码表：节点侧读装机 pi-ai 的 builtinProviders()，页面侧读它已经持有的模型目录，所以 pi-ai 新增 provider 时无需改这个插件。此插件只在 Web profile 加载（依赖 connection）。

保存时会先完整解析一遍 Provider（含建模），解析不通过的配置在写入处就被拒绝，不会出现“保存成功但路由没生效”。