GitHub Copilot API Proxy 把 $10/月的 Copilot 订阅变成任意工具可接入的 OpenAI/Anthropic 兼容接口。本文先讲清楚它是什么（逆向代理 + 协议转换层），再讲针对 OPC 场景的四个改造：环境变量持久化（告别每次粘贴启动命令）、Admin 热切换（模型挂了不停工）、全链路自动账号轮换（限速后自动切账号/Provider）、Claude Direct（接纯血 Claude Pro，突破 160K 上下文限制）。

OPC 底座：Copilot API Proxy 是什么，我又改了什么

上两篇讲了我 OPC 的困境——不累但快饿死，流量高但变现接近零。今天聊支撑整个工作流的技术底座。

如果你也在用 AI 辅助干活，但总被「模型挂了」和「限速了要等半小时」这两件事打断思路，这篇文章或许有参考价值。

Copilot API Proxy 是什么？先弄清楚原理

很多人听说过这个工具，但不清楚它究竟做了什么。

GitHub Copilot 的尴尬处境

GitHub Copilot 订阅约 $10/月，背后接的是 GPT-4o、Claude Sonnet、Gemini 等一线模型。理论上性价比极高。

问题在于：Copilot 只有 IDE 插件，没有开放给外部工具使用的标准 API。

你想用 Claude Code、Cursor、Open WebUI、任何支持 OpenAI/Anthropic 协议的工具，直接接 Copilot？不行，GitHub 没有提供这条路。

Proxy 做了什么

copilot-api 项目（我用的是这个维护活跃的 fork）通过逆向工程，把 Copilot 的内部 API 包了一层，对外暴露成标准接口：

Claude Code / 任意工具
        │  Anthropic 协议 / OpenAI 协议
        ▼
Copilot API Proxy（本地 :4141）
        │  Copilot 内部协议（逆向）
        ▼
GitHub Copilot API → 背后的大模型

整个请求流程是：

你的工具发出标准 Anthropic 或 OpenAI 请求到本地 4141 端口
Proxy 把请求转换为 Copilot 格式，加上从 OAuth 流程拿到的令牌
发给 GitHub Copilot API
把响应转换回 Anthropic/OpenAI 格式，返回给你的工具

你的工具感知不到中间有这层代理，它以为自己在直接和 Anthropic 或 OpenAI 对话。

核心代码一瞥

Proxy 的核心是一个状态机，维护着当前使用的 Provider：

typescript

// state.ts
export interface State {
  provider: "openai" | "copilot" | "mimo" | "claude" | "ollama"
  openaiApiKey?: string
  copilotToken?: string
  keyStatus: Map<string, KeyStatus>
  providerSwitchLog: Array<ProviderSwitchLogEntry>
  isSwitching: boolean
}

每次收到请求，先走 ensureProviderAvailable() 检查当前 Provider 是否可用，不可用就切换，然后再转发请求。架构逻辑非常清晰。

暴露的端点

端点	说明
`POST /v1/messages`	Anthropic Messages API，Claude Code 走这里
`POST /v1/chat/completions`	OpenAI Chat Completions API
`GET /v1/models`	列出可用模型
`POST /v1/embeddings`	文本嵌入
`GET /admin`	Web 管理面板（仅 localhost）
`GET /usage`	Copilot 用量统计

Copilot API Proxy Admin 面板：模型映射配置界面

原版已经很好用，我为什么还要改

原版项目的核心功能已经够用了：

通过 /admin 面板添加 GitHub 账户（OAuth 设备流程，扫码授权）
多账户切换
速率限制控制（RATE_LIMIT 和 RATE_LIMIT_WAIT 环境变量）
Docker 一键部署

但我在 OPC 场景下遇到了几个具体的摩擦点，原版没有覆盖到，于是动手改了。

我的改造：四个具体问题的解法

改造一：环境变量持久化，告别每次粘贴启动命令

用 Copilot 代理接 Claude Code，需要覆盖几个环境变量：

bash

ANTHROPIC_BASE_URL=http://localhost:4141
ANTHROPIC_AUTH_TOKEN=dummy
ANTHROPIC_MODEL=claude-sonnet-4-6
ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-4-6
ANTHROPIC_SMALL_FAST_MODEL=gpt-4.1
ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-4.1
DISABLE_NON_ESSENTIAL_MODEL_CALLS=1

以前每次开新终端启动 Claude Code，都要粘贴这一长串。

解法：把这些变量写进系统环境变量（Windows 的「编辑系统环境变量」），永久生效。现在直接 claude，干净。

这是最小改动，但每天用下来节省的心智负担是真实的。古法编程讲「把精力留给真正需要判断的事情」，消除这类机械重复操作属于基础设施层面的优化。

改造二：Admin 面板热切换 Provider，当前对话不断

场景：Claude Sonnet 在 Copilot 里突然不可用了（GitHub 模型会时不时维护），或者单项目被限速（不是配额问题，是速率问题，要等 30~60 分钟）。

原版行为：遇到这种情况，你需要等。工作流断掉，思路打断。

改造后：打开 /admin，在 Model Mappings 或 Provider 配置里切换，当前对话继续跑，不用重启，不用等。

这个热切换能力不是凭空加的，它依赖于 Proxy 本身的状态管理架构——请求路由在运行时读 state.provider，而不是启动时写死。所以改变 admin 面板里的配置，下一条请求就走新路由了。

改造三：全链路自动轮换（账号 → key → Provider 降级）

这是我觉得改得最值的部分。

原版支持多账户手动切换。我加了自动降级逻辑：

GitHub Copilot 账号 A 限速
    → 自动切 GitHub Copilot 账号 B
    → 账号 B 也不行
    → 自动切 OpenAI（读取配置里的 keys 列表）
    → OpenAI key A 用完
    → 自动轮换 key B
    → 全部用完 → 返回 AllProvidersExhaustedError

实现在 provider-switch.ts 的 performSwitch() 函数里，核心逻辑是：

标记当前 key 为 exhausted（记录 exhaustedAt 时间戳，UTC 0 点自动重置）
遍历 keys 列表找下一个可用的
没有可用 key 就跌落到下一个 Provider
每次切换都记录到 providerSwitchLog（admin 面板可见）

在 OPC 场景里，这意味着：工作流跑着跑着遇到配额问题，自动切换，继续跑，我不知道。 只有事后看日志才发现「啊，刚才切了一次」。

改造四：Claude Direct——接纯血 Claude Pro

背景：Copilot 里的 Claude Sonnet 被限制成了 160K 上下文（官方是 1M）。高强度代码分析时，160K 明显不够用。

有朋友送了我一个月 Claude Pro。我想用 claude login 直接登录，让 Claude Code 走纯血 Claude，而不是 Copilot 里的阉割版。

问题：claude login 后，系统环境变量里的 ANTHROPIC_BASE_URL=http://localhost:4141 会覆盖原始设置，claude 命令会被 Proxy 劫持，根本走不到真正的 Anthropic。

解法：在 Proxy 里加 Claude Direct Provider：

typescript

// claude-credentials.ts
export function getClaudeOAuthToken(): string {
  const credPath = getCredentialsPath()
  const creds = readCredentialsFile(credPath)
  const token = creds.claudeAiOauth?.accessToken
  // ...
  return token
}

Proxy 读取 ~/.claude/.credentials.json 里 claude login 写入的 OAuth token，把自己伪装成「Claude Direct」Provider。当你在 admin 切到这个 Provider 时，请求直接用本地凭证打到真实的 Anthropic API，完全绕过 Copilot。

两边互不干扰：切 Claude Direct → 走真实 Claude Pro；切 Copilot → 走 Copilot 里的模型。同一个 claude 命令，后台 Provider 不同。

成本和风险，都说清楚

成本

成本项	金额
GitHub Copilot 个人版	$10/月
服务器资源（本机跑）	$0
维护时间（稳定后）	<30 分钟/月

这是我 OPC 技术底座目前最主要的外部支出。

真实的风险

逆向工程风险：这不是 GitHub 官方 API，是逆向出来的。GitHub 可能随时修改内部接口，导致 Proxy 挂掉。但上游项目有人在维护，通常几天内会跟进修复。

封号风险：README 里写得很清楚——

过度的自动化或脚本化使用 Copilot，可能触发 GitHub 的滥用检测系统。你可能收到安全警告，进一步异常活动可能导致 Copilot 访问权限被暂时停用。

我加了速率限制（RATE_LIMIT_WAIT=true），跑了快两个月，没有遇到警告。但不保证所有人都没问题，高频批量请求风险会更高。

上下文限制：Copilot 里的 Claude Sonnet 被限制到 160K，而官方是 1M。这是 GitHub 做的限制，Proxy 解决不了。需要更大上下文就得走 Claude Direct。

对古法编程理念的一点反思

回头看这套底座，它符合古法编程的一个核心原则：架构在人，AI 是员工。

我不是把 Claude Code 接上就算了。我想清楚了：

模型挂了，工作流应该继续 → 设计热切换
限速了，应该自动切账号，不打断我的思路 → 设计多账号轮换
需要更强的上下文，应该能切到纯血 Claude → 设计 Claude Direct

每一个功能点背后都有一个明确的「人的判断」在驱动。Proxy 只是把这些判断实现成了代码。

这就是 OPC 底座应该有的样子：不是把所有事情都扔给 AI，而是把「我已经想清楚了的决策」自动化掉，把精力留给还没想清楚的事情。

系列延伸：

常见问题

Q: 用 Copilot API Proxy 会封号吗？

A: README 里写得很清楚，过度自动化有风险。我的做法是开 RATE_LIMIT_WAIT=true（请求排队而非直接报错），避免短时间内高频并发。跑了两个月没遇到问题，但不保证对所有使用方式都安全——批量并发请求风险会更高。

Q: Claude 在 Copilot 里是阉割版，具体限制了什么？

A: 上下文窗口从官方的 1M 被压缩到 160K。对一般对话够用，但分析一个较大的代码库（几万行）就会明显不够。需要更大上下文时，要么用 Claude Direct（接纯血 Claude Pro），要么接受这个限制，拆分任务。

Q: 这套底座适合没有服务器的人搭吗？

A: 完全可以本机跑，Docker 一条命令搞定，只要你的电脑不关机就行。如果需要多台设备或者 24 小时可用，可以部署在 NAS 或小型云服务器上。我的方案是本机跑，够用了。

OPC 底座：Copilot API Proxy 是什么，我又改了什么 ​

Copilot API Proxy 是什么？先弄清楚原理 ​

GitHub Copilot 的尴尬处境 ​

Proxy 做了什么 ​

核心代码一瞥 ​

暴露的端点 ​

原版已经很好用，我为什么还要改 ​

我的改造：四个具体问题的解法 ​

改造一：环境变量持久化，告别每次粘贴启动命令 ​

改造二：Admin 面板热切换 Provider，当前对话不断 ​

改造三：全链路自动轮换（账号 → key → Provider 降级） ​

改造四：Claude Direct——接纯血 Claude Pro ​

成本和风险，都说清楚 ​

成本 ​

真实的风险 ​

对古法编程理念的一点反思 ​

常见问题 ​