Cursor s’intègre à tous les modèles d’IA de pointe dédiés au code.

Chaque modèle nécessite des instructions spécifiques et des ajustements de l’infrastructure de notre Agent afin d’améliorer la qualité des résultats, d’éviter les comportements paresseux, d’appeler les outils de façon efficace, et plus encore.

Nous collaborons avec OpenAI pour rendre leurs modèles disponibles aux développeurs via l’Agent de Cursor. Cet article explique comment nous avons mis à jour l’infrastructure de notre Agent pour prendre en charge leur dernier modèle de code de pointe, GPT-5.1-Codex-Max.

#Créer une infrastructure robuste pour les agents

Chaque modèle au sein de l’infrastructure d’agents de Cursor dispose d’instructions spécifiques et d’outils mis à sa disposition pour optimiser ce modèle à l’intérieur de l’environnement Cursor.

Les laboratoires d’IA entraînent de nouveaux modèles sur une variété d’instructions et d’outils différents. Dans des domaines spécifiques comme la programmation, les modèles peuvent privilégier des schémas plus proches de ce qu’ils ont déjà vus pendant l’entraînement. Lors de l’ajout de nouveaux modèles à Cursor, notre rôle est d’intégrer des instructions et des outils familiers aux côtés de ceux spécifiques à Cursor, puis de les affiner sur la base de Cursor Bench, notre suite interne d’évaluations.

Nous mesurons la qualité et la robustesse des modèles en fonction de leur taux de réussite, de leur capacité à appeler des outils et de leur adoption globale par les utilisateurs. Voici quelques-unes des mises à jour que nous avons apportées à notre infrastructure d’agents pour Codex.

#Mise à jour vers le dernier modèle Codex

Les modèles Codex d’OpenAI sont des variantes de leur plus récent modèle de pointe, entraîné spécifiquement pour le codage piloté par des agents.

L’équipe d’OpenAI a étroitement collaboré avec nous pour aligner les outils et les prompts avec l’infrastructure Codex CLI. Voici quelques-uns des changements que nous avons apportés :

#Une approche plus axée sur le shell

La CLI Codex d’OpenAI est centrée sur des workflows orientés shell. En conséquence, le modèle Codex reçoit un ensemble limité d’outils pendant l’entraînement et apprend plutôt à utiliser le shell pour rechercher, lire des fichiers et effectuer des modifications.

Si le modèle a du mal avec une modification complexe, il se rabat parfois sur l’écriture de fichiers via un script Python en ligne. Ces scripts sont puissants, mais l’appel d’outils est à la fois plus sûr et offre une meilleure expérience utilisateur pour les modifications dans Cursor.

Pour encourager l’appel d’outils, nous avons rapproché les noms et définitions des outils dans Cursor de leurs équivalents dans le shell comme rg (ripgrep). Nous avons appliqué ce changement à tous les modèles de notre banc d’essai. Nous avons également ajouté des instructions comme :

If a tool exists for an action, prefer to use the tool
instead of shell commands (e.g. read_file over `cat`).

Le sandboxing dans Cursor, qui empêche l'accès non autorisé aux fichiers et l'activité réseau sans obliger les utilisateurs à approuver manuellement chaque commande, contribue également à renforcer la sécurité si le modèle décide malgré tout d'exécuter une commande shell.

#Préambules

Contrairement à la série principale de modèles GPT-5, la famille de modèles Codex utilise actuellement des résumés de raisonnement pour communiquer les mises à jour à l’utilisateur pendant leur exécution. Ceux‑ci peuvent prendre la forme de titres d’une ligne ou d’un message complet.

Pour ces résumés de raisonnement, nous avons voulu trouver un équilibre permettant aux utilisateurs de suivre la progression de l’agent et d’identifier rapidement les mauvaises trajectoires, sans les inonder au point qu’ils cessent de prêter attention. Nous avons donné au modèle des consignes pour limiter les résumés de raisonnement à 1 ou 2 phrases, signaler lorsqu’il découvre une nouvelle information ou initie une nouvelle tactique, et éviter de commenter sa propre communication (« Je suis en train d’expliquer à l’utilisateur… »).

Étant donné que les modèles Codex ne peuvent pas « parler » normalement avant la fin d’un tour de l’agent, nous avons supprimé du prompt tout langage lié à la communication avec l’utilisateur en milieu de tour. Nous avons constaté que cela améliorait la qualité de la sortie de code finale du modèle.

#Lecture des lints

Cursor met des outils à la disposition de tous les modèles de notre infrastructure pour lire les erreurs de linter (par exemple ESLint, Biome) et permettre à l’agent de les corriger automatiquement.

Nous avons constaté que fournir à Codex uniquement la définition de l’outil ne suffit pas à l’amener à appeler notre outil read_lints. Au contraire, Codex tire un bénéfice significatif d’instructions claires et littérales indiquant dans quels cas l’appeler :

After substantive edits, use the read_lints tool to check
recently edited files for linter errors. If you've introduced
any, fix them if you can easily figure out how.

#Préserver les traces de raisonnement

Les modèles de raisonnement d’OpenAI produisent des traces de raisonnement internes entre les appels d’outils, qui constituent en pratique une « chaîne de raisonnement » expliquant pourquoi le modèle choisit chaque action. L’API Responses est conçue pour capturer et transmettre ces éléments de raisonnement (ou des éléments de raisonnement chiffrés dans des contextes sensibles) afin que le modèle puisse maintenir la continuité entre les tours de conversation, plutôt que de devoir reconstruire son plan à partir de zéro.

Codex dépend particulièrement de cette continuité. Lorsque les traces de raisonnement sont perdues, le modèle doit déduire son processus de pensée précédent, ce qui conduit souvent à des sous-objectifs perdus, une planification dégradée, des appels d’outils dans le mauvais ordre ou à recalculer à répétition des étapes antérieures. Dans nos expériences Cursor Bench, la suppression des traces de raisonnement de GPT-5-Codex a entraîné une baisse de performances de 30 %. À titre de comparaison, OpenAI a observé une dégradation plus faible de 3 % pour GPT-5 sur SWE-bench lorsque les traces de raisonnement étaient omises.

Compte tenu de l’ampleur de cet impact, nous avons ajouté un système d’alerte pour garantir que les traces de raisonnement sont toujours conservées et relayées correctement. Cela permet de garder intact le plan interne de l’agent et d’éviter les régressions de performance qui surviennent lorsque les modèles sont contraints de « combler les blancs » entre les appels d’outils.

#Influer sur le modèle pour qu’il passe à l’action

Dans le mode agent par défaut de Cursor, vous souhaitez que l’agent lise et modifie de manière autonome les fichiers en fonction de la demande de l’utilisateur. Il peut être frustrant de changer d’onglet pour découvrir que l’agent attendait votre autorisation pour continuer.

Nous avons testé des consignes plus précises pour mieux guider Codex :

Unless the user explicitly asks for a plan or some other intent that
makes it clear that code should not be written, assume the user wants
you to make code changes or run tools to solve the user's problem. In
these cases, it's bad to output your proposed solution in a message, you
should go ahead and actually implement the change. If you encounter
challenges or blockers, you should attempt to resolve them yourself.

Dans Cloud Agents, notre workflow asynchrone à distance, nous durcissons encore cette formulation.

#Ordonnancement des messages

Les modèles d’OpenAI sont entraînés à respecter et à prioriser l’ordonnancement des messages. Par exemple, l’invite système a toujours la priorité sur les messages de l’utilisateur et sur les résultats des outils.

Même si c’est utile, cela signifie que nous devons ajuster nos mécanismes d’orchestration afin de garantir que l’invite fournie par Cursor n’inclut pas d’instructions pouvant, par inadvertance, contredire les messages de l’utilisateur. Sinon, Codex pourrait se retrouver dans un état où il ne souhaite plus se conformer à la demande de l’utilisateur.

Par exemple, à un moment donné, nous avons indiqué à Codex qu’il devait veiller à économiser les tokens et à ne pas les gaspiller. Mais nous avons remarqué que ce message affectait la volonté du modèle d’exécuter des tâches plus ambitieuses ou des explorations à grande échelle. Parfois, il s’arrêtait et affirmait obstinément : Je ne suis pas censé gaspiller des tokens, et je ne pense pas que cela vaille la peine de continuer cette tâche !

#Perspectives d’avenir

Le rythme des lancements de modèles s’accélère. Notre objectif est de tirer le meilleur parti de chaque modèle de pointe au sein de l’environnement d’agent de Cursor. Il reste encore du travail à accomplir, et nous continuerons à partager les améliorations que nous apportons à Cursor.