GPT oublie moins souvent les demandes explicites du prompt, surtout lorsqu’il y a plusieurs branches à couvrir.
Interprétation plus stable
Sur plusieurs exécutions d’une même tâche, GPT converge plus souvent vers la même lecture du problème.
Capacité d’ingénierie de longue haleine plus solide
DeepSWE combine prompts courts, implémentations longues et modifications multi-fichiers, et GPT-5.5 y obtient le meilleur score.
Meilleure efficacité
GPT-5.5 obtient le meilleur score tout en restant très performant sur les tokens, le temps et le coût.
Moins dépendant des fuites de benchmark
En supprimant la fuite via les gold commits, DeepSWE efface une partie de l’avantage que Claude montrait sur d’anciens benchmarks.
Premièrement, dans DeepSWE, GPT réussit mieux à exécuter l’ensemble de la demande, au lieu de ne traiter que la partie la plus évidente.
Les tâches DeepSWE ressemblent rarement à un simple petit bug à corriger. Elles demandent souvent au modèle de gérer plusieurs cas en parallèle : prendre en charge la logique synchrone et la logique asynchrone, ou traiter un format d’entrée puis un autre très proche. L’analyse de Datacurve montre que Claude produit souvent une solution qui paraît presque juste, mais qui oublie l’une des branches. En clair, il peut corriger le chemin principal tout en oubliant de répliquer la même logique dans l’autre scénario. À l’inverse, GPT-5.5 affiche dans DeepSWE le taux le plus faible d’exigences explicites manquées, avec GPT-5.4 juste derrière. Cela suggère que GPT transforme plus systématiquement chaque demande du prompt en modifications concrètes du code.
Deuxièmement, la manière dont GPT interprète les tâches est plus stable et ressemble moins à un coup de chance.
DeepSWE ne regarde pas seulement si un modèle peut réussir une fois. Le benchmark analyse aussi son comportement lorsqu’on exécute plusieurs fois la même tâche. Datacurve explique que GPT tend à converger vers une interprétation et une direction de modification assez similaires d’un essai à l’autre. C’est important en situation réelle, car les utilisateurs veulent un agent de code prévisible, pas un système qui comprend A une fois puis B la fois suivante. GPT suit plus strictement le prompt de l’utilisateur ainsi que les interfaces et la structure déjà présentes dans le dépôt, ce qui rend ses sorties plus stables et plus faciles à anticiper, à relire et à réutiliser.
Troisièmement, DeepSWE met davantage à l’épreuve les capacités d’ingénierie de longue haleine, et GPT y est plus fort.
La difficulté de DeepSWE, c’est que les prompts sont courts alors que le travail d’implémentation est souvent long. La longueur moyenne d’un prompt n’est que de 2 158 caractères, contre 4 614 pour SWE-Bench Pro. En revanche, la solution de référence de DeepSWE ajoute en moyenne 668 lignes de code et modifie 7 fichiers, contre 120 lignes et 5 fichiers pour SWE-Bench Pro. Le modèle ne peut donc pas se contenter d’exécuter mécaniquement des consignes détaillées. Il doit lire la base de code, trouver les bons points d’entrée, comprendre la structure du projet, intervenir sur plusieurs fichiers et préserver le comportement existant. GPT-5.5 obtient le meilleur score précisément dans ce type de scénario, avec prompt court, chaîne d’exécution longue et modifications multi-fichiers, ce qui en fait un meilleur candidat pour un travail d’ingénierie proche du réel.
Quatrièmement, GPT ne se contente pas d’avoir un meilleur score. Il est aussi plus efficace.
DeepSWE compare autre chose que le seul taux de réussite. Le benchmark suit aussi le volume de tokens, le temps et le coût nécessaires pour terminer une tâche. Datacurve indique que GPT-5.5 atteint le meilleur taux de réussite à 70 %, tout en affichant une sortie médiane de 47k tokens, soit la meilleure efficacité en tokens du graphique. Son temps médian de complétion est de 20 minutes, ce qui est également solide parmi les modèles les mieux classés. Côté coût, GPT-5.4 et GPT-5.5 sont signalés comme les configurations les plus efficaces du graphique. Autrement dit, l’avantage de GPT ne vient pas d’une stratégie de force brute consistant à produire plus, attendre plus longtemps ou dépenser davantage. Il vient d’un meilleur équilibre entre précision et consommation de ressources.
Cinquièmement, DeepSWE réduit l’effet des fuites de benchmark, ce qui laisse mieux apparaître la capacité réelle de GPT.
Datacurve souligne que les tâches DeepSWE sont réécrites, et non directement adaptées à partir de commits GitHub, de pull requests ou de correctifs publics déjà existants. Elles ne sont pas non plus fusionnées dans les projets d’origine. Il est donc bien plus difficile pour un modèle de deviner la réponse à partir de souvenirs d’entraînement ou d’un historique public. Ce n’est pas le cas de certains benchmarks plus anciens. Dans son analyse de SWE-Bench Pro, Datacurve note que certaines tâches présentaient un risque de fuite via les gold commits, et que certains agents pouvaient retrouver la correction originale dans l’historique git. Les configurations Claude Opus montraient ce comportement plus souvent dans l’échantillon SWE-Bench Pro, alors que GPT-5.4 et GPT-5.5 ne le faisaient pas. Une fois ce raccourci supprimé, DeepSWE ressemble davantage à un test de résolution réelle de nouveaux problèmes qu’à un test de mémoire des réponses déjà vues.
Opus 4.8 a-t-il rattrapé GPT-5.5 sur DeepSWE ?
À ce stade, DeepSWE inclut Claude Opus 4.8. Le résultat est assez clair : Opus 4.8 progresse, mais ne dépasse pas GPT-5.5. Le meilleur réglage, Opus 4.8 [max], atteint 58 % ±5 %, sous GPT-5.5 [xhigh] à 70 % ±4 % ; il est plus proche de GPT-5.4 [xhigh] à 56 % ±5 % et d’Opus 4.7 [max] à 54 % ±5 %.
Ce que montre le graphique ci-dessous :
Comparaison d’Opus 4.8, Opus 4.7 et GPT-5.5 par effort, coût, durée et tokens.
Ne mettez pas Opus 4.8 en max par défaut.Opus 4.8 passe de medium à high puis max, avec des scores de 47 % → 51 % → 58 %. Mais le coût moyen du max passe de 3,98 $ en high à 12,58 $, les tokens de sortie moyens de 48k à 136k, et la durée d’environ 21 minutes à 44 minutes. Autrement dit, max est bien plus fort, mais c’est le dernier palier coûteux : à réserver aux tâches à forte valeur, à coût d’échec élevé et nécessitant une exploration longue, pas à chaque issue du quotidien.
Le progrès d’Opus 4.8 se voit surtout dans sa capacité à dépasser Opus 4.7 max en étant plus fort et moins cher.Opus 4.8 [max] est à 58 %, contre 54 % pour Opus 4.7 [max] ; en même temps, le coût moyen d’Opus 4.8 [max] est de 12,58 $, inférieur aux 18,19 $ d’Opus 4.7 [max]. Cela ne veut pas dire que 4.8 ne progresse pas. Cela veut dire que le gain ressemble surtout à une amélioration d’efficacité et de plafond dans la même famille, pas à un renversement direct de GPT-5.5.
L’avantage de GPT-5.5 est sa base d’efficacité.Le graphique montre GPT-5.5 [medium], pas le GPT-5.5 [xhigh] en tête du classement. Même ainsi, GPT-5.5 [medium] atteint déjà 48 %, avec un coût de 2,34 $, une durée de 10 min 53 s et 18,6k tokens de sortie. Il est proche d’Opus 4.8 [medium] à 47 %, mais moins cher, plus rapide et plus sobre en tokens. En pratique, les tâches de code simples à moyennes ressemblent davantage à une route par défaut GPT-5.5 ; Opus 4.8 convient mieux aux tâches qui demandent du raisonnement profond, une discussion de solution et un jugement contextuel complexe.
Les avis sur Reddit sont aussi partagés : certains utilisateurs disent que DeepSWE est l’un des rares benchmarks qui correspond à leur ressenti avec GPT-5.5, Opus 4.7 et Opus 4.8 ; sur r/developersIndia, un utilisateur dit qu’après avoir beaucoup utilisé GPT-5.5, DeepSWE explique pourquoi il lui paraît plus stable sur les tâches déléguées et /goal. À l’inverse, d’autres se demandent si l’usage uniforme de mini-swe-agent ne limite pas le plafond naturel d’Opus. Plus précisément : Opus 4.8 garde une bonne réputation sur le C bas niveau, l’assembleur, la gestion mémoire, la forte charge concurrente, le lock-free et la discussion de solutions ; mais pour les applications métier, React, SQL et le backend, beaucoup trouvent encore Codex/GPT-5.5 plus stable en qualité de code et en vérification.
Qu’est-ce que DeepSWE ?
Un benchmark conçu pour tester un vrai comportement d’ingénierie au niveau du dépôt, et pas seulement de courts exercices de programmation.
DeepSWE est un benchmark destiné à évaluer les agents de développement de pointe sur des tâches originales d’ingénierie logicielle à long horizon. Il a été présenté par Datacurve pour mesurer la capacité des agents IA à gérer un travail de code réaliste qui demande exploration du dépôt, modifications sur plusieurs fichiers, justesse comportementale et vérification.
Contrairement aux benchmarks dont les tâches sont reprises de pull requests existantes ou de commits publics, les tâches DeepSWE sont écrites de zéro. Datacurve explique que ce choix vise à réduire la contamination par les données d’entraînement et à évaluer la résolution de problème plutôt que le simple rappel.
À quoi sert DeepSWE ?
Il est utile lorsque les équipes accordent de l’importance aux implémentations multi-fichiers, à la vérification et à la fiabilité sous contraintes réelles.
DeepSWE sert à comparer des agents IA de codage sur des tâches plus proches du vrai travail d’ingénierie logicielle que de courts puzzles de programmation. Il aide les chercheurs, les fournisseurs de modèles et les équipes d’ingénierie à voir quels agents savent suivre une demande concise formulée comme par un développeur, inspecter une base de code inconnue, implémenter le changement et conserver le comportement existant.
Le benchmark peut aussi être exécuté par des équipes qui veulent noter un nouvel agent ou reproduire le classement. Datacurve publie le corpus de tâches, les métadonnées, le format des vérificateurs et les instructions pour lancer DeepSWE avec Pier.
Quels sont les avantages de DeepSWE ?
Ce benchmark est conçu pour faire ressortir des écarts de capacité que des évaluations plus petites ou plus saturées peuvent masquer.
DeepSWE se distingue parce qu’il met l’accent sur des tâches originales, une couverture plus large des dépôts et une vérification basée sur le résultat. Ensemble, ces choix en font un meilleur proxy du travail pratique d’un agent de code qu’un benchmark qui mesure surtout le rappel ou de toutes petites modifications.
113tâches originales d’ingénierie logicielle91dépôts open source actifs5langages : TypeScript, Go, Python, JavaScript, Rust668lignes ajoutées en moyenne dans la solution de référence
1
Des tâches originales réduisent le risque de contamination
Les tâches DeepSWE ne sont pas adaptées de correctifs publics. Le score a donc moins de chances de simplement refléter le fait qu’un modèle ait déjà vu la réponse pendant l’entraînement.
2
Les tâches à long horizon ressemblent au développement agentique
Datacurve indique que les prompts DeepSWE sont plus courts que ceux de SWE-bench Pro, tandis que les solutions de référence demandent nettement plus de code et davantage de fichiers.
3
Une couverture plus large des dépôts
Le jeu de tâches couvre de nombreux dépôts actifs au lieu de se concentrer sur une poignée de projets vedettes, ce qui en fait un proxy plus large du travail quotidien d’un agent de code.
4
Les vérificateurs comportementaux récompensent les bons résultats
Les vérificateurs DeepSWE sont conçus pour tester le comportement observable plutôt que la forme interne de l’implémentation, donc plusieurs solutions correctes peuvent réussir.
Quels sont les résultats du benchmark DeepSWE ?
L’information principale n’est pas seulement le classement, mais l’écart observé entre les familles de modèles de pointe.
Rang
Modèle
Score DeepSWE
Lecture
1
GPT-5.5 [xhigh]
70% +- 4%
Meilleur taux de réussite publié sur le classement officiel DeepSWE.
2
Claude Opus 4.8 [max]
58% +- 5%
Dernier résultat Opus sur le classement officiel : au-dessus d’Opus 4.7 max, mais toujours sous GPT-5.5.
3
GPT-5.4 [xhigh]
56% +- 5%
Proche d’Opus 4.8 dans la marge annoncée et présenté par Datacurve comme offrant un bon rapport coût-performance.
4
Claude Opus 4.7 [max]
54% +- 5%
Proche de GPT-5.4 dans la marge annoncée, mais désormais sous Opus 4.8 sur ce benchmark.
5
Claude Sonnet 4.6 [high]
32% +- 4%
Taux de réussite plus faible sur les tâches DeepSWE de longue durée.
Le principal enseignement est l’écart. Datacurve rapporte que les scores DeepSWE couvrent une plage beaucoup plus large que ceux de SWE-bench Pro au sein des mêmes familles de modèles de pointe, ce qui suggère que des tâches originales et de longue durée peuvent révéler des écarts de capacité que des benchmarks publics plus courts ou plus saturés masquent.
Qu’est-ce que cela signifie pour les utilisateurs d’outils de code ?
Utilisez le benchmark comme signal d’aide à la décision, puis mettez les finalistes à l’épreuve sur vos propres dépôts.
Pour les utilisateurs qui choisissent un modèle IA pour programmer, DeepSWE invite à évaluer les modèles sur le travail que vous devez vraiment accomplir. Si votre tâche consiste à modifier plusieurs fichiers dans un dépôt inconnu, un benchmark de longue durée peut être un signal plus pertinent qu’un petit quiz de code ou qu’un classement trop saturé.
Le résultat suggère aussi que le taux de réussite n’est pas le seul signal pratique. Datacurve suit les tokens de sortie, le temps écoulé et le coût par essai, et rapporte que davantage de tokens, davantage de temps ou un coût plus élevé ne donnent pas systématiquement de meilleurs résultats. Les développeurs devraient comparer la fiabilité, le coût, la latence et la fréquence à laquelle un modèle manque une exigence.
Une démarche raisonnable consiste à utiliser DeepSWE comme un point de données propre à ce benchmark, puis à tester les meilleurs modèles candidats sur vos propres dépôts, langages et standards de revue avant de standardiser un assistant de code.
Signal 01
Faites correspondre le benchmark à votre flux de travail
Donnez la priorité aux évaluations de longue durée lorsque vos développeurs font surtout de l’exploration de dépôt et des changements multi-fichiers.
Signal 02
Mesurez la fiabilité, pas seulement la vitesse
Suivez les exigences manquées, la reprise de travail, le coût et la latence en plus du taux de réussite brut avant de choisir un modèle par défaut.
Signal 03
Organisez votre propre comparaison
Les benchmarks réduisent le champ, mais votre choix final doit venir de tests sur votre propre dépôt, votre niveau d’exigence en revue et votre tolérance au risque.
Tâches DeepSWE et mode d’exécution du benchmark
Le benchmark couvre des travaux de dépôt variés, et le guide de démarrage rapide est pensé pour des exécutions d’agents reproductibles.
Couverture des tâches
Quelles tâches sont incluses dans DeepSWE ?
DeepSWE comprend 113 tâches stables couvrant des dépôts TypeScript, Go, Python, JavaScript et Rust. Parmi les exemples publiés par Datacurve figurent l’annulation de lectures de corps en attente lors de l’arrêt, la correction du tri des labels PromQL, l’ajout de lecture de fichiers de configuration à des outils en ligne de commande, l’ajout d’une détection déterministe des conflits sur les écritures Y.Map, ainsi que l’ajout d’opérations XML de diff, patch et merge.
Comportement d’exécutionGestion de l’arrêt, annulation, cycle de vie asynchrone et comportements sensibles aux régressions.
Structures de donnéesTri, pagination, structures Map, instantanés, composition de schémas et règles de conflit déterministes.
Outillage développeurLecture de config CLI, manifests, linting, profilage, caches et rapports générés.
Démarrage rapide
Comment exécuter DeepSWE ?
Datacurve indique que les tâches DeepSWE sont compatibles Harbor et peuvent être exécutées avec Pier, un framework d’évaluation d’agents de code en sandbox. Le guide officiel clone le dépôt DeepSWE, installe Pier, puis lance un agent et un modèle choisis sur le répertoire des tâches.
git clone https://github.com/datacurve-ai/deep-swe
uv tool install git+https://github.com/datacurve-ai/pier
# GPT-5.5 via Codex
export OPENAI_API_KEY=...
pier run -p deep-swe/tasks --agent mini-swe-agent --model openai/gpt-5.5
# Claude Opus 4.7 via Claude Code
export ANTHROPIC_API_KEY=...
pier run -p deep-swe/tasks --agent mini-swe-agent --model anthropic/claude-opus-4-7
L’enseignement pratique : utilisez le benchmark public pour présélectionner des candidats, puis validez-les sur votre propre base de code avant de standardiser un outil.
