WindsurfAPI : exposer les modèles de Windsurf derrière trois API standard

Le problème : trois formats d'API pour un seul fournisseur de modèles

Windsurf, anciennement Codeium et désormais présenté comme Devin Desktop, donne accès à plus de cent modèles (Claude, GPT, Gemini, DeepSeek, Kimi, GLM, SWE) mais pas par une API publique au format standard. Le README annonce que le service expose simultanément trois familles de points d'entrée : POST /v1/chat/completions et POST /v1/completions pour OpenAI, POST /v1/messages pour Anthropic, POST /v1beta/models/* pour Gemini. Le public visé est nommément cité : Claude Code, Cline et Cursor, qui parlent Anthropic, plus tout client s'appuyant sur un SDK OpenAI. Concrètement, cela évite d'écrire une couche de traduction par outil. Le projet ne remplace pas un fournisseur de modèles : il change le format de sortie d'un accès existant. Si vous n'avez pas de compte Windsurf, cette brique ne vous sert à rien.

Le trajet d'une requête, du client HTTP jusqu'au cloud Windsurf

Le diagramme du README décrit une chaîne en trois étages. Le service écoute sur le port 3003 et reçoit le JSON du client, avec du SSE en retour pour le streaming. Une couche de traduction convertit OpenAI vers Anthropic vers Gemini selon la route appelée. Une seconde couche gère un pool de comptes avec rotation, isolation des limites de débit, bascule en cas de panne et disjoncteur. La requête part ensuite en gRPC vers un Language Server local, lui-même issu du binaire Windsurf, qui relaie en HTTPS vers server.self-serve.windsurf.com. Une voie alternative existe vers le cloud Devin, décrite comme DEVIN_CONNECT, en HTTPS direct et optionnel. Le détail qui compte pour la sécurité de vos données : la traduction ne s'arrête pas au format. Le service retire l'identité Windsurf des réponses pour que le modèle se présente comme Claude Opus 4.6 développé par Anthropic. C'est une décision de conception assumée, pas un effet de bord.

Ce que le service ne fait pas : exécuter les outils

Un point du README mérite d'être lu avant de se lancer. Les modèles ne manipulent pas vos fichiers. Quand Claude Code envoie une requête avec des tools, WindsurfAPI renvoie un bloc content_block de type tool_use, et c'est le client qui exécute edit_file() en local. Le proxy est donc un traducteur de protocole plus un gestionnaire de comptes, rien de plus. Cela a une conséquence pratique : la qualité de l'édition de code dépend entièrement du client, pas de ce service. Si vous cherchez un agent capable de lire et modifier un dépôt tout seul, WindsurfAPI n'est pas la pièce qui manque. Il fournit le modèle au client qui, lui, sait se servir d'outils.

Démarrage : port, binaire Windsurf et clés d'environnement

Le README renvoie vers une section intitulée 5 分钟跑起来 pour la mise en route, et vers docs/ENV-SWITCHES.md pour les variables d'environnement. La seule variable nommée dans le matériel fourni est DEVIN_CONNECT, qui active la voie directe vers le cloud Devin au lieu du Language Server. Le port par défaut est 3003. Le projet se présente comme sans dépendance npm, en JavaScript pur sur Node.js, ce qui élimine toute étape d'installation de paquets et réduit la surface d'attaque côté chaîne de dépendances. Ce que le matériel ne donne pas : la commande exacte de lancement, le nom des variables d'authentification, ni la procédure d'enregistrement d'un compte dans le pool. Il faut ouvrir docs/ENV-SWITCHES.md et le dossier docs/ avant de pouvoir démarrer, et je ne peux pas affirmer ici qu'une commande unique suffit.

La limite structurelle : un protocole interne qui bouge sans préavis

Le service parle gRPC à un Language Server propriétaire. Ce protocole n'est pas un contrat public : rien dans le matériel ne garantit sa stabilité, et une mise à jour du binaire Windsurf peut casser la traduction sans que le projet y soit pour quelque chose. Le rythme des versions va dans ce sens : v3.9.29 le 28 août 2026, v3.9.30 le 4 septembre, v3.9.31 le même jour. Trois publications en une semaine, dont deux le même jour, c'est le profil d'un projet qui court après un amont mouvant. Autre limite, plus terre à terre : POST /v1/completions est documenté comme non streaming, le prompt étant encapsulé en un seul tour utilisateur, et le README renvoie explicitement vers la route chat pour le streaming. Si votre outillage dépend de l'ancienne API Completions en flux, ce n'est pas le bon outil. Enfin, la licence MIT couvre le code, mais l'auteur ajoute une clause personnelle : usage commercial, revente, déploiement pour des tiers et service de relais payant sont interdits sans Star et Follow sur le dépôt. Cette clause n'est pas une licence open source au sens strict, et elle crée une ambiguïté juridique que chaque utilisateur doit évaluer, sans que je puisse donner un avis de droit.

Face à LiteLLM : traduire un protocole contre agréger des fournisseurs

LiteLLM est l'alternative évidente pour qui veut une façade OpenAI devant plusieurs fournisseurs. La différence d'approche est nette. LiteLLM s'appuie sur les API officielles de chaque fournisseur et normalise leurs réponses ; il gère des clés, des budgets et des journaux d'usage, et il est installable via pip. WindsurfAPI ne s'appuie sur aucune API officielle : il passe par le Language Server d'un client de bureau, avec un pool de comptes Windsurf et une couche qui masque l'origine des réponses. Le premier est un routeur de fournisseurs, le second un adaptateur vers un accès non documenté. Conséquence directe : WindsurfAPI n'a pas de gestion de clés par utilisateur ni de quotas par projet, et il dépend d'un binaire externe installé sur la machine. Si vous avez besoin de facturer des équipes ou de tracer la consommation par service, LiteLLM correspond mieux. Si vous voulez réutiliser un abonnement Windsurf existant depuis Claude Code, WindsurfAPI est la seule des deux options qui le fait.

Coût de maintenance et implications de licence

Le coût de maintenance se lit dans le journal des versions. Un projet qui publie v3.9.29, v3.9.30 et v3.9.31 en huit jours demande une mise à jour régulière si vous dépendez d'un modèle précis, parce que le chemin sous-jacent peut changer. La bonne nouvelle est qu'il n'y a pas d'arbre de dépendances npm à auditer : le README insiste sur le zéro dépendance, ce qui supprime les alertes de sécurité liées aux paquets transitifs. La mauvaise est qu'une partie du travail de maintenance est déléguée à l'amont : c'est le binaire Windsurf qu'il faut garder synchronisé avec le service. Sur le plan de la licence, le fichier LICENSE porte MIT, ce qui autorise la modification et la redistribution. La clause ajoutée dans le README, conditionnant l'usage commercial à un Star et un Follow, n'est pas un texte de licence et son opposabilité est incertaine. Un déploiement en entreprise devrait faire trancher ce point avant toute mise en production.

Conclusion éditoriale

WindsurfAPI convient à un développeur isolé qui possède déjà un compte Windsurf, accepte de faire tourner un service Node.js local et veut brancher Claude Code, Cline ou Cursor sur les modèles de Windsurf sans écrire de traduction de protocole. Ce n'est pas un outil pour une équipe qui a besoin d'un SLA, d'une facturation par utilisateur ou d'une API officielle : le projet repose sur un protocole interne non documenté publiquement, et la licence MIT ne couvre pas l'usage commercial que l'auteur restreint par ailleurs. Avant d'adopter, vérifier trois choses concrètes : que le binaire Windsurf est bien présent sur la machine puisque le service lance un Language Server, que le pool de comptes se comporte correctement quand un compte tombe, et que les routes /v1/responses et /v1/completions répondent comme vos clients l'attendent, car le README précise que /v1/completions ne gère pas le streaming.

Sources officielles

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