Résultats de l’évaluation des modèles CursorBench 3.1

• Dans le tableau d’évaluation des modèles de codage de Cursor, Fable 5 Max arrive en tête avec 72,9 %, devenant le point de référence de la concurrence en haut du classement
• La famille Fable 5 occupe toutes les places de 1 à 4 avec Max, Extra High, High et Medium, affichant un écart net avec les autres familles de modèles
• Après le top 5, on trouve Opus 4.7 Max à 64,8 %, GPT-5.5 Extra High à 64,3 %, Fable 5 Low à 64,2 %, Opus 4.8 Max à 63,8 %, puis Composer 2.5 à 63,2 %
• CursorBench 3.1 ajoute des tâches centrées sur la compréhension de codebase, la détection de bugs, la planification et la revue de code, et améliore les critères de notation de certaines tâches d’édition
• Le coût moyen par tâche est calculé à partir des prix publics des tokens et des tokens utilisés pour chaque tâche ; de faibles écarts de score peuvent ne pas être statistiquement significatifs

---

Le haut du classement est monopolisé par Fable 5

• Le tableau CursorBench 3.1 compare, pour chaque modèle, le classement, le score, le coût moyen par tâche et des chiffres liés à l’utilisation
• Les quatre premières places sont toutes occupées par la famille Fable 5
  • Fable 5 Max : 72,9 %, $18.02, 63,842, 76
  • Fable 5 Extra High : 72,0 %, $13.74, 48,754, 63
  • Fable 5 High : 70,6 %, $10.81, 37,173, 54
  • Fable 5 Medium : 69,8 %, $8.27, 28,507, 47
• Dans la tranche des places 5 à 10, les modèles Opus, GPT-5.5, Fable et Composer se mêlent
  • Opus 4.7 Max : 64,8 %, $11.02, 62,989, 96
  • GPT-5.5 Extra High : 64,3 %, $4.37, 17,905, 46
  • Fable 5 Low : 64,2 %, $5.70, 18,882, 36
  • Opus 4.8 Max : 63,8 %, $7.59, 77,370, 60
  • Composer 2.5 : 63,2 %, $0.55, 15,152, 37
  • GPT-5.5 High : 62,6 %, $3.59, 13,329, 40

Scores des modèles du milieu et du bas du classement

• Les places 11 à 20 sont principalement occupées par des modèles Opus, Sonnet et GPT-5.5
  • Opus 4.8 Extra High : 62,1 %, $6.14, 55,622, 54
  • Opus 4.7 Extra High : 61,6 %, $7.11, 43,942, 72
  • Sonnet 5 Max : 61,2 %, $6.87, 93,485, 93
  • Opus 4.7 High : 59,4 %, $5.01, 32,227, 59
  • GPT-5.5 Medium : 59,2 %, $2.22, 9,065, 35
  • Opus 4.8 High : 58,4 %, $4.41, 36,788, 45
  • Sonnet 5 Extra High : 58,4 %, $5.23, 58,228, 86
  • Sonnet 5 High : 57,0 %, $3.74, 41,735, 66
  • Opus 4.8 Medium : 56,6 %, $3.83, 31,684, 41
  • Sonnet 5 Medium : 54,9 %, $2.57, 27,469, 53
• Les places 21 à 36 incluent notamment GLM, Kimi, Gemini, Sonnet et Composer
  • GLM 5.2 Max : 54,6 %, $3.11, 51,312, 83
  • Opus 4.8 Low : 54,3 %, $2.93, 22,726, 36
  • Opus 4.7 Medium : 52,7 %, $2.93, 19,193, 41
  • Kimi K2.7 Code : 52,7 %, $1.92, 32,902, 70
  • Composer 2 : 52,2 %, $0.56, 14,163, 40
  • GLM 5.2 High : 50,7 %, $2.46, 30,621, 76
  • Gemini 3.5 Flash : 49,8 %, $1.94, 35,105, 79
  • Sonnet 4.6 Max : 49,0 %, $3.09, 40,280, 55
  • GPT-5.5 Low : 48,8 %, $1.19, 4,923, 24
  • Sonnet 4.6 High : 48,8 %, $3.06, 37,352, 57
  • Opus 4.7 Low : 48,3 %, $1.87, 13,164, 29
  • Sonnet 5 Low : 47,7 %, $1.46, 17,028, 37
  • Kimi 2.6 : 47,6 %, $1.27, 24,783, 56
  • Sonnet 4.6 Medium : 46,0 %, $2.64, 31,360, 50
  • Sonnet 4.6 Low : 41,5 %, $1.89, 21,211, 50
  • Kimi 2.5 : 31,9 %, $0.87, 9,446, 30

Périmètre d’évaluation de CursorBench 3.1

• CursorBench 3.1 introduit des problèmes axés sur la compréhension de codebase, la détection de bugs, la planification et la revue de code
• Les critères de notation de certaines tâches d’édition ont également été améliorés
• CursorBench 3.0 était un premier ensemble de tâches centré sur l’édition, le refactoring et la correction de bugs

Calcul des coûts et limites d’interprétation

• Le coût moyen par tâche est calculé à partir du tarif public par million de tokens de chaque modèle
• Il inclut les prix de l’entrée, de la lecture du cache, de l’écriture du cache et de la sortie
• Les prix sont appliqués aux tokens utilisés par chaque modèle sur les tâches CursorBench 3.1, puis la moyenne est calculée sur l’ensemble des tâches
• Les résultats conservent une part de variabilité, et de faibles écarts de score peuvent ne pas être statistiquement significatifs

[GN⁺]

Avis de Hacker News

• Je suis un peu sceptique
  Dans le benchmark de Cursor, le modèle de Cursor, Composer 2.5, est présenté comme aussi bon qu’Opus 4.8 max et GPT-5.5 xhigh, tout en coûtant beaucoup moins cher
  Mais dans les tests d’Artificial Analysis, Composer 2.5 est assez loin derrière : https://artificialanalysis.ai/agents/coding-agents
  Sur le benchmark DeepSWE, GPT-5.5 xhigh est à 64, Opus 4.8 max à 56, et Cursor 2.5 à 16
  Je ne doute pas que Cursor puisse très bien convenir à certaines personnes, mais l’affirmation selon laquelle il rivalise avec Opus 4.8 ou GPT-5.5 me paraît suspecte. C’est un peu trop pratique qu’il soit bon sur son propre benchmark et très en retrait sur les benchmarks tiers

  • Je travaille chez Cursor. Au moment du lancement de Composer 2.5, il était assez compétitif dans le benchmark global d’AA et, si je me souviens bien, il était 3e au classement général
    Récemment, AA est passé à DeepSWE, un benchmark beaucoup plus axé sur des tâches à très longue portée. Composer n’est pas encore très fort sur ce type de tâches, et nous travaillons à l’améliorer dans le prochain modèle
    Globalement, Composer obtient de bons résultats sur certains benchmarks, et moins bons sur d’autres. Cela dit, je pense que c’est un modèle très capable dans sa tranche de prix actuelle. Si vous observez des comportements précis ou des points faibles, vous pouvez les signaler ici ou m’écrire à lrobinson at cursor.com
  • Il n’est pas difficile de comprendre ce qui se passe. Comme ils ont fait de l’apprentissage par renforcement sur les motifs et capacités spécifiques de leurs propres données, il est naturel qu’ils finissent par créer un benchmark qui correspond à leur jeu d’entraînement
    Ironiquement, dans le périmètre étroit qui intéresse vraiment les « clients propres » de Cursor, ce benchmark pourrait être plus précis qu’Artificial Analysis. Pour le reste, il faut juste le voir comme un point de données de plus
  • DeepSWE est un peu défectueux dans la mesure où il n’utilise que son propre harnais d’exécution, ce qui pose problème avec les modèles que ce harnais ne prend pas correctement en charge
    Il existe de nombreux éléments montrant que le harnais a une forte influence sur le comportement de ces modèles, et DeepSWE élimine complètement ce facteur. Il est probable qu’ils aient seulement vérifié qu’il fonctionnait bien avec quelques modèles qu’ils privilégient
    Comme cela a aussi été signalé dans les issues GitHub, le harnais n’utilise pas de cache, ce qui pose également problème pour le calcul des coûts. Aucun benchmark n’est parfait, mais cela explique assez bien les écarts entre benchmarks
  • Les sessions Cursor sont presque exactement ce sur quoi le modèle Composer est entraîné par renforcement. Ce bench et les données d’entraînement devraient en pratique provenir de la même distribution
  • Je ne sais pas trop pour les benchmarks, mais j’ai beaucoup utilisé Composer 2.5 et il a plutôt bien fonctionné dans du travail réel

• Le choix des axes est assez déroutant. Je pensais que la gauche correspondait au moins cher, alors que c’est en fait le plus cher
  Je comprends la disposition qui vise à faire du coin supérieur droit la meilleure position, mais inverser l’axe des coûts reste peu intuitif
  Cela mis à part, je fais tous les jours, toute la journée, des implémentations très difficiles que les agents arrivent à peine à réaliser, et pour les tâches qui nécessitent une « vraie validation », j’ai dû garder Opus en max pendant un bon moment. C’était en pratique la seule manière, à mes yeux, de faire en sorte qu’Opus se comporte même à peu près comme GPT-5.5 xhigh
  Avec GPT-5.5 en abonnement, la fenêtre de contexte est petite : elle est de 400k, mais l’effectif est plutôt autour de 258k, donc j’utilise Opus
  La différence, c’est que GPT-5.5 xhigh est très rapide dans la plupart des cas réels. L’implémentation globale est aussi efficace, et il répond de façon adaptative et rapide aux questions qui ne nécessitent pas de réflexion approfondie
  À l’inverse, Opus 4.8 Max rumine inutilement tout pendant longtemps, et même une implémentation simple peut prendre des heures, si bien que je l’utilise surtout pour la planification et les revues
  Fable est nettement meilleur pour la réflexion adaptative et les réponses rapides, mais il reste probablement inférieur à GPT-5.5 xhigh. Je pense que tout le monde a suffisamment parlé des avantages et inconvénients, et malheureusement, pour mes tâches difficiles, ce n’est pas encore un implémenteur fiable. Cela reste le domaine de GPT, tandis que Fable a tendance, si on ne le surveille pas de près, à laisser de gros trous dangereux dans l’implémentation

  • Est-ce qu’il y a quoi que ce soit de vérifiable dans « je fais tous les jours, toute la journée, des implémentations très difficiles que les agents arrivent à peine à réaliser » ? Ou est-ce qu’on est juste censés te croire ? Tout cela sonne ridiculement subjectif
  • Si Fable laisse des trous dangereux dans l’implémentation, on pourrait envisager d’y intégrer GLM ou DeepSeek comme outil de red team du code
    Fable est, par conception, aveugle à la sécurité[0], tandis que les modèles ouverts sont plutôt bons sur ce terrain
    [0] On ne sait pas bien ce que donnera GPT-5.6, mais à en juger par le blog, il aura probablement des filtres de sécurité tout aussi excessivement prudents
    Ce qui est amusant, c’est que les billets de sortie récents d’Opus se vantent d’avoir volontairement réduit certaines capacités de sécurité. « during its [Opus 4.7] training we experimented with efforts to differentially reduce these ["cyber"] capabilities »
  • C’est du Gartner. Le coin supérieur droit est l’endroit où l’on veut être
  • Je suis d’accord sur le fait qu’on se demande pourquoi l’axe x a été inversé. Ce graphique devient très difficile à comprendre pour un observateur ordinaire
  • Je me demande si tu as vraiment l’impression que « la fenêtre de contexte est petite avec GPT-5.5 en abonnement » fait une différence dans le travail réel
    Je l’utilise en 5.5 high/xhigh pour optimiser et benchmarker une base de code en C, et la simple lecture du code initial remplit presque toute la première fenêtre de contexte
    La session effectue automatiquement la compression environ 5 à 15 fois, mais comme le travail se concentre surtout sur la fenêtre la plus récente à chaque fois, il s’en sort plutôt correctement
    En programmation, les points forts de GPT par rapport à Opus sont tels qu’ils semblent compenser la différence de fenêtre de contexte

• Difficile de croire que Composer 2.5 soit si bon. Je l’ai comparé à GLM 5.2 et Opus 4.6, et il manquait de profondeur dans la réflexion sur les problèmes et de raisonnement critique
  Il est bon pour exécuter un plan créé par un autre modèle, mais même dans ce cas, il lui arrive de manipuler le code de façon étrange, très éloignée de la manière dont les fichiers alentour fonctionnent réellement

  • Je n’utilise plus Cursor aujourd’hui, mais mon expérience, quand je l’ai utilisé il y a quelque temps, était similaire. Je planifiais avec Opus, j’implémentais avec Composer, puis je nettoyais avec Opus
    Composer est compétent quand il dispose d’un bon plan, mais pas au point d’être bluffant. Ce que j’ai vraiment apprécié, en revanche, c’est sa vitesse
    Ce qui prenait 30 minutes à Opus, Composer le terminait en 5 à 10 minutes. Bien sûr, le résultat n’était pas parfait, donc je passais par une étape de nettoyage avec Opus ou Codex
    Au final, c’est une question d’équilibre, cela change en permanence et dépend entièrement du problème à résoudre. Je reste flexible et j’adapte mon processus à ce qui fonctionne le mieux sur le moment
  • En voyant ce genre de choses, j’ai simplement l’impression qu’il s’agit d’une frontière irrégulière. Je ne remets pas en cause les expériences personnelles. Le mois dernier, j’ai essayé Composer 2.5 avec Grok et les crédits d’un compte X Premium
    Je ne construis pas des fusées, mais c’était assez impressionnant. Tous les modèles font parfois des bêtises, mais il a plutôt bien réalisé les tâches que je lui ai demandées et a produit des résultats impressionnants
    Dans Grok, il est rapide, et par rapport aux autres modèles que j’ai beaucoup utilisés, je le trouve meilleur que gemini 3.1. À mes yeux, 3.5 et antigravity étaient moins bons que l’ancien gemini cli. Il est comparable à Opus 4.6. Je n’ai pas encore essayé les modèles plus récents de Claude Code

• Si j’ai bien compris le graphique, Fable utilise moins de tokens que sonet et opus pour accomplir la même tâche. Si c’est le cas, c’est une bonne chose
  Pendant un moment, on avait l’impression que les modèles crachaient des tokens à tout-va pour obtenir de meilleurs résultats ; si le modèle lui-même s’améliore sans générer davantage de tokens, cela ressemble à un vrai progrès
  Question 1 : pourquoi le nombre d’étapes est-il important dans ce graphique ? Qu’est-ce que cela nous apprend ?
  Question 2 : pourquoi avoir inversé l’axe horizontal pour que 0 soit à droite plutôt qu’à l’origine ? Est-ce une nouvelle façon intelligente de faire ? Je ne crois pas avoir déjà vu ça auparavant

• Il est intéressant qu’Opus 4.7 fasse mieux que 4.8. J’aurais aimé qu’ils testent aussi 4.6. Hier, j’ai vu ici quelqu’un se faire moquer parce qu’il insistait sur le fait que 4.6 était meilleur que ses successeurs
  Cela dit, les benchmarks sont toujours subtils. Sur DeepSWE, GPT-5.5 bat Opus-4.8 avec une marge assez nette, mais sur FrontierCode c’est l’inverse
  Le seul benchmark fiable, c’est sa propre charge de travail réelle

• À chaque nouveau benchmark, les modèles chinois obtiennent des résultats bien inférieurs à ce qu’on attendrait d’eux d’après les benchmarks existants, puis ils remontent avec le temps

  • La magie de la distillation

• J’aimerais que tous ces sites affichent un graphique de frontière de Pareto coût/performance. Ce sont surtout ces deux critères qui comptent. On pourrait aussi ajouter un paramètre de vitesse pour en faire un graphe en 3D
  https://paraplouis.github.io/llm-pareto-frontier/ est le meilleur graphique que j’aie vu, mais il n’est pas mis à jour aussi souvent que je le voudrais

  • Ce site n’est pas très utile. Il ne prend pas en compte les tokens de raisonnement, le caching, ni leur efficacité
    GLM5.2 est promu sur Internet par tous les wumao que l’APL peut mobiliser, mais son processus de raisonnement est trop verbeux, ce qui révèle ses limites
    Les modèles d’Anthropic ont le même problème, mais ils partent d’un niveau d’intelligence réel bien plus élevé
    C’est précisément pour cette raison que les comparaisons fiables se fondent désormais non pas sur un coût arbitraire des tokens d’entrée/sortie, mais sur le coût total nécessaire pour terminer une tâche

• J’ai beaucoup utilisé Composer 2.5 et GPT 5.5 à la fois dans Cursor et dans Codex, et l’idée que les performances de Composer 2.5 soient proches de celles de GPT 5.5 est totalement absurde
  Il est plus rapide, mais sa qualité n’est absolument pas à ce niveau
  De plus, Composer n’est utilisable qu’avec un abonnement mensuel à Cursor, donc la comparaison des coûts n’a pas vraiment de sens. Avec un abonnement OpenAI à prix similaire, on peut utiliser de meilleurs modèles dans les mêmes proportions

• La partie la plus intéressante, c’est le coût. GPT 5.5 et sonnet 5 coûtent autant que GLM 5.2, mais ce sont des modèles plus capables

• Un modèle Cursor excellent sur un benchmark Cursor, voilà qui mérite le journal de 23 h
  Cela dit, tous les autres modèles sont placés de manière assez raisonnable, d’après mon expérience directe avec eux
  Fable coûte 10 fois plus cher, mais il surpasse la plupart des autres modèles sur presque tout. Parfois, toutefois, le choix ne se fait pas entre une option chère et une option bon marché, mais entre une option chère qui rend la tâche possible et une option où elle est tout simplement impossible. Comme avec les autres modèles, il faut apprendre où se situe cette frontière