Windows-Copilot-API：把消费版 Copilot 网页会话包装成 OpenAI 接口

它真正绕开的是计费与密钥，不是模型能力

Copilot 网页本身对普通账号开放，但没有公开的 API 入口。这个项目的做法是复用你浏览器里已经登录的会话，把网页聊天行为自动化，再在本地暴露一个 HTTP 层。README 的定位很清楚：使用你自己的 Microsoft Copilot 账号，没有 API key、没有 credits、没有付费计划。

目标用户是个人开发者。README 举了一个具体场景：在匿名 Copilot 被封锁的地区（它点名印度），已登录路径仍然可用。这一点比“免费”更实际，因为它说明项目的价值不完全在于省钱，而在于拿到一条能通的路。

需要提前说清的是，仓库描述里写的是访问 GPT-4 和 GPT-5 模型，但 README 正文没有给出任何模型选择参数或型号映射表。模型名在示例里统一写成 model="copilot"，服务端如何把它对应到具体后端，材料里看不到。所以“能选 GPT-5”这个说法，目前只能当作仓库描述，不能当作可配置能力。

会话、Cloudflare clearance 与 chat token 是两条不同的生命线

机制上分三层。最底层是 Playwright 驱动的 Chromium，登录时打开一个可见浏览器，你手动完成微软或 Google 账号登录。登录检测通过后浏览器自动关闭，会话落到 session/ 目录，该目录被 git 忽略。

中间层是两种凭据。README 描述了登录后会发送一条短预热消息，作用是同时拿到 chat token 并通过 Cloudflare 的“verify you're human”检查。这两样东西寿命不同：chat token 可以在无头环境下刷新，Cloudflare clearance 不行。

最上层才是接口。Python 侧是 CopilotClient，chat() 返回完整文本和 conversation_id，把 id 传回去就延续同一轮对话；stream() 逐块产出。服务侧是 app.py，监听 127.0.0.1:8000，暴露 /v1/chat/completions，支持 "stream": true。多轮对话靠 conversation_id 寻址，这是它和 OpenAI 原生 messages 数组语义不完全一致的地方，README 没有说明服务端是否会把 messages 数组折叠成一次 Copilot 调用。

安装路径与两个必须记住的命令

依赖是 Python 3.9+，跨 Windows、macOS、Linux。核心步骤是三步：pip install -r requirements.txt，playwright install chromium，然后 python -m copilot login。登录是唯一需要人眼介入的环节，README 特别说明浏览器会自动关闭，不需要你按回车，并且如果出现复选框，要在那个登录窗口里点一下。

启动服务是 python app.py。客户端接入时 api_key 字段必须填但会被忽略，base_url 指向 http://localhost:8000/v1，模型名写 copilot。也可以直接用 curl 打 /v1/chat/completions。

Docker 路径有个前置条件容易被跳过：必须先在有图形界面的宿主机上完成登录，因为登录需要可见浏览器，容器里跑不了。容器通过 bind mount 复用 session/，compose 文件映射 8000 端口，并暴露 RATE_LIMIT_RPM 和 RATE_LIMIT_BURST 两个限流参数供调整。不用 compose 时，docker run 也要手动把 session 目录挂进去。

30 分钟这个数字决定了它能用在什么场合

README 里最硬的一条限制是：容器无法自行获取新的 Cloudflare clearance，clearance 大约 30 分钟后过期，之后服务返回 503，解决办法是回到宿主机重跑 python -m copilot login。

这意味着它不是一个能长期无人值守运行的服务。任何把它当作后台依赖的设计都会在半小时后开始报错，而且错误形态是 503，不是鉴权失败，排查时容易误判成上游故障。

同一段材料还暴露了另一个边界：登录流程依赖可见浏览器。这在 CI、无头服务器、纯远程开发机上直接不成立。README 的措辞是登录步骤打开一个可见浏览器，无法在无头容器内运行，没有提供替代方案。

再叠加它自己的免责声明，项目是自动消费版 Copilot 网页体验，README 要求负责任使用并遵守微软条款。把它接到面向外部用户的产品里，风险和责任都在使用者这一侧。

和直接用官方 OpenAI 接口相比，差在哪

最直接的替代是官方 OpenAI API。差别不在模型质量，而在契约：官方接口有密钥管理、配额、错误码语义和版本稳定性，你可以把 base_url 写死然后长期不管。这个项目的 base_url 同样写死，但底层凭据会周期性失效，且失效后需要人工介入。用一句概括：官方接口的失败模式是配额和鉴权，这个项目的失败模式是会话过期。

另一个替代是 Azure OpenAI 或微软自家的正式接口。README 没有提到任何官方通道，也没有把自己和它们做对比，所以这里只能指出方向：如果需求是稳定调用，就不该走消费版网页这条路。

如果只是想在 Python 里试 prompt，其实可以不启服务，直接用 CopilotClient 的 chat() 和 stream()，少一层 HTTP 和端口占用。README 把这种用法列为 Usage 1，说明作者也认为它是最简单的入口。

维护成本与 MIT 许可的实际含义

仓库没有发布任何 release，默认分支是 master，最近一次推送时间在材料中给出。没有版本号意味着没有兼容性承诺，pip 安装依赖后如果上游网页结构变化，出问题的地方会在 Playwright 选择器或登录检测逻辑里，而不是在你自己的代码里。

日常维护成本主要是重新登录。按 README 的说法，宿主机登录一次后会话会被保存并在每次运行时复用，所以个人本机使用下这个成本接近于零；一旦上容器或换机器，就要重新走一遍可见浏览器流程。README 还提到登录步骤会写入 session/login.log，并附带一个诊断工具，既修复常见的 captcha 和 clearance 问题，也生成可分享的报告。这是排查时唯一被点名的入口。

许可是 MIT。这意味着你可以修改、再分发、商用，但项目本身对微软没有任何授权关系，README 明确写了非官方、未获微软认可或背书。MIT 只覆盖这份代码，不覆盖你通过它访问的服务，两者是分开的。这里不构成法律意见，涉及条款判断请自行确认。

先验证再决定的三件事

第一，验证会话在你的机器上能撑多久。跑 python app.py，用 curl 打 /v1/chat/completions，然后隔一段时间重复，看什么时候开始返回 503。README 给的约 30 分钟是容器场景下的描述，你自己的环境是否一致，只有实测才知道。

第二，验证多轮对话的语义。README 里 Python 侧的 conversation_id 用法是明确的，但 OpenAI 兼容层收到的是 messages 数组，这两者如何对应没有写。如果你的应用依赖多轮上下文，先构造两轮消息看返回是否符合预期。

第三，验证模型名。示例统一用 model="copilot"，仓库描述里提到的 GPT-4 和 GPT-5 在 README 中没有对应的参数说明。如果你的代码需要指定型号，先确认这个字段是否真的起作用。

这三件事都能在本地半小时内跑完，跑完再决定是否把它接进任何长期运行的东西。

编辑结论

适合已经在本地登录 Copilot 网页、想用 openai SDK 快速验证 prompt 形态的个人开发者，或者需要把 Copilot 接进一个只认 OpenAI 格式的小脚本的人。不适合任何多用户服务、批量任务或需要稳定 SLA 的场景：文档明确写了容器内无法获取新的 Cloudflare clearance，约 30 分钟后会返回 503，只能回到宿主机重跑 python -m copilot login。采用前先确认两件事：一是你的使用场景是否落在微软消费版条款允许的范围内，README 自己就提示了这一点；二是你的代码能否容忍会话失效后的人工重登。如果这两条都过不了，就应该去看官方 Azure OpenAI 或直接调用其他有正式计费与配额承诺的接口。

官方来源

1. Issues
2. License: MIT
3. README
4. sums001/Windows-Copilot-API on GitHub