Pourquoi ce projet existait
Le point de départ était simple: permettre à Cursor de travailler avec d’autres modèles que ceux prévus nativement, en particulier DeepSeek au moment où le projet a été lancé. L’objectif n’était pas de refaire l’éditeur, mais de garder Cursor comme surface de travail tout en reprenant la main sur le modèle appelé derrière.
Comment le proxy fonctionnait
L’idée était d’exposer localement une API compatible OpenAI, puis de traduire les requêtes vers les modèles disponibles via OpenRouter. Pour Cursor, le point d’entrée restait familier. Pour l’opérateur, le vrai changement était la possibilité de choisir le modèle aval sans casser l’intégration existante.
Ce que cela debloquait
Ce proxy ouvrait une marge de manœuvre utile:
- conserver la compatibilité attendue par Cursor
- tester plusieurs modèles sans changer d’outil
- garder le contrôle sur la couche de routage et les hypothèses d’intégration
Les limites apparues en pratique
En pratique, Cursor envoie des prompts lourds et attend des réponses très strictes dans leur format. C’est précisément là que les limites apparaissaient vite: certains modèles plus faibles ou moins bien alignés sur ces contraintes ne répondaient pas de façon suffisamment fiable. Le projet rendait quelque chose possible, mais il montrait en même temps à quel point la compatibilité apparente ne suffit pas quand les attentes du client restent exigeantes.
Pourquoi l’idée reste utile
L’expérience reste intéressante aujourd’hui parce qu’elle parle moins d’un hack ponctuel que d’un sujet plus large: les contraintes de tooling dans les workflows agents. Le projet valait autant pour ce qu’il rendait possible que pour ce qu’il montrait: les limites d’un outil apparaissent vite quand on tente de lui faire parler d’autres modèles que ceux pour lesquels il a été pensé.