WindsurfAPI: ein Node.js-Reverse-Proxy, der Windsurf-Modelle in drei API-Dialekte übersetzt

Ein Kontingent, viele Clients: das Problem hinter dem Proxy

Windsurf, ursprünglich Codeium und heute als Devin Desktop geführt, bündelt in seinem Abonnement eine große Zahl fremder Modelle: Claude, GPT, Gemini, DeepSeek, Kimi, GLM, SWE. Diese Modelle sind aber nur über die eigene Oberfläche und die eigene Protokollschicht erreichbar. Genau dort setzt das Projekt an. Es übersetzt die drei verbreiteten HTTP-Dialekte, also OpenAI Chat Completions, Anthropic Messages und die Gemini-Endpunkte unter /v1beta/models, in das interne Format von Windsurf. Die Zielgruppe ist eng umrissen: Entwickler, die bereits einen Windsurf-Zugang besitzen und diesen Zugang mit Werkzeugen nutzen wollen, die ausschließlich OpenAI- oder Anthropic-Schnittstellen sprechen. Ein zweiter Adressat sind Teams, die mehrere Windsurf-Konten besitzen und deren Anfragen über einen gemeinsamen Endpunkt bündeln möchten, statt in jedem Editor eine eigene Anmeldung zu pflegen. Wer kein Windsurf-Konto hat, für den löst das Projekt nichts.

Der Weg einer Anfrage: HTTP rein, gRPC raus

Der Datenfluss ist in der README als Diagramm hinterlegt und lässt sich in vier Schritten beschreiben. Erstens nimmt der Dienst auf Port 3003 eine HTTP-Anfrage entgegen, wahlweise im OpenAI-, Anthropic- oder Gemini-Format. Zweitens übersetzt eine Protokollschicht den Rumpf in eine Anfrage, die das Repository als Cascade-Request bezeichnet. Drittens geht diese Anfrage per gRPC an einen lokal laufenden Language Server, also an den Windsurf-Binärprozess auf derselben Maschine. Dieser Language Server spricht seinerseits per HTTPS mit server.self-serve.windsurf.com. Viertens läuft die Antwort denselben Weg zurück und wird wieder in das Ausgangsformat gegossen, bei Streaming als Server-Sent-Events. Bemerkenswert ist die Rolle des Language Servers: Er ist kein optionaler Bestandteil, sondern der einzige Weg nach draußen. Die README zeigt daneben einen gestrichelten Pfad direkt zum Devin-Cloud-Backend, gesteuert über den Schalter DEVIN_CONNECT. Dieser zweite Weg ist als optional markiert, und die Dokumentation beschreibt ihn deutlich dünner als den Language-Server-Pfad. Wer Devin ohne lokale Windsurf-Installation nutzen will, sollte diesen Punkt zuerst prüfen, statt ihn als gleichwertige Alternative anzunehmen.

Drei Dialekte auf einem Port, mit unterschiedlicher Reife

Die Endpunktliste ist nicht symmetrisch, und das ist eine bewusste Designentscheidung mit Folgen. POST /v1/chat/completions deckt den OpenAI-Chat ab und trägt Streaming. POST /v1/completions bedient die alte Completions-Schnittstelle, aber ausdrücklich nur nicht-streamend: Der Parameter prompt wird laut README in einen einzelnen User-Turn verpackt, für Streaming verweist die Dokumentation auf den Chat-Endpunkt. POST /v1/responses bedient das neuere OpenAI-Responses-Format, ergänzt um GET und DELETE auf /v1/responses/{id} zum Lesen und Löschen gespeicherter Antworten, wobei diese beiden Aufrufe einen Identitäts-Header verlangen. POST /v1/messages bedient Anthropic, also Claude Code, Cline und Cursor. POST /v1beta/models/* bedient das Gemini-SDK. Praktisch heißt das: Ein Client, der auf die alte Completions-Schnittstelle mit Streaming setzt, wird hier nicht glücklich. Ebenso sollte man die gespeicherten Responses nicht als persistentes Protokoll missverstehen, denn der Löschaufruf existiert genau deshalb, weil serverseitig Zustand entsteht.

Installation: Node.js, Umgebungsvariablen und der Pfad zum Language Server

Das Projekt beschreibt sich als abhängigkeitsfreies Node.js-Programm, es gibt also keinen npm install-Schritt für Laufzeitbibliotheken. Für den Start nennt die README Port 3003 als Vorgabe. Die zentrale Stellschraube ist der Pfad zum Windsurf-Binärprozess, den die Dokumentation unter dem Schlüssel WIND_LS_BIN führt. Ohne diesen Pfad findet der Proxy seinen gRPC-Gegenpart nicht. Ein zweiter Schalter, DEVIN_CONNECT, aktiviert den optionalen direkten Weg zum Devin-Cloud-Backend. Eine vollständige Liste weiterer Umgebungsvariablen liegt in docs/ENV-SWITCHES.md, das die README verlinkt. Für die Client-Seite ist der Aufwand gering: Claude Code, Cline und Cursor werden auf die Basisadresse des Proxys gezeigt, weil sie bereits Anthropic-kompatibel sprechen. Wer den OpenAI-Weg nimmt, setzt die Basis-URL auf den Proxy und lässt den SDK-Pfad /v1/chat/completions unverändert. Die README betont an dieser Stelle einen Punkt, der häufig falsch verstanden wird: Die Modelle selbst bearbeiten keine Dateien. Dateizugriffe führt der Agent-Client lokal aus, der Proxy leitet nur Text und tool_use-Blöcke weiter.

Kontenpool, Identitätsneutralisierung und die Frage der Stabilität

Zwei Mechanismen tragen die Betriebstauglichkeit. Der erste ist ein Kontenpool mit Round-Robin, getrennter Ratenbegrenzung pro Konto, Failover und einer Circuit-Breaker-Logik. Das ist die Antwort auf das offensichtlichste Problem: Ein einzelnes Windsurf-Konto hat ein Kontingent, und ein Agent, der in einer Schleife Dateien liest und schreibt, verbraucht es schnell. Der zweite Mechanismus ist die Identitätsneutralisierung. Vor der Rückgabe entfernt der Proxy die Windsurf-Signatur aus der Antwort, sodass das Modell sich laut README als Claude Opus 4.6 von Anthropic ausgibt. Das ist ein Kompatibilitätstrick, kein Sicherheitsmerkmal. Genau hier liegt auch die größte Unsicherheit des Projekts. Der gesamte Mechanismus hängt an einer inoffiziellen gRPC-Schnittstelle eines fremden Binärprozesses. Ändert Windsurf diese Schnittstelle, bricht der Proxy, und zwar nicht an einer Stelle, sondern an der Übersetzungsschicht. Die Release-Historie mit Versionen wie v3.9.29 bis v3.9.31 innerhalb weniger Wochen deutet auf eine hohe Änderungsrate hin. Wer den Dienst produktiv betreibt, sollte einplanen, dass ein Update des Windsurf-Clients den Proxy vorübergehend unbrauchbar macht.

Wann ein eigener Router die bessere Wahl ist

Die naheliegende Alternative ist ein Router wie LiteLLM, der viele Anbieter hinter einer OpenAI-kompatiblen Fassade bündelt. Der Unterschied liegt nicht im Funktionsumfang, sondern in der Herkunft der Modelle. LiteLLM spricht mit offiziellen, dokumentierten und vertraglich geregelten APIs von Anthropic, OpenAI und Google. WindsurfAPI spricht mit Windsurf und benutzt dabei dessen Modellzugang. Das hat zwei Konsequenzen. Erstens ist der Proxy nur so stabil wie die Schnittstelle, die er nachbildet, während ein Router auf versionierte Endpunkte mit Ankündigungsfristen baut. Zweitens ist die Abrechnung eine andere: Bei LiteLLM zahlt man pro Token beim Anbieter, bei WindsurfAPI nutzt man ein bestehendes Windsurf-Abonnement. Wer ohnehin direkt bei Anthropic oder OpenAI einkauft, gewinnt durch WindsurfAPI nichts und verliert eine zusätzliche Fehlerquelle. Wer dagegen ein Windsurf-Abonnement bezahlt und es mit mehreren Clients ausschöpfen will, für den ist der Ansatz sinnvoll. Die README selbst nennt die Begriffe Windsurf-Reverse-Engineering und Codeium-Reverse-Engineering, was die Einordnung klar macht: Es ist eine Nachbildung, keine Integration.

Lizenz, Wartung und die Erwartung an den Betreiber

Der Code steht unter der MIT-Lizenz, was Weitergabe und Veränderung erlaubt. Die README enthält daneben einen Abschnitt, den man nicht überlesen sollte: Der Autor formuliert dort eine persönliche Erwartung an Nutzer ohne Star und Follow und untersagt in diesem Fall kommerzielle Nutzung, Weiterverkauf, Fremd-Deployment und das Betreiben als öffentlich erreichbarer Weiterverkaufsdienst. Das ist ausdrücklich als persönliche Haltung und nicht als Lizenzbedingung gekennzeichnet, und nur die LICENSE-Datei ist rechtlich bindend. Wer den Dienst hinter einem offenen Endpunkt betreibt, sollte diese Unterscheidung kennen und selbst entscheiden, wie er sie gewichtet. Eine rechtliche Bewertung ist hier nicht möglich und auch nicht Aufgabe dieses Textes. Auf der Wartungsseite fällt die hohe Release-Frequenz auf: drei Veröffentlichungen zwischen dem 28. August und dem 4. September 2026. Das spricht für Aktivität und gegen ein totes Projekt, bedeutet aber zugleich, dass man einem beweglichen Ziel folgt. Ein Upgrade ist nicht optional, sondern eine Reaktion auf Änderungen auf der Windsurf-Seite. Wer den Proxy einsetzt, übernimmt damit eine Betriebsrolle, die ein normaler API-Client nicht hat.

Redaktionelles Fazit

Wer bereits ein Windsurf-Konto betreibt und Claude Code, Cline oder Cursor gegen Windsurf-Modelle laufen lassen will, findet hier einen schlanken, abhängigkeitsfreien Übersetzer. Für alle anderen ist es das falsche Werkzeug: Der Dienst hängt an einem lokalen Windsurf-Binärprozess, an einer inoffiziellen gRPC-Schnittstelle und an Kontingenten, die das Projekt nicht kontrolliert. Vor dem ersten Einsatz sollte man den Pfad zum Language Server in WIND_LS_BIN prüfen, ein einzelnes Modell über /v1/models auflisten und einen Streaming-Aufruf gegen /v1/messages mit einem eigenen Konto testen, bevor irgendetwas Produktives daran hängt.

Offizielle Quellen

1. dwgx/WindsurfAPI on GitHub
2. License: MIT
3. Project website
4. README
5. Releases