OmniCopilot：把一千两百个模型塞进 Copilot Chat 的「免费通道」

如果你每天在 VS Code 里写代码，模型选择器里通常只有寥寥几个选项——GPT-4o、Claude Sonnet、Gemini Pro，全都要按 token 付费，Copilot 订阅之外还得单独买 API Key。用量一超，账单立刻见顶。

OmniCopilot 想解决的问题很直白：**能不能让 Copilot Chat 这个已经用顺手的界面，变成一个聚合了上千个模型的「模型超市」？**而且不要钱。

这个仓库是 2026 年 8 月新建的 VS Code 扩展，TypeScript 编写，MIT 协议，两个多月冲到 142 星、32 个 fork。虽然在 PIFS 平台上还有 13 个 open issue，但作者 diegosouzapw 是持续高频输出的独立开发者，扩展版本号已经迭代到 1.3.0，最近一次提交就在几天前。

它到底解决什么问题

OmniCopilot 本体不提供任何模型能力，它是一块**「转接头」**。真正的模型来自它依赖的上游项目 OmniRoute——一个把 340 多家模型供应商、1200 多个模型统一到一个 OpenAI 兼容端点后的 AI 网关。

打个比方：OmniRoute 像是把全国所有发电厂并联进一张电网，OmniCopilot 则是插在编辑器上的那根转换线。VS Code 侧只需要认识一种「插头」（OpenAI 兼容协议），背后具体是哪家电厂、哪个型号，扩展不关心。

关键在于它接入的是 VS Code 原生的 LanguageModelChatProvider API，不是另起炉灶做一个聊天窗口。这意味着 Copilot Chat 里原有的能力——agent 模式、工具调用、MCP 支持、指令系统——全部原封不动地跑在你选的那个模型上。换模型这件事，不需要你学习任何新的界面。

核心能力拆解

**模型目录的构建逻辑是这个项目最有技术含量的部分。**扩展从 OmniRoute 拉取 /v1/models 目录后，会做两层过滤（见 src/catalogFilter.ts）：

1. 剔除非对话模型。OmniRoute 的目录里混着音频、图像、嵌入、重排、视频、内容审核等专用模型，这些模型在 /v1/chat/completions 上会被服务端直接拒绝（HTTP 400）。扩展通过 type 字段和 supported_endpoints 白名单（chat 与 responses）识别并剔除。

2. 去重镜像行。OmniRoute 默认 MODELS_CATALOG_PREFIX_MODE=dual，同一模型会同时以短别名（cc/claude-sonnet-4-6）和规范前缀（claude/claude-sonnet-4-6）两条记录出现。扩展请求 ?prefix=alias 只取一条，对不支持该参数的旧版服务端则靠 parent 字段回退。

其他实用功能：

• 组合模型（Combo）：OmniRoute 支持 priority、round-robin、cost-optimized、fusion 等路由策略，这些组合在扩展里表现为普通模型项，选中即自动在背后做故障转移。

• 配额感知的自动降级：免费额度耗尽时自动切换到其他可用供应商，避免对话中断。

• 推理强度控制：GPT-5.x、Claude thinking、DeepSeek R1、Gemini Thinking 这类模型支持 reasoning_effort 分级，扩展只对目录中标记为 reasoning-capable 的模型下发该字段，避免服务端 400。

• 视觉能力：目录中标记为 vision-capable 的模型可直接在对话中接受图片附件。

• 用量面板：侧边栏可显示当前 Key 的日/周花费、重置时间与各供应商连接配额（需 OmniRoute v3.8.50+ 提供 GET /api/usage/om-usage?format=json）。

• 一站式配置各家 CLI：一条命令即可为 Codex CLI、Claude Code、Cline、Roo、Continue、Cursor、Aider、Goose、Crush、OpenCode、Qwen Code 生成指向 OmniRoute 的配置档案。

• 42 种界面语言：包含简体与繁体中文。

安全设计：API Key 存放在 VS Code 的 SecretStorage（操作系统钥匙串），不写入 settings.json。

上手门槛

门槛低到有点反常，分三步：

1. 启动上游网关：npm install -g omniroute 然后 omniroute，本地起在 http://localhost:20128，仪表盘里配置供应商密钥。

2. 从 VS Code Marketplace 或 Open VSX 装这个扩展（Cursor、Windsurf、VSCodium、code-server 等分支通过 Open VSX 也能装）。

3. 打开 Copilot Chat → 模型选择器 → Manage Models… → 勾选 OmniRoute，模型即刻出现在下拉列表里。

已经部署了远程 OmniRoute（家用服务器、VPS、隧道）的，把地址填进连接面板即可，扩展会自动补 /v1 后缀。

版本要求：VS Code 1.104+。自 VS Code 1.122 起，第三方 provider 模型无需 GitHub 登录、无需任何 Copilot 套餐即可使用——这是 VS Code 官方规则，与本项目无关，但确实是它「免费」叙事成立的前提。

争议与局限

这个项目的商业模式和信任模型都需要使用者清醒认识：

一、它不是「模型」，是「模型转售与聚合」。免费额度来自各家供应商的免费套餐（90+ 家提供），这些额度的稳定性、限流策略、服务条款随时可能变化。免费承诺的兑现主体在第三方，本项目只是通道。

二、扩展本身完全依赖上游。OmniRoute 才是功能主体，OmniCopilot 只是它 1200 个模型目录在 VS Code 里的呈现层。上游一旦改协议或变更目录结构，扩展的诸多高级特性（用量面板、Agents 窗口暴露）会直接失效——README 里明确要求 OmniRoute v3.8.50+。

三、部分能力踩在 VS Code 未稳定的 API 上。把模型暴露到 Copilot Agents 窗口依赖 proposed API targetChatSessionType，作者因此默认关闭。若你的 VS Code 版本不支持该提案，模型会重复出现在普通选择器里而不是 Agents 窗口——README 给出的解法是关掉开关。

四、内嵌仪表盘是构建期开关，不是运行期。想在 VS Code 标签页内打开 OmniRoute 仪表盘，需要在源码构建时设置 DASHBOARD_ALLOW_EMBED=vscode。因为 Next.js 在构建期就把响应头烘焙进路由清单，事后在已安装的服务前面导出这个环境变量没有任何作用——预编译 npm 包和官方 Docker 镜像都不支持。扩展会检测到禁止内嵌并自动回落到外部浏览器，不会崩，但这个功能实际可用性有限。

五、代码补全不在覆盖范围。行内补全和基于嵌入的功能仍依赖 GitHub Copilot 本身，扩展只接管 Chat、Agent 模式与工具类任务。

六、企业策略可拦截。Copilot Business/Enterprise 管理员可通过「Bring Your Own Language Model Key」策略禁用第三方模型 provider。

七、单人主导的 bus factor。全仓库只有一位贡献者（diegosouzapw），源码约 10 万行 TypeScript，测试仅有一个 vitest 文件覆盖 Agents 窗口逻辑。文档相当详尽（README + CATALOG.md + PUBLISHING.md），但整体维护风险集中在一个人身上。

行业意义

OmniCopilot 折射的是 2026 年 AI 工具链的一条清晰主线：模型在商品化，聚合层在增值。

当 1200 个模型通过统一协议变得唾手可得，模型本身的差异化急剧下降，真正的价值转移到「我怎么找到最合适的那一个」「额度耗尽时怎么无缝接力」「怎么让同一个模型出现在我所有工具里」。OmniCopilot 的 Combo 策略、配额感知降级、跨 CLI 配置，正是对这一价值转移的精准回应。

它对国内开发者的意义更直接：Kimi、GLM、DeepSeek、Qwen、CodeGeeX 等一批国产模型都有免费层，通过 OmniRoute 统一接入后，可以在 Copilot Chat 这套已经被验证好用的交互里直接用上——不用换编辑器、不用改工作流、不用记多套 API Key。

另一层值得关注的信号是它对 Copilot 的「不替换而增强」策略。标题写着 1200+ 模型进 Copilot Chat，README 第一句却是「Don't replace Copilot — power it up」。在一个商业巨头产品的腹地做扩展，最聪明的做法往往不是正面竞争，而是占据它开放 API 留下的空位。这个项目 142 星、32 fork、13 个 open issue 的体量说明它找到了真实需求，但体量也说明它尚未成为现象级爆款——更像是精准补位者，而非破局者。