上周末 GitHub 上冒出一个叫 Windows-Copilot-API 的项目（sums001/Windows-Copilot-API），两天不到涨了 600 多星。做法很直接：把 Windows Copilot 的本地接口逆向成 OpenAI 兼容的 REST API，这样你本地跑的代码、脚本、agent 都可以通过标准的 /v1/chat/completions 调用 Windows Copilot 背后的大模型——目前能看到的是 GPT-4 和 GPT-5。
从成本角度看，这种方式完全绕过了 API 计费。不经过 Azure OpenAI 的计量管道，不走 Anthropic 的 token 账单，用的是一个已经激活的 Windows 系统本身附带的 Copilot 通道。对个人开发者、小团队、或者 prototyping 阶段来说，这等于多了一条零边际成本的模型调用途径。
不过站在部署视角，有几件事值得拆开想想：
权限模型是什么？ Windows Copilot 的本地 API 接口没有独立的 API key 机制——项目做的事情相当于把本地服务端口暴露出来。如果这个端口绑定在 0.0.0.0 或者被内网其他服务发现，等于把整个 Windows 机器的 Copilot 访问权开放给了局域网。不能简单把它当 OpenAI 替代品来用，网络隔离是前提。
稳定性没有 SLA。 Windows Copilot 的模型版本、接口行为、限流策略都由微软控制，随时可能变。这个项目本质上是在消费一个内部接口，不是公开 API。今天能用的端点，下个月 Windows Update 后可能就改了。
适合什么场景？ 我觉得对个人工作流来说，这个工具可以省掉每月几十刀的 API 开销——跑批量任务、做实验、测 prompt。对团队来说，它不适合作为生产推理的依赖，但可以用作本地开发环境的低成本备用通道。
跟其他本地推理方案比呢？ 跟 ollama / llama.cpp / vllm 这些纯本地方案不同，这个项目走的是 Windows 自带的云端推理通道——模型跑在微软的服务器上，不是本地。只是 API 层被本地拦截并转发了。所以它解决的问题不是「没有 GPU 怎么跑模型」，而是「不想付 API 费怎么用 GPT-4/5」。
如果你手上有 Windows 机器，这个项目值得试一下。部署思路跟自建推理完全不同，但能在某些场景下显著压低推理成本。
（配图：GitHub repo 的 OpenGraph 界面截图——sums001/Windows-Copilot-API 的仓库主页）
项目地址：github.com/sums001/Windows-Copilot-API
延伸阅读：微软 Copilot 架构文档 learn.microsoft.com/en-us/copilot/
讨论参考：news.ycombinator.com/item?id=42791449