Windows-Copilot-API：把消費版 Copilot 包成 OpenAI 相容介面
Reverse engineered Windows Copilot into an OpenAI-compatible API. Access GPT-4 and GPT-5 models through a simple REST interface without API keys or billing.
秒懂
- 它是什麼？
- 這個專案用 Playwright 驅動已登入的 copilot.microsoft.com，對外提供 /v1/chat/completions，讓 openai SDK 直接指向 localhost。省下的是 API 費用，付出的是 session 有效期與非官方自動化的不穩定性。
- 適合誰用？
- 如果你的程式已經寫好 OpenAI client，只想在開發或個人實驗中省下帳單，這個專案值得一試；若你需要可預期的延遲、穩定的併發或商業用途的授權保證，它不適合。動手前先確認三件事：python -m copilot login 能否在你的網路環境完成 Cloudflare 驗證、session/ 在容器或長時間執行下多久失效、以及 RATE_LIMIT_RPM 的預設值是否低於你的呼叫量。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 80 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是帳單問題，不是模型取得問題
多數人不是拿不到 LLM，而是不想為個人專案開一張信用卡。這個專案的做法是：不碰 Azure、不申請 API key，改為自動化你已經登入的免費 Copilot 網頁。README 的說法是把它變成「an API you can call from code」，並強調「No API key, no credits, no paid plan」。
目標讀者很明確：手上已經有 OpenAI 格式的程式碼、想接一個便宜或免費的後端來跑原型、個人自動化腳本或 agent 實驗的人。它不適合當成產品後端，因為底下是一條消費級網頁通道，而不是合約保障的推論服務。README 自己也標明「Unofficial project」，並要求使用者「within Microsoft's terms」。
另一個被低估的賣點寫在 Why use this 一節：已登入路徑在匿名 Copilot 被封鎖的地區（README 舉印度為例）仍可用。這對身處此類地區的開發者是實質差別，而不是行銷詞。
Playwright 驅動瀏覽器，session 就是你的憑證
架構上沒有什麼魔法。登入階段用 Playwright 開一個可見的 Chromium，你在裡面完成 Microsoft 或 Google 帳號登入；登入完成後瀏覽器自行關閉，不需要按 Enter。接著它送出一次短的 warm-up 訊息，README 說這一步同時取得 chat token 並通過 Cloudflare 的「verify you're human」檢查，代價是對話歷史裡會多一則無用的訊息。
之後每次執行都重用 session/ 底下的登入狀態（該目錄被 git-ignore）。Python 端是 CopilotClient，chat() 回傳文字與 conversation_id，把 id 傳回去就延續同一條對話，省略就開新對話；stream() 逐段吐出內容。伺服器端則是把同一套邏輯包成 /v1/chat/completions，支援 "stream": true。
關鍵在於：這裡的「認證」不是一把可以複製到別台機器的 API key，而是一組綁著瀏覽器指紋與 Cloudflare clearance 的 session。這是整個專案所有限制的根源。
兩分鐘安裝，但登入那一步不能跳過
文件給的流程很直白。先 git clone 與 cd Windows-Copilot-API，建立虛擬環境後安裝依賴：
pip install -r requirements.txt playwright install chromium python -m copilot login
Windows 上若被執行原則擋住，README 建議先跑 Set-ExecutionPolicy -Scope CurrentUser RemoteSigned，cmd.exe 則改用 venv\Scripts\activate.bat。登入過程寫入 session/login.log，出問題時看這個檔。
要用 OpenAI 相容伺服器，執行 python app.py，預設聽 127.0.0.1:8000。客戶端寫法就是標準的 OpenAI 形式，base_url 指向 http://localhost:8000/v1，api_key 隨便填，SDK 要求這個欄位但伺服器忽略它。模型名稱用 model="copilot"。不想裝 SDK 也可以直接 curl 打 /v1/chat/completions，body 只帶 messages 就能跑。
Docker 路線有個容易踩的順序問題：容器內沒有可見瀏覽器，所以必須先在主機上完成 python -m copilot login，再把 session/ 綁進去。docker compose up --build 會映射 8000 埠並 bind-mount session/，rate limit 透過 RATE_LIMIT_RPM 與 RATE_LIMIT_BURST 調整。
Cloudflare clearance 約三十分鐘到期，這是硬限制
README 對 Docker 的說明藏著最重要的一句話：容器可以無頭刷新 chat token，但無法在沒有可見瀏覽器的情況下取得新的 clearance，因此當 clearance 過期（文件寫約 30 分鐘）時，伺服器回傳 503，你得回到主機重跑 python -m copilot login。
這代表長時間掛著的服務會週期性失效。你的呼叫端必須處理 503 並具備重試或告警邏輯，否則半夜的排程任務會靜默失敗。這不是可以靠調參解決的效能問題，而是自動化消費級網頁的結構性代價。
第二個限制是速率。專案內建 rate limiting，但真正的上限由微軟那端決定，README 沒有給出可承受的併發數字，只提供 RATE_LIMIT_RPM / RATE_LIMIT_BURST 讓你自我約束。把這個服務當成高併發後端來規劃，是誤判。
第三，模型名稱與實際後端模型的對應關係，在提供的資料裡沒有說明。README 的標題提到 GPT-4 與 GPT-5，但 API 只接受 model="copilot"，你無法從介面指定版本。如果你的應用對模型版本有硬性要求，這裡給不了保證。
和直連 OpenAI API 比，差別在誰承擔不穩定性
最直接的替代方案就是原本的 OpenAI API。差異不在模型能力，而在責任歸屬：官方 API 給的是可複製的金鑰、明確的速率上限、版本化的模型名稱與服務層級；這個專案給的是綁在一台機器上的瀏覽器 session、三十分鐘的 clearance、以及一個由網頁改版決定的介面。
如果你的程式碼已經用 openai SDK 寫成，切換成本確實只有 base_url 一行，這也是它最大的實用價值：先用它驗證流程，等真的要上線再換回官方端點。反過來說，任何需要 SLA、需要多台實例共用、需要審計日誌的場景，這個專案都不該出現在架構圖裡。
另一個思路是直接用微軟官方的 Azure OpenAI 或 Copilot 相關服務，代價是回到申請與計費流程。這個專案存在的意義，正是服務那些不願意走那條流程的人。
維護成本與 MIT 授權的實際含義
專案以 MIT 授權釋出，這表示你可以自由使用、修改與再散布，條款要求保留著作權與授權聲明。但授權只涵蓋這個專案的程式碼，不涵蓋你透過它存取的 Copilot 服務，後者受微軟自己的條款約束，README 也提醒使用者要自行負責。這不是法律意見，實際使用前應自行確認微軟的服務條款。
維護面上，這類專案的成本不在依賴更新，而在外部介面變動：只要 copilot.microsoft.com 的登入流程、Cloudflare 檢查或回應格式改變，自動化就可能失效，而修復只能等維護者跟上。專案沒有檢索到任何 release，也就是說沒有版本化的相容性承諾，你追的是 master 分支的當下狀態。
升級前值得先看 session/login.log 的內容與 examples/ 底下的三支範例是否仍與 README 一致，這比讀 changelog 更能反映實際可用性。
編輯結論
如果你的程式已經寫好 OpenAI client，只想在開發或個人實驗中省下帳單，這個專案值得一試；若你需要可預期的延遲、穩定的併發或商業用途的授權保證，它不適合。動手前先確認三件事：python -m copilot login 能否在你的網路環境完成 Cloudflare 驗證、session/ 在容器或長時間執行下多久失效、以及 RATE_LIMIT_RPM 的預設值是否低於你的呼叫量。這三項決定了它是能長期掛著的服務，還是每次都要重新登入的玩具。
社群筆記