Composer 2.5 de Cursor : un modèle de code puissant et bien moins cher

Cela reflète une évolution plus large des outils de programmation basés sur l’IA : on passe d’outils de suggestion de code à de véritables agents capables de gérer des workflows complets.

Performances sur les benchmarks face à Opus 4.7 et GPT‑5.5

Cursor publie plusieurs résultats comparatifs pour situer son modèle face aux leaders du marché.

Principaux scores annoncés :

• SWE‑Bench Multilingual : 79,8 % (Composer 2.5), 80,5 % (Claude Opus 4.7), 77,8 % (GPT‑5.5)
• Terminal‑Bench 2.0 : 69,3 % (Composer 2.5), 69,4 % (Claude Opus 4.7), 82,7 % (GPT‑5.5)
• CursorBench v3.1 : 63,2 % (Composer 2.5)

Ces résultats montrent une situation assez nuancée :

• Sur SWE‑Bench Multilingual, qui mesure la capacité d’un modèle à corriger de vrais problèmes GitHub dans plusieurs langages, Composer 2.5 atteint pratiquement le niveau des modèles de pointe et dépasse légèrement GPT‑5.5 dans cette comparaison.

• Sur Terminal‑Bench 2.0, un test axé sur les agents exécutant des commandes dans un terminal, il se situe quasiment au même niveau que Claude Opus 4.7, mais reste nettement derrière GPT‑5.5.

• Par rapport à la génération précédente, les progrès sont importants : le score SWE‑Bench passe par exemple de 73,7 % à 79,8 %.

En résumé, Composer 2.5 est globalement compétitif sur certaines tâches d’ingénierie logicielle, sans pour autant dominer tous les benchmarks.

Une stratégie de prix très agressive

L’autre élément qui frappe est le tarif.

Cursor annonce environ :

• 0,50 $ par million de tokens d’entrée
• 2,50 $ par million de tokens de sortie

Une version plus rapide est proposée à :

• 3,00 $ par million de tokens d’entrée
• 15,00 $ par million de tokens de sortie.

À titre de comparaison, certaines estimations placent les modèles Claude Opus autour de 5 $ / million en entrée et 25 $ / million en sortie.

Pourquoi cela compte‑t‑il ?

Les agents de développement consomment énormément de tokens : exploration du code, planification, génération de correctifs, compilation, exécution de tests… chaque étape implique souvent un nouvel appel au modèle.

Un tarif plus bas permet donc à Cursor d’exécuter davantage d’étapes de raisonnement par tâche sans faire exploser les coûts.

Sur quelle base le modèle est construit

Composer 2.5 s’appuie sur le checkpoint open‑weight Kimi K2.5 développé par Moonshot AI, sur lequel l’équipe Cursor a réalisé un entraînement supplémentaire spécialisé dans le développement logiciel.

Selon les informations disponibles sur l’entraînement :

• le modèle aurait utilisé environ 25 fois plus de tâches de codage synthétiques que la génération précédente ;
• environ 85 % du budget de calcul aurait été consacré à l’entraînement supplémentaire et au reinforcement learning, plutôt qu’à la base initiale.

Ces tâches synthétiques servent à simuler des workflows complets : planifier des changements, modifier du code, exécuter des tests et itérer jusqu’à obtenir une solution correcte.

Une pièce clé dans la stratégie de Cursor

La sortie de Composer 2.5 s’inscrit aussi dans une stratégie plus large.

Historiquement, Cursor dépendait largement de modèles tiers — notamment ceux d’OpenAI, Anthropic ou Google — pour alimenter ses fonctionnalités de code assisté par IA.

Développer des modèles internes apporte plusieurs avantages :

• réduire les coûts d’inférence pour les agents longue durée
• diminuer la dépendance aux fournisseurs externes
• contrôler plus finement le comportement du modèle dans l’IDE

Cet aspect est particulièrement important face à Claude Code, l’outil d’Anthropic qui bénéficie d’une intégration très étroite entre modèle et agent de développement.

Avec la famille Composer, Cursor tente donc de devenir non seulement un IDE intelligent, mais aussi un fournisseur de modèles spécialisés pour le développement.

À retenir

Composer 2.5 ne domine pas systématiquement les modèles de pointe : GPT‑5.5 reste en tête sur certains benchmarks, tandis que Claude Opus 4.7 reste très compétitif.

Mais l’association de performances proches du niveau frontier et d’un coût bien plus faible pourrait changer l’économie des agents de programmation — surtout pour les workflows longs exécutés directement dans l’IDE.