沉浸式翻译自定义 API 配置：用 OpenAI 兼容接口接入 Router One

填写沉浸式翻译的自定义 API 接口地址与 Key

打开沉浸式翻译 设置 → 翻译服务 → OpenAI，把服务从 Pro 切换为「自定义 API Key」。在 APIKEY 里粘贴你的 Router One Key。点「展开更多自定义选项」，填写「自定义 API 接口地址」。字段自带的说明写着「可填写 API Base URL 或完整接口地址」，而完整的 Chat Completions 地址是所有版本处理方式都一样的写法。然后打开「设置更多模型」，添加要用的目录 ID（见下文），再在「模型」里选中一个。点「点此测试服务」，翻译一个短页面，到控制台 → 日志按时间和模型找到对应的新记录，确认无误后再翻译整篇文档：

Custom API interface address（自定义 API 接口地址）

https://api.router.one/v1/chat/completions

# Immersive Translate → Settings → Translation Services → OpenAI
# 沉浸式翻译 → 设置 → 翻译服务 → OpenAI
Service（服务）:  Custom API Key（自定义 API Key）, not Pro
APIKEY:  sk-your-router-one-key
Custom API interface address（自定义 API 接口地址）, works in every version:
  https://api.router.one/v1/chat/completions
Set up more models（设置更多模型）:  -all,+anthropic/claude-haiku-4.5,+deepseek-v4-flash
Model（模型）:  pick one of the IDs you added, then click Verify service（点此测试服务）

地址怎么填：完整地址、/v1 还是只填主机名

沉浸式翻译会把你填的内容改写成实际的请求地址，而这条规则在不同版本间有变化。Chrome 应用商店分发的是 1.33.3（Edge 加载项商店目前是 1.33.1），1.33.3 几乎怎么填都能补全；Firefox 附加组件商店目前仍分发 1.30.2，对只填主机名的写法更严格。填完整地址，就不用管版本。以 /responses 结尾的地址会保留这个路径，而 Router One 的 /v1/responses 只服务 GPT 系列、DeepSeek ID 与 Grok 对话模型，所以请保持 /chat/completions。

用「设置更多模型」添加目录里的模型名称

OpenAI 服务内置的模型列表是 OpenAI 自己的名称，不带厂商前缀，比如 gpt-5.5、gpt-5.4-mini，所以要自己添加目录里的精确 ID。「设置更多模型」接受逗号分隔的列表：直接写名称就是添加（前面加 + 效果相同），-名称 隐藏一个内置名称，-all 隐藏全部内置名称，名称=显示名 可以给列表里已有的名称换一个好认的标签。例如 -all,+anthropic/claude-haiku-4.5,+deepseek-v4-flash,+google/gemini-3.1-flash-lite 只保留这三个。也可以在「输入自定义模型名称」里直接填一个 ID。ID 必须与 /models 完全一致，因为它会原样作为 model 字段发送，不认识的 ID 会被拒绝。当前单价在各模型详情页；翻译会让单价乘上大量 tokens，选之前先比较。

一个页面会发多少请求，以及怎么避开限流

OpenAI 服务每次请求最多发送 4 个段落（「每次请求最大段落数」），按官方文档，默认每秒最多 10 个请求，所以一篇长文章会在控制台 → 日志里产生几十条请求，每条按各自的输入和输出 tokens 计费。译文默认在本地缓存 30 天，重新打开已经翻译过的页面，可能一个新请求都不会发。频率相关的设置在「展开更多自定义选项」里：「每秒最大请求数」「每分钟最大请求数」「每次请求最大文本长度」「每次请求最大段落数」。Router One 对每把 Key 和每个账户都有默认的请求数与 token 限额。突发请求超过其中之一时，会返回 429，错误码是 RATE_LIMIT_EXCEEDED 或 TOKEN_QUOTA_EXCEEDED，并用 X-RateLimit-Scope 响应头标明是哪一项限额，对应的段落就会翻译失败。调低「每秒最大请求数」（官方文档建议翻译电子书时调到每秒 5 个左右）或「每分钟最大请求数」即可。APIKEY 也可以填多个用英文逗号分隔的 Key，文档称之为负载均衡，但同一个 Router One 账户下的多把 Key 仍共享账户限额。如果日常用量确实需要更高，Key 和账户的限额可以申请调高：发邮件到 support@router.one，写明账户 ID、Key 的名称和预计峰值。

选一个适合批量翻译的模型，以及质量校验

翻译会把同一类请求发上成千上万次，所以小而快、不带推理的对话模型通常最划算。可以考虑 anthropic/claude-haiku-4.5、deepseek-v4-flash、deepseek-v4.1-flash、google/gemini-3.1-flash-lite、google/gemini-3.7-flash 和 openai/gpt-5.6-terra。避开每次请求都会思考的 ID：anthropic/claude-opus-5.5 始终开启自适应思考，以 -thinking 结尾的 ID 默认开启思考，这样每一批都会额外按输出单价计费思考 tokens。沉浸式翻译 1.33.3 自己会调整一部分 GPT 请求：对匹配 gpt-5.6 及其 Sol、Terra、Luna 变体，以及 gpt-5.1、gpt-5.2、gpt-5.4、gpt-5.5 的名称，它会把 reasoning_effort 设为 none 并去掉 temperature，而且这个匹配也会命中 openai/gpt-5.6-terra、azure/gpt-5.6-sol 这类带前缀的 ID。每次拿到结果后，扩展会比较输出与输入的 token 数；比例超出范围（默认 0.21 到 8）时，它会丢弃这份译文，改用其他翻译方案。设置 strictPrompt: true 可以跳过这项校验，文档只建议在自定义提示词不是单纯翻译时这样做。

高级设置：temperature、超时、频率与输出上限

上面这些也都可以在 开发者设置 → Edit Full User Config 里用 JSON 设置，写在 translationServices.openai 下：temperature、requestTimeout（毫秒，AI 服务默认 101000）、limit（每秒请求数）、maxTextGroupLengthPerRequest、maxTextLengthPerRequest、用于附加请求字段的 bodyConfigs 和 headerConfigs、按模型覆盖的 modelsOverrides、strictPrompt 和 langOverrides。请求路径保存在 baseUrlApiPath 里，默认是 /chat/completions，这也是只填 base URL 能用的原因。有一个字段值得注意：当主机是 OpenAI 或 Azure 的，或者模型名称最后一段以 gpt-5、o1、o3、o4 开头时（openai/gpt-5.6-terra 也算），1.33.3 会把输出上限作为 max_completion_tokens 发送。Router One 的 Chat Completions 参考文档写的输出上限字段是 max_tokens，所以要限制输出长度，就在 bodyConfigs 里设置 max_tokens，之后扩展对所有模型都会用这个字段。编辑前先备份配置，JSON 写错时扩展会忽略整段配置：

{
  "translationServices": {
    "openai": {
      "temperature": 0.2,
      "requestTimeout": 60000,
      "limit": 5,
      "bodyConfigs": { "max_tokens": 2048 }
    }
  }
}

沉浸式翻译该填哪个模型 ID？

从 /models 页复制精确的模型 ID，保留大小写、连字符和版本后缀，不要用展示名称代替。打开该模型的详情页，核对支持的 API 端点、上下文窗口和工具调用等能力，再与沉浸式翻译当前选择的 provider 和功能对应。模型出现在目录里，不等于当前客户端能调用它的所有功能。建议为每个客户端或应用单独建 API Key，并设置 maxSpend 消费上限。

沉浸式翻译用的是哪种 API 协议？

OpenAI 兼容描述的是接口格式，不能据此推断 Chat Completions（/v1/chat/completions）、Responses（/v1/responses）和 Anthropic Messages（/v1/messages）可以互换。先核对工具当前版本、provider 配置和实际请求路径，再查模型详情与 API 兼容性事实页。一次普通对话成功，也不能证明服务端工具、历史状态或文件编辑功能都受支持。

在请求日志里核对沉浸式翻译的调用

先在沉浸式翻译发出一次简单文本请求，再到控制台 → 日志按时间、模型和 request_id 找到这条记录，核对 Token、花费、总耗时和状态码。成功后再分别验证流式输出、工具调用和多轮历史。失败时保留实际请求路径、完整错误消息及 request_id；没有对应日志时，先查客户端配置和网络，不能仅凭客户端报错认定是网关或上游故障。

常见问题