Contexte technique
Je me suis penché sur ce cas d'usage non pas en spectateur, mais en tant que personne qui conçoit constamment des AI integration dans les outils de travail. Le principe est simple : dans Cursor, on peut spécifier une custom URL pour un fournisseur compatible OpenAI dans Settings → Models, saisir la clé et activer l'override base URL. Sur le papier, c'est presque idéal.
Mais ensuite, la réalité s'impose. Si vous voulez faire passer un abonnement GPT ou un proxy de traduction de requêtes dans Cursor, vous vous heurtez à l'API réellement appelée par le client. D'après les retours et l'analyse de la documentation, le chemin personnalisé de Cursor passe souvent par /chat/completions, tandis que les nouveaux scénarios GPT attendent parfois déjà l'Responses API.
Et là, je ne promettrais pas de miracle. Pour les endpoints OpenAI-compatible classiques, cela démarre souvent très vite. Pour les modèles GPT récents ou les systèmes d'abonnement, il faut soit un proxy conçu avec soin pour traduire le format des requêtes, soit accepter que certaines fonctionnalités se comportent de manière erratique.
Je comprends tout à fait pourquoi on fait cela. Ce n'est pas pour les benchmarks, mais pour l'UX : Composer 2.5, exploration, travail sur l'interface utilisateur, corrections rapides de code dans un seul environnement. Dans ce mode, build AI automation au sein de l'IDE est vraiment plus agréable que de jongler entre le CLI et le web.
Concernant la consommation de Composer, j'ai relevé un indicateur pratique important : sur une nouvelle base de code, il consomme nettement plus les premiers jours, puis un mécanisme similaire à du cache intelligent s'active. Lors des discussions, un repère a été évoqué : sur deux semaines d'utilisation moyenne, environ 60 % ont été consommés, les premiers 30 % étant partis très rapidement. Ce n'est pas un test scientifique, mais cela donne un excellent repère de terrain.
Ce que cela change pour le business et l'automatisation
En résumé, les équipes qui privilégient la vitesse de réflexion à une architecture stérile sont gagnantes. Cursor, avec un bon modèle intégré, accélère réellement l'exploration du code, les itérations de l'interface utilisateur et la routine d'ingénierie mineure.
Les perdants sont ceux qui espèrent qu'un custom endpoint fournira automatiquement un remplacement économique et fluide de l'intégration officielle. Ce ne sera pas le cas si les protocoles ne correspondent pas. Un seul niveau de compatibilité défaillant, et l'agent commence à se comporter bizarrement tandis que les coûts augmentent sans aucun bénéfice.
Je suggérerais ici deux solutions : soit concevoir dès le départ un proxy adapté au format de requête spécifique, soit éviter de toucher à ce schéma fragile là où l'équipe a besoin d'une UX de production prévisible. Chez Nahornyi AI Lab, nous analysons précisément ces goulets d'étranglement : là où l'AI implementation est requise pour accélérer l'équipe, et là où il vaut mieux concevoir un environnement robuste pour que l'automation with AI ne se transforme pas en une expérience coûteuse. Si Cursor, vos outils internes ou votre agent de code commencent déjà à consommer trop de temps et de budget, analysons votre scénario pour concevoir une solution sans magie inutile.