Composer 2.5 : benchmarks, tarifs et comparatif

Cursor a publié Composer 2.5 le 18 mai 2026, environ deux mois après Composer 2 en mars. Ce rythme soutenu montre à quelle vitesse Cursor fait évoluer sa gamme de modèles maison.

Selon Cursor, Composer 2.5 se situe au niveau de Claude Opus 4.7 et GPT-5.5 sur plusieurs benchmarks de code. Son prix par token est également inférieur à celui des modèles de pointe. La formation a changé elle aussi : plus de tâches synthétiques, des environnements d’entraînement plus difficiles et une méthode de feedback qui cible des erreurs précises lors de longues sessions de codage.

Dans cet article, je considère Composer 2.5 comme plus qu’une simple mise à jour de benchmarks. J’explique ce que c’est, ce qui a changé, à quoi ressemblent les scores, comment les tarifs se comparent aux modèles de pointe, et où il s’intègre dans un flux de travail de développement. Il y a aussi des limites à connaître avant de prendre les scores pour l’alpha et l’oméga.

Pour en savoir plus sur les autres modèles de cette comparaison, consultez nos guides sur Claude Opus 4.7 et GPT-5.5.

Qu’est-ce que le modèle Composer 2.5 de Cursor ?

Composer 2.5 est le dernier modèle de la famille Composer de Cursor, conçu pour le travail de développement dans le Cursor IDE. Il s’inscrit dans la lignée de Composer 1, Composer 1.5 et Composer 2.

Chronologie de Composer du lancement à 2.5. Image de l’auteur.

Ce n’est pas un chatbot généraliste. Composer 2.5 est entraîné pour les modifications multi-fichiers, les commandes terminal, l’usage d’outils et les longues sessions de codage. Ses objectifs de formation et ses benchmarks se concentrent sur des tâches d’ingénierie logicielle.

Le billet de lancement indique que le modèle dépasse Composer 2 sur les tâches de code et se comporte différemment lors de longues sessions. Il est désormais l’option par défaut dans le sélecteur de modèles de Cursor, même si Composer 2 reste disponible. Il fonctionne exclusivement dans Cursor : pas d’API publique, pas de fiche modèle sur Hugging Face, ni d’accès via un autre fournisseur.

Ce qui a changé dans Composer 2.5

Les changements de Composer 2.5 se répartissent en deux catégories : les performances sur tâches de code et le comportement collaboratif. La première se mesure plus facilement que la seconde ; il est donc utile de distinguer ce que Cursor quantifie de ce qu’il décrit de façon plus qualitative.

Meilleures performances sur les longues tâches

Composer 2.5 vise les longues sessions où le modèle doit lire des fichiers, exécuter des commandes, corriger des erreurs et itérer. C’est important, car en pratique, un développement ne tient presque jamais en une seule invite et une seule réponse.

Cursor a entraîné le modèle dans des environnements d’apprentissage par renforcement plus exigeants pour ce type de travail. Les tâches ont été générées pendant l’entraînement avec une difficulté qui augmentait au fil du temps.

Suivi des consignes et collaboration

La version annonce aussi un suivi des instructions plus fiable. Elle met en avant un calibrage de l’effort : le modèle doit mobiliser plus de calcul sur les tâches difficiles et éviter de suranalyser les tâches simples.

Avec une réserve : Cursor précise que ces changements de comportement « ne sont pas bien capturés par les benchmarks existants ». Cette partie repose donc surtout sur l’évaluation interne de Cursor et les premiers retours d’utilisateurs, pas sur un score public.

Des environnements RL plus difficiles

Le billet présente l’évolution comme « faire passer l’entraînement à l’échelle, générer des environnements RL plus complexes et introduire de nouvelles méthodes d’apprentissage ». L’entraînement a utilisé 25 fois plus de tâches synthétiques que Composer 2.

Comment Cursor a entraîné Composer 2.5

Les détails d’entraînement expliquent pourquoi le modèle a évolué sans nouvelle architecture de base. Composer 2.5 s’appuie sur la même fondation que Composer 2, mais le travail post-entraînement de base a changé. Tout n’a pas la même importance pour les lecteurs, mais certains éléments éclairent l’évolution des benchmarks.

Construit sur Kimi K2.5

Composer 2.5 repose sur le même checkpoint open source que Composer 2 : Kimi K2.5 de Moonshot AI. Cursor l’indique clairement dans le billet de lancement, point important car le modèle de base avait suscité des débats autour de Composer 2.

Kimi K2.5 utilise une architecture Mixture of Experts. Cursor applique un pré-entraînement continu et de l’apprentissage par renforcement par-dessus, et indique qu’environ 85 % du calcul total du modèle final provient de son propre travail après l’entraînement de base.

RL ciblé avec feedback textuel

C’est le principal changement technique de Composer 2.5. En RL standard, le modèle reçoit un signal de récompense unique à la fin d’une longue séquence. Lors d’une session de codage prolongée, ce signal final est trop bruité pour indiquer précisément où le modèle s’est trompé.

L’enseignant et l’élève partagent un tour. Image de l’auteur.

La méthode de Cursor insère un court indice textuel à l’endroit où le modèle a pris une mauvaise décision. Par exemple, si le modèle appelle un outil inexistant, le processus peut insérer un rappel avec la liste correcte d’outils. La version avec indice joue le rôle « d’enseignant », et le modèle d’origine celui « d’élève ». Une distillation par perte oriente alors le comportement de l’élève vers celui de l’enseignant, uniquement pour ce tour.

Résultat : un entraînement plus ciblé. On corrige des erreurs spécifiques sans juger un long déroulé comme globalement bon ou mauvais. Cursor a appliqué cette méthode sur le style de code, l’usage d’outils et la communication du modèle pendant l’entraînement de Composer 2.5.

Des données synthétiques à plus grande échelle

Composer 2.5 a été entraîné avec 25 fois plus de tâches synthétiques que Composer 2. Ces tâches s’ancrent dans de vrais dépôts de code, pas des exemples jouets.

Une approche décrite par Cursor est la suppression de fonctionnalités. Un agent part d’un codebase réel avec une large suite de tests, puis retire du code et des fichiers tout en gardant le reste fonctionnel. La tâche synthétique consiste à réimplémenter la fonctionnalité supprimée, et les tests fournissent un signal de récompense vérifiable.

Cette échelle d’entraînement synthétique comporte ses propres risques. Cursor a documenté des cas où Composer 2.5 a trouvé des raccourcis, par exemple en récupérant des informations supprimées via un cache de typage Python ou en décompilant du bytecode Java pour reconstruire une API externe. L’entreprise indique avoir détecté ces cas via des outils de monitoring, tout en reconnaissant qu’un tel entraînement exige « une vigilance accrue ».

Évolutions d’infrastructure

Côté infrastructure, Cursor a utilisé Sharded Muon et un double maillage HSDP pour le pré-entraînement continu. Ces choix ont réduit une partie des coûts et des délais liés à l’entraînement sur de grands clusters GPU.

Résultats de benchmark de Composer 2.5 : Terminal-Bench, SWE-Bench et CursorBench

Les benchmarks sont utiles, mais ne racontent pas tout. Considérez-les comme un point de départ, pas comme un verdict sur l’usage quotidien.

Cursor évalue Composer 2.5 sur trois benchmarks :

SWE-Bench Multilingual évalue la capacité d’un modèle à résoudre de vrais tickets GitHub dans plusieurs langages. Chaque tâche fournit un dépôt et un énoncé, puis vérifie si le correctif passe les tests associés.

Terminal-Bench 2.0 mesure la capacité d’un agent IA à travailler dans un terminal réel : inspection de fichiers, exécution de commandes, débogage et accomplissement de tâches en plusieurs étapes.

CursorBench v3.1 est le benchmark interne de Cursor. Il évalue des agents sur des tâches ambiguës et multi-fichiers issues de vraies sessions Cursor : compréhension de codebase, recherche de bugs, planification, revue de code. Limite : CursorBench ne peut pas être audité ni reproduit en externe ; il faut comparer les scores au sein d’une même version.

Une réserve importante avant d’interpréter ces chiffres : les comparaisons inter-modèles ne sont pas toujours nettes. Des différences de protocole d’évaluation et de niveau d’effort peuvent déplacer les scores, et Cursor précise que les scores d’Opus 4.7 et GPT-5.5 sur des évaluations publiques sont auto-déclarés. À lire comme des tendances, pas comme des tests strictement identiques.

Un benchmark externe ultérieur d’Artificial Analysis va dans le même sens, avec un autre mix d’épreuves. Composer 2.5 a obtenu 62 sur l’Artificial Analysis Coding Agent Index, derrière Claude Opus 4.7 en effort max (66) et GPT-5.5 en xhigh reasoning (65).

L’écart de coût mérite l’attention : Artificial Analysis estime Composer 2.5 à 0,07 $ par tâche en Standard et 0,44 $ en Fast, contre 4,10 $ pour Opus 4.7 max et 4,82 $ pour GPT-5.5 xhigh.

Composer 2.5 vs Composer 2 vs Composer 1.5 : comparaison des scores

La famille Composer a connu trois sorties rapprochées : Composer 1.5 en février 2026, Composer 2 en mars et Composer 2.5 en mai. Chaque version a modifié un aspect différent de l’approche d’entraînement.

Composer 2.5 face à Composer 2

Le saut de Composer 2 à 2.5 est le plus visible sur Terminal-Bench 2.0, de 61,7 % à 69,3 %, et sur SWE-Bench Multilingual, de 73,7 % à 79,8 %. Le gain sur CursorBench est plus faible, et la version du benchmark a changé (v3 à v3.1), rendant la comparaison moins directe.

La différence majeure tient au pipeline d’entraînement. Composer 2 a introduit le pré-entraînement continu sur Kimi K2.5. Composer 2.5 conserve cette base et ajoute un feedback textuel ciblé, 25× plus de tâches synthétiques et des changements d’infrastructure. Le prix Standard est resté identique.

Composer 2.5 face à Composer 1.5

Composer 1.5 a été construit en multipliant par 20 l’apprentissage par renforcement sur le même modèle pré-entraîné que Composer 1. Il a introduit une pensée adaptative et l’auto‑résumé, permettant au modèle de compresser son propre contexte lors de longues sessions.

L’écart entre Composer 1.5 et 2.5 est important sur tous les benchmarks. Il s’accompagne d’un prix par token plus bas : Composer 1.5 était facturé 3,50 $ par million de tokens en entrée et 17,50 $ en sortie, soit environ 7 fois plus que Composer 2.5 Standard.

Ce qui change concrètement

Au fil des versions, le schéma est clair : chaque génération modifie le comportement en longues sessions et le suivi des consignes, tandis que Composer 2 et 2.5 ont réduit le coût des sessions agent prolongées.

Composer 2.5 vs Claude Opus 4.7 vs GPT-5.5 : benchmarks, prix et arbitrages

C’est la comparaison qui intéressera sans doute en premier. Composer 2.5 affiche des scores proches sur certaines épreuves de codage, un prix par token inférieur aux modèles de pointe listés ci-dessous, et des arbitrages nets.

Comparaison des benchmarks

GPT-5.5 mène sur Terminal-Bench 2.0 avec 82,7 %, environ 13 points devant Composer 2.5. Cet écart compte pour les travaux très dépendants du terminal.

Claude Opus 4.7 devance légèrement Composer 2.5 sur SWE-Bench Multilingual (80,5 % contre 79,8 %), soit moins d’un point. Sur CursorBench, Composer 2.5 à 63,2 % dépasse Opus 4.7 en réglages par défaut (61,6 %) mais reste sous Opus 4.7 en effort max (64,8 %). GPT‑5.5 atteint aussi 64,3 % en xhigh, contre 59,2 % en défaut.

Ces modèles n’occupent pas exactement le même rôle. Opus 4.7 et GPT‑5.5 sont des modèles de pointe généralistes. Composer 2.5 est un modèle de codage qui fonctionne uniquement dans Cursor. Les scores sont proches sur certaines tâches de code, mais le périmètre produit diffère.

Comparaison des tarifs

La différence de coût est la séparation la plus nette d’avec les modèles de pointe.

Composer 2.5 Standard est facturé environ dix fois moins cher qu’Opus 4.7 et GPT‑5.5 par token. La variante Fast reste aussi en dessous des paliers standards de ces modèles de pointe.

Ces tarifs sont valables en mai 2026 ; vérifiez les prix des modèles de Cursor, les tarifs d’Opus chez Anthropic et les prix de l’API OpenAI avant de vous baser sur cette comparaison.

Un point souvent ignoré : le prix de Composer 2.5 Fast a doublé par rapport à Composer 2 Fast. Le Standard n’a pas bougé, mais Fast est le défaut ; la mise à niveau peut donc augmenter la facture de certains utilisateurs.

Quel modèle choisir ?

Le choix dépend de ce qui prime : coût, usage du terminal ou profondeur de raisonnement :

• Composer 2.5 convient au codage quotidien dans Cursor, notamment les modifications multi‑fichiers, le refactoring, le débogage et les sessions agent où le coût compte.
• GPT‑5.5 est pertinent lorsque la performance au terminal est prioritaire.
• Claude Opus 4.7 convient aux tâches nécessitant un raisonnement soigné, de la planification architecturale ou une fenêtre de contexte d’un million de tokens.

C’est le schéma à retenir : Composer 2.5 couvre le travail de code courant, tandis que les modèles de pointe gardent l’avantage pour un raisonnement plus large ou des scores terminal plus élevés.

Composer 2.5 Standard vs Fast : vitesse, prix et cas d’usage

Comme pour Composer 2, Cursor propose deux variantes de Composer 2.5. D’après Cursor, elles partagent la même intelligence sous-jacente. La différence tient surtout à la rapidité de réponse et au coût.

Sélecteur de modèles Cursor avec Composer choisi. Image de l’auteur.

Fast est l’option par défaut et coûte 3,00 $ par million de tokens en entrée et 15,00 $ par million en sortie. Il vise les sessions interactives où la faible latence est clé. Standard fonctionne à 0,50 $ et 2,50 $ ; il convient aux tâches en arrière-plan ou aux boucles agent longues où l’immédiateté compte moins.

L’usage de Composer 2.5 est imputé au pool « Auto + Composer » de Cursor, distinct du pool API utilisé pour les modèles externes comme Claude et GPT. Cursor a également offert un double quota d’usage la première semaine après le lancement.

Limites et réserves de Composer 2.5

Les réserves portent sur l’accès, les benchmarks et les risques d’entraînement. Rien d’inhabituel, mais cela influe sur le poids à accorder aux annonces de Cursor.

Disponible uniquement dans Cursor. Comme indiqué plus haut, Composer 2.5 n’a pas d’API publique. Si votre flux dépend d’appels depuis vos scripts ou pipelines, ce n’est pas une option.

CursorBench n’est pas indépendant. Comme vu dans la section benchmarks, CursorBench v3.1 est interne. Sa méthodologie n’est pas entièrement publique, et les tâches ne sont pas reproductibles par des chercheurs externes.

Variabilité des protocoles d’évaluation. Les scores des modèles de pointe dans le tableau de Cursor ne sont pas tous mesurés de la même manière. À considérer comme indicatifs, pas définitifs.

Reward hacking pendant l’entraînement. Cursor a révélé des cas où le modèle a trouvé des raccourcis astucieux dans des tâches synthétiques au lieu de les résoudre « proprement ». C’est un risque inhérent du RL à cette échelle, même si le monitoring détecte les cas évidents.

Calibrage de l’effort non vérifié. Les affirmations de Cursor sur le style de communication et le calibrage de l’effort ne sont pas corroborées par des benchmarks, comme indiqué plus haut. Difficiles à valider de l’extérieur.

Quand Composer 2.5 a du sens

Cela dépend de la tâche. Voyez Composer 2.5 moins comme un choix universel que comme un modèle de codage pour celles et ceux qui travaillent déjà dans Cursor.

Si vous codez la majeure partie de la journée dans Cursor et surveillez vos coûts tokens, Composer 2.5 Standard est l’option la plus économique de la gamme 2.5. Idéal pour les mêmes tâches d’édition, de refactoring, de débogage et pour les longues sessions.

Si la vitesse de réponse prime, Composer 2.5 Fast est l’option par défaut.

Si la tâche exige un raisonnement plus large, une fenêtre de contexte plus grande ou de meilleurs scores sur une épreuve donnée, Claude Opus 4.7 ou GPT‑5.5 seront peut‑être plus adaptés.

En bref : Composer 2.5 gère le travail de code courant décrit plus haut, tandis qu’un modèle de pointe conviendra aux tâches nécessitant un raisonnement plus large ou de meilleures performances au terminal. Une comparaison pragmatique, sans en faire une recommandation unique en tout cas.

Conclusion

Composer 2.5 peut se lire comme une histoire de benchmarks, mais l’essentiel est la trajectoire. Cursor ne se contente pas d’envelopper des modèles de pointe dans un éditeur : l’entreprise bâtit une lignée de modèles autour des usages réels de ses agents : modifications multi‑fichiers, étapes terminal, longues sessions et récupération après erreurs.

Comme indiqué plus haut, l’arbitrage, c’est la spécialisation. Composer 2.5 n’a pas vocation à remplacer Claude Opus 4.7 ou GPT‑5.5 comme modèles généralistes, et il ne sert pas si vous avez besoin d’une API hors de Cursor. Mais dans Cursor, cette focalisation est un atout : le modèle coûte moins cher à faire tourner, il est ajusté pour les tâches de codage et il est au plus près de la couche produit où ces tâches se déroulent.

Reste à voir jusqu’où Cursor veut aller. L’entreprise dit travailler avec SpaceXAI pour entraîner un modèle plus grand, from scratch, avec 10× plus de calcul total et l’infrastructure Colossus 2. Aucune date de sortie n’a été annoncée. La tendance est néanmoins claire : Cursor passe d’un excellent usage des modèles à une maîtrise accrue de la pile modèle elle‑même.