Benchmark d’agents de code : l’impact de la couche d’exécution

Quatre sessions d’agents de code ont reçu le même dépôt et la même mission générale. Chacune a produit une modification et réussi ses tests ciblés. La durée totale variait pourtant de 6:04 à 13:57.

Codex avec Luna Max a été l’exécution la plus courte. DSH avec Qwen 3.8 27B a été l’exécution locale la plus courte. Les deux configurations OpenCode ont pris davantage de temps, même si OpenCode Qwen déclarait le volume total de tokens le plus faible.

La conclusion principale n’est donc pas un classement universel des modèles. Un agent de code comprend aussi les instructions système, les skills, la mémoire, la gestion du contexte, le cache, les outils, les validations utilisateur, la politique de revue et la vérification finale.

Ce que mesure le benchmark

Les quatre sessions partaient du même dépôt et de la même mission abstraite, sans être contraintes de choisir le même défaut concret. Les deux exécutions Luna ont convergé vers la même zone de flashcards, avec une portée différente. Les exécutions Qwen ont choisi d’autres défauts.

Le test compare donc des profils de runtime complets, et non quatre modèles dans une condition contrôlée « même correctif ». Une session peut être plus longue à cause de la génération, d’un plus grand nombre d’actions outils, d’une revue indépendante ou du compactage et de la continuation du contexte.

Durée et volume de tokens déclaré

• Codex · Luna Max : 363,696 secondes, 2,031 millions de tokens, 11/11 tests ciblés.
• DSH · Qwen 3.8 27B : 483,641 secondes, 1,984 million de tokens, 57 appels d’outils, 14/14 tests.
• OpenCode · Luna Max : 773,632 secondes, 2,683 millions de tokens, 67 appels, 11/11 tests.
• OpenCode · Qwen 100K : 836,954 secondes, 1,687 million de tokens, 39 appels, 17/17 tests.

OpenCode Luna a pris 2,13 fois le temps de Codex Luna. OpenCode Qwen a pris 1,73 fois le temps de DSH Qwen. Pourtant, OpenCode Qwen a été la session la plus longue tout en déclarant le moins de tokens. Un volume réduit n’est donc pas automatiquement un score de vitesse ou de qualité.

Les schémas de tokens diffèrent aussi. Codex inclut le raisonnement dans la sortie. OpenCode le sépare et combine entrée nouvelle et lectures du cache dans le prompt. DSH expose des totaux de prompt et de sortie. Ces valeurs normalisées décrivent une charge de travail, pas directement une facture, une consommation énergétique ou une limite d’abonnement.

Cache, orchestration et revue

Plus de 91 pour cent du volume côté prompt provenait du cache dans les deux sessions OpenCode. OpenCode Luna déclarait 220 630 tokens d’entrée nouvelle et 2 451 456 tokens lus du cache ; OpenCode Qwen en déclarait respectivement 145 146 et 1 514 973.

DSH Qwen a utilisé 36 tours assistant et 57 appels d’outils. OpenCode Luna a utilisé 32 tours et 67 appels ; OpenCode Qwen, 31 tours et 39 appels. L’export Codex ne fournissait pas de compteurs directement comparables ; il est donc omis de cette vue au lieu de recevoir un zéro trompeur.

OpenCode Luna a activé brainstorming, planification, développement piloté par les tests, revue de code et vérification finale. Le reviewer a représenté environ 299 secondes, soit 38,6 pour cent de la session. Ce protocole peut être pertinent pour une modification importante ou risquée. Pour un petit correctif, son coût fixe est devenu une partie substantielle du temps total.

Codex Luna utilisait les recommandations de Karpathy et une mémoire de travail antérieure. Ces éléments ont peut-être favorisé un correctif plus petit, des hypothèses explicites et une vérification directe. Une seule exécution ne permet toutefois pas d’en mesurer l’effet indépendant ; il faut un bras expérimental skills activés contre skills désactivés.

Quel runtime pour quelle tâche ?

• Pour un petit correctif cloud bien borné, Codex Luna Max a été le chemin observé le plus court.
• Pour l’exécution locale de Qwen, DSH Qwen a été le runtime le plus rapide dans ce test.
• OpenCode reste utile lorsque la portabilité des fournisseurs, la planification visible et une interface indépendante du modèle comptent davantage que le temps minimal.
• Pour une refonte importante ou un changement à fort risque de régression, une chaîne explicite de planification et de revue peut justifier son surcoût.
• Pour les micro-tâches, un profil plus léger devrait éviter les coûts de processus fixes, sauf si le risque impose des contrôles supplémentaires.

Limites et prochain benchmark

Chaque condition n’a été exécutée qu’une fois. Les agents n’ont pas produit le même correctif, les exports de tokens n’utilisent pas la même sémantique et Qwen fonctionnait localement alors que Luna utilisait le cloud. Le nombre de tests n’est pas un classement de qualité puisque les portées diffèrent.

Le prochain test devrait imposer un seul défaut, un même test d’acceptation, les mêmes outils, les mêmes instructions système et les mêmes limites de contexte et de temps. Chaque condition devrait être répétée au moins trois fois. Pour Qwen, il faut enregistrer le matériel, la quantification, la limite de contexte, le format du KV cache et le débit de génération. Des horodatages par étape sépareraient enfin latence du modèle, outils et revue.

Preuves et sources des marques

Les mesures ont été reconstruites depuis quatre exports conservés : `lunamax-session.jsonl`, `session.jsonl`, `session-ses_fdda.md` et `session-ses_fdd8.md`.

• Organisation GitHub officielle d’OpenAI
• Logo officiel de DeepSeek dans le dépôt DeepSeek-VL
• Organisation GitHub officielle de Qwen
• Dépôt officiel d’OpenCode