Windows-Copilot-API: Microsofts Consumer-Copilot als OpenAI-kompatibler Endpunkt

Ein Anmeldevorgang, der den Browser voraussetzt

Der Kern des Problems ist banal und zugleich der ganze Trick: Microsofts Copilot ist im Browser kostenlos, aber es gibt keine dokumentierte Schnittstelle, die ein Skript aufrufen könnte. Windows-Copilot-API setzt genau dort an. Nach dem einmaligen Aufruf von python -m copilot login öffnet sich ein sichtbares Browserfenster, der Nutzer meldet sich mit einem Microsoft- oder Google-Konto an, und die Anwendung speichert die daraus entstehende Sitzung im Verzeichnis session/. Dieses Verzeichnis ist laut README git-ignoriert. Die Zielgruppe sind damit Einzelpersonen und kleine Teams, die einen OpenAI-kompatiblen Endpunkt für Prototypen, lokale Werkzeuge oder Skripte brauchen, ohne Guthaben aufzuladen. Der Einsatz ist ausdrücklich als persönliche Nutzung beschrieben, das Projekt bezeichnet sich selbst als inoffiziell und nicht mit Microsoft verbunden.

Playwright, Cloudflare-Clearance und ein Warmschuss

Der Mechanismus ist eine Browserautomatisierung, kein HTTP-Client. Abhängig ist das Projekt von Playwright und dem Chromium-Build, der über playwright install chromium nachinstalliert wird. Nach erfolgreicher Anmeldung schickt der Login-Vorgang laut README automatisch eine kurze Nachricht, die zwei Dinge in einem Schritt erledigt: Sie erzeugt das Chat-Token und passiert gleichzeitig die Cloudflare-Prüfung. Ein sichtbares Kontrollkästchen muss in diesem Fenster vom Nutzer angeklickt werden. Die Protokolle landen in session/login.log, was die Fehlersuche ohne zusätzliche Instrumentierung möglich macht. Diese beiden Vorgänge, Token und Clearance, sind unterschiedlich langlebig, und das ist die wichtigste technische Eigenschaft des Projekts: Das Token lässt sich ohne sichtbaren Browser erneuern, die Clearance nicht.

Zwei Betriebsarten, ein gemeinsamer Sitzungsordner

Das Projekt bietet zwei Nutzungswege. Als Python-Bibliothek lädt CopilotClient() die gespeicherte Sitzung, chat() liefert den Text zusammen mit einer conversation_id, die man zurückgibt, um denselben Thread fortzusetzen, und stream() gibt die Antwort stückweise aus. Alternativ startet python app.py einen Server auf http://127.0.0.1:8000, der die OpenAI-Formate spricht, sodass das offizielle openai-Paket mit base_url="http://localhost:8000/v1" und einem beliebigen api_key funktioniert. Der Schlüssel wird vom SDK verlangt, aber laut README ignoriert. Beide Wege greifen auf denselben Ordner session/ zu, weshalb ein Wechsel zwischen Bibliothek und Server keine erneute Anmeldung erfordert. Das Modellfeld im Aufruf trägt den Wert copilot.

Der Docker-Betrieb endet nach etwa dreißig Minuten

Interessant ist die dokumentierte Grenze des Containerbetriebs. Der Login öffnet einen sichtbaren Browser, der in einem headless-Container nicht laufen kann. Deshalb muss python -m copilot login auf dem Host ausgeführt werden, bevor docker compose up --build startet. Der Container bindet session/ ein und erneuert das Chat-Token selbstständig, kann aber keine neue Cloudflare-Clearance erarbeiten. Das README nennt dafür eine Größenordnung von rund 30 Minuten, nach deren Ablauf der Dienst mit 503 antwortet, bis der Login auf dem Host wiederholt wird. Für einen unbeaufsichtigten Dauerbetrieb ist das ein Ausschlusskriterium, nicht ein Konfigurationsdetail. Wer den Container dauerhaft laufen lassen will, braucht einen Weg, den Login regelmäßig auf einem Host mit Anzeige zu wiederholen.

Rate Limiting als Selbstbeschränkung

Das Projekt bringt eine eigene Drosselung mit, steuerbar über RATE_LIMIT_RPM und RATE_LIMIT_BURST. Diese Parameter werden laut README in der docker-compose.yml gesetzt. Das ist bemerkenswert, weil die Begrenzung hier nicht dem Schutz eines eigenen Dienstes dient, sondern der Vermeidung von Auffälligkeiten gegenüber dem automatisierten Gegenüber. Wer die Werte nach oben dreht, verschiebt das Risiko nicht weg, sondern nur in die Sitzung hinein. In dieselbe Richtung weist der Abschnitt zum Stresstest im Inhaltsverzeichnis: Das Projekt kennt seine Belastungsgrenze und macht sie konfigurierbar, statt sie zu verbergen. Ob die Standardwerte konservativ genug sind, lässt sich aus dem vorliegenden Material nicht beurteilen.

Kein Ersatz für einen Vertrag mit einem Anbieter

Die naheliegende Alternative ist ein kostenpflichtiger Modellzugang über einen Anbieter mit dokumentierter API, etwa die offizielle OpenAI-Schnittstelle oder ein europäischer Anbieter mit Rechenzentrumsbetrieb. Der Unterschied liegt nicht in der Modellqualität, sondern in der Betriebsform: Dort ist der Endpunkt ein Produkt mit Zusagen, hier ist er eine automatisierte Weboberfläche, deren Verhalten sich ohne Ankündigung ändern kann. Ein weiterer Unterschied ist die Datenfrage. Bei einem gehosteten Anbieter ist vertraglich geregelt, was mit Eingaben geschieht. Hier laufen die Anfragen über ein persönliches Consumer-Konto bei Microsoft, und die Nutzungsbedingungen dieses Kontos gelten. Für vertrauliche Inhalte ist das der falsche Weg, unabhängig davon, wie gut die Technik funktioniert. Wer den Komfort der OpenAI-Formate ohne diese Bindung braucht, ist mit einem lokal betriebenen Modellserver besser bedient, auch wenn dieser eigene Hardware voraussetzt.

Wartung, Lizenz und der Blick auf die Modellliste

Der letzte Push liegt laut Repository-Angaben im Juni 2026, veröffentlichte Releases gibt es nicht. Das bedeutet: Updates kommen über den Branch master, es gibt keine Versionsnummern, an denen man einen Stand festmachen könnte. Wer das Projekt einsetzt, sollte einen festen Commit notieren, weil ein späterer git pull sowohl die Abhängigkeiten als auch das Sitzungsformat verändern kann. Die Lizenz ist MIT, was die Weitergabe und Veränderung des Codes erlaubt. Sie regelt aber nur den Code, nicht die Nutzung des Copilot-Dienstes; die Bedingungen des Microsoft-Kontos bleiben davon unberührt. Eine rechtliche Bewertung ist hier nicht möglich und auch nicht beabsichtigt. Praktisch zu prüfen ist vor dem ersten Einsatz, welche Modellkennungen /v1/models tatsächlich zurückgibt. Die Projektbeschreibung nennt GPT-4 und GPT-5, das README zeigt im Beispiel jedoch den Modellwert copilot. Ob sich dahinter eine feste Zuordnung oder eine Weiterleitung an das jeweils aktuelle Consumer-Modell verbirgt, geht aus dem Material nicht hervor, und genau diese Frage entscheidet, ob der Endpunkt für einen gegebenen Anwendungsfall brauchbar ist.

Redaktionelles Fazit

Wer bereits Copilot im Browser nutzt, Python 3.9 oder neuer zur Hand hat und einen lokalen OpenAI-kompatiblen Endpunkt für Experimente oder einzelne Skripte braucht, kann das Projekt ausprobieren. Wer einen stabilen Dienst mit Zusagen zu Verfügbarkeit und Datenabfluss benötigt, sollte es nicht als Produktionsbaustein einsetzen. Zuerst zu prüfen sind der Ablauf von python -m copilot login, die Lebensdauer der Cloudflare-Clearance und die tatsächliche Modellkennung, die /v1/models zurückgibt.

Offizielle Quellen

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