用 Router One Key 运行 GitHub Copilot CLI（BYOK）

安装 Copilot CLI 1.0.89，并创建专用 Key

用 npm 安装（需要 Node.js 22 或更高版本）：npm install -g @github/copilot。GitHub 文档还给出了 Homebrew（brew install --cask copilot-cli）、WinGet（winget install GitHub.Copilot）以及 macOS 与 Linux 的安装脚本（curl -fsSL https://gh.io/copilot-install | bash）。1.0.89 于 2026-09-28 发布。然后在控制台 → API 密钥点「创建密钥」，为 CLI 单独建一把 Key 并设置 maxSpend 上限。CLI 以 agent 方式工作，每一轮模型调用都是一次请求，内置的 subagent（explore、task 与 code-review）也沿用同一套 provider 配置，所以一个任务可能产生很多次计费请求；这个上限就是硬性止损，专用 Key 也便于在日志里集中查看。

把 GitHub Copilot CLI 配置到 Router One base URL

在启动 CLI 的 shell 中设置 provider 变量，然后运行 copilot。COPILOT_PROVIDER_BASE_URL 填 https://api.router.one/v1，与 GitHub 自己的 OpenAI 示例写法一致。COPILOT_PROVIDER_TYPE 可以不设，或设为 openai——GitHub 文档说明这一类型适用于任何兼容 OpenAI Chat Completions 的端点。请显式设置 COPILOT_PROVIDER_WIRE_API=completions：GitHub 文档介绍了这个变量，但没有写明它在这一类型下的默认值，第三方的说法也不一致；显式指定后，每个请求都走 POST /v1/chat/completions，这个端点覆盖全部对话模型。Key 填在 COPILOT_PROVIDER_API_KEY，COPILOT_MODEL 填精确的目录 ID，也可以用 --model 传入。按 GitHub 文档，模型必须支持工具调用和流式输出，上下文窗口最好不少于 128k tokens。provider 配置无效时 CLI 会报错；按 GitHub 更新日志，它不会悄悄退回 GitHub 托管的模型。bash 或 zsh 的写法如下：

COPILOT_PROVIDER_BASE_URL

https://api.router.one/v1

# GitHub Copilot CLI → Router One (bash / zsh)
export COPILOT_PROVIDER_BASE_URL=https://api.router.one/v1
export COPILOT_PROVIDER_TYPE=openai
export COPILOT_PROVIDER_WIRE_API=completions
export COPILOT_PROVIDER_API_KEY=sk-your-router-one-key
export COPILOT_MODEL=anthropic/claude-sonnet-5
copilot

每个 Router One 模型 ID 该用哪种 provider 类型与 wire API

Router One 在 Chat Completions 上提供全部对话模型，所以上面的配置可以填 Claude、GPT、Gemini、Grok 与 DeepSeek 的 ID。另外还有两种组合。设置 COPILOT_PROVIDER_WIRE_API=responses 时，CLI 调用 POST /v1/responses，Router One 在这个端点上原生提供 GPT 系列、DeepSeek V4 与 Grok 对话模型；Claude ID 发到这里会在调用任何模型之前被 HTTP 400 拒绝（model '<id>' must be called via /v1/messages or /v1/chat/completions）。设置 COPILOT_PROVIDER_TYPE=anthropic 时，Base URL 填主机根地址 https://api.router.one（与 GitHub 的 Anthropic 示例使用 Anthropic API 主机根的写法一致），CLI 改用 Anthropic Messages，Router One 在这个端点上提供 Claude 系列与 DeepSeek V4 的 ID；其他对话模型会收到提示 must be called via /v1/chat/completions 的 400。无论哪种组合，都请优先选模型页标明支持工具调用的 ID，并在开始长任务之前先试一次工具调用。

Token 上限：MODEL_ID、MAX_PROMPT_TOKENS 与 MAX_OUTPUT_TOKENS

按 GitHub 文档，CLI 通过一个「well-known」模型名识别模型能力和 Token 上限，这个名字可以由 COPILOT_PROVIDER_MODEL_ID 提供；实际发给 provider 的模型名则来自 COPILOT_MODEL，设置了 COPILOT_PROVIDER_WIRE_MODEL 时以它为准。文档没有列出哪些名字算 well-known，也没有说明 anthropic/claude-sonnet-5 这类带厂商前缀的 Router One ID 能否被识别，所以本指南不去猜 COPILOT_PROVIDER_MODEL_ID，而是直接设置上限。GitHub 文档把 COPILOT_PROVIDER_MAX_PROMPT_TOKENS 说明为单次请求允许的最大 prompt Token 数：请让它不超过该模型在 Router One 详情页上的上下文窗口（anthropic/claude-sonnet-5 为 1048576，deepseek-v4.1-flash 为 1000000），并记住每个输入 Token 都计费。对于模型页列出长上下文价格（整次请求按该价格计费）的 ID，例如输入超过 272,000 Token 的 openai/gpt-5.6-sol，按 GitHub 的说明，把它设在门槛以下应能让 prompt 保持在门槛之内；CLI 如何执行这个上限，文档没有说明。COPILOT_PROVIDER_MAX_OUTPUT_TOKENS 是你为每次回复自定的上限；CLI 在 completions wire 上用哪个字段发送它，文档没有说明，而 Router One 的 Chat Completions 参考文档写的输出上限字段是 max_tokens。除非想要更低的上限，否则不必设置。

# 可选：自定 prompt 上限，不超过模型页上的上下文窗口
export COPILOT_PROVIDER_MAX_PROMPT_TOKENS=200000

为什么本指南保持使用 completions wire

Copilot CLI 1.0.64 为 BYOK 的 OpenAI 兼容 provider 加入了 WebSocket Responses 支持。Router One 的 /v1/responses 通过 HTTP 流式返回，没有 WebSocket 模式；GitHub 文档也没有说明 CLI 何时在 responses wire 上使用 WebSocket、是否会退回 HTTP，所以推荐配置保持 COPILOT_PROVIDER_WIRE_API=completions。如果你用 GPT ID 试了 responses wire，而请求在任何输出之前就失败，请改回 completions。CLI 的更新日志说，从 1.0.13 起它的推理强度设置也适用于自带模型的 provider。请求带有 reasoning_effort 时，对 Claude 系列 ID，Router One 不会把它转换为 thinking 设置；Claude Opus 5.5 例外，会映射到 output_config.effort。其他模型可能忽略它，也可能以 400 拒绝请求，所以修改后请到日志里看下一次请求的状态。

哪些请求会走你的 Key，以及如何看日志

配置 Router One provider 后，CLI agent 的每一轮模型调用都是这把 Key 上的一次请求，内置的 explore、task 与 code-review subagent 的调用也包括在内。登录 GitHub 是可选的：登录后可以使用 /delegate、GitHub 代码搜索和 GitHub MCP server 等 GitHub 功能，而模型请求仍然发往 Router One。按 GitHub 更新日志，COPILOT_OFFLINE=true 会让 CLI 不再联系 GitHub 的服务器并关闭遥测；你的 prompt 和代码上下文仍会发到 Router One，它是一个远程 provider。在控制台 → 日志中按 CLI 专用的 Key 筛选：每条记录显示模型、Token、费用、状态、总耗时，以及产生过输出的流式请求的首字延迟（TTFT）。401 表示 Key 缺失或错误，402 表示钱包余额或该 Key 的 maxSpend 已用完，400 且提示 must be called via 说明当前的 provider 类型或 wire API 不服务这个 ID。

GitHub Copilot CLI 该填哪个模型 ID？

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

GitHub Copilot CLI 用的是哪种 API 协议？

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

在请求日志里核对 GitHub Copilot CLI 的调用

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

常见问题