Vous disposez d'un nombre fixe de relecteurs et, depuis le 22 septembre 2026, d'une grille tarifaire de modèles qui ne décide plus rien à votre place. GPT-6 Luna s'affiche à 0,10 $ par million de tokens en entrée et 0,50 $ par million en sortie, identifiant d'API gpt-6-luna. Claude Opus 5.5 s'affiche à 4 $ et 20 $, identifiant d'API claude-opus-5-5. Cela représente un écart de 40x de part et d'autre du compteur — notre calcul, à partir des tarifs publics des deux fournisseurs — et cela transforme une question autrefois théorique en une décision de planification hebdomadaire. Pour le même prix, faites-vous tourner dix Agents bon marché ou un seul Agent coûteux ?
Les deux configurations ne sont pas interchangeables. Ce qui les distingue n'est pas la qualité du modèle, et cela se voit à la fin de l'exécution plutôt qu'au début : chacune place une quantité de travail différente devant une personne.
L'arithmétique qui rend la question concrète
OpenAI publie le coût par tâche à côté du score, ce qui est plus utile qu'une grille tarifaire. Sur DeepSWE 1.1, Luna en effort de raisonnement maximal obtient 66,6 %, un score qu'OpenAI décrit comme comparable à Claude Opus 5 et Fable 5 en effort moyen, pour un coût par tâche inférieur de 93 % à celui d'Opus 5 et de 96 % à celui de Fable 5.
Si l'on inverse le premier chiffre, une tâche d'Opus 5 équivaut à environ quatorze tâches de Luna. Dix exécutions de Luna coûtent donc à peu près sept dixièmes d'une seule exécution d'Opus 5 sur ce harnais. Cette multiplication est la nôtre, à partir des 93 % annoncés par OpenAI.
Anthropic affirme qu'Opus 5.5 coûte 40 % de moins à exécuter qu'Opus 5. Appliquez cela et le ratio tombe aux alentours de neuf pour un. Ce chiffre enchaîne les mesures de deux fournisseurs prises sur des harnais différents ; considérez-le donc comme une tendance plutôt qu'un chiffre précis : dix tentatives bon marché et une tentative coûteuse coûtent désormais à peu près la même chose, quelle que soit la méthode de calcul.
| GPT-6 Luna | Claude Opus 5.5 | |
|---|---|---|
| Identifiant d'API | gpt-6-luna |
claude-opus-5-5 |
| Entrée / sortie par million | 0,10 $ / 0,50 $ | 4 $ / 20 $ |
| Entrée mise en cache | −90 % sur les lectures | 0,20 $ en lecture, 5 $ en écriture |
| Fenêtre de contexte | 1 M | 1 M |
| Promesse du fournisseur sur le long horizon | aucune | reste sur la tâche 18 h ou plus |
| Artificial Analysis Index | 37 | 58, classé n° 1 sur 212 |
Deux mises en garde accompagnent ce tableau. Le titre d'OpenAI est que Sol et Luna sont chacun 50 % moins chers que les tarifs promotionnels de GPT-5.6, et « promotionnel » est le mot d'OpenAI lui-même : la comparaison se fait par rapport à un tarif remisé, et non à un tarif public. Et les deux articles de lancement ne constituent pas une comparaison directe. Les deux fournisseurs rapportent un score AutomationBench, à des versions de harnais et des niveaux d'effort différents, le même jour. Mettre ces deux pourcentages dans une même ligne produirait une comparaison qu'aucun des deux laboratoires n'a réalisée. Les ratios de coût par tâche ci-dessus tiennent parce qu'ils proviennent des mesures d'un seul fournisseur.
Trois configurations qui ressemblent à un seul arbitrage
« Dix agents ou un seul » recouvre en réalité trois dispositions, qui se comportent différemment à l'étape de relecture.
| Configuration | Ce qui arrive à la relecture | Qui choisit le gagnant | Fonctionne quand |
|---|---|---|---|
| Dix Agents bon marché, dix Tasks | Dix diffs, dix décisions | Une personne, dix fois | Le backlog est large et chaque élément est acceptable indépendamment |
| Dix Agents bon marché, une seule Task | Un diff, une décision | Votre suite de tests | Une machine peut classer les tentatives sans qu'un humain les lise |
| Un Agent coûteux, une Task | Un diff, une décision | Une personne, une fois | Horizon long, signal automatique faible, ou un changement qui exige du jugement tout du long |
La ligne du milieu est celle que la baisse de prix débloque réellement, et c'est celle que la plupart des équipes négligent. Exécuter la même Task dix fois et conserver la tentative qui passe le typecheck, les tests et le build est une stratégie devenue abordable seulement le jour où une tentative a cessé de coûter de l'argent réel. Avec un taux de réussite au benchmark proche de deux tiers, un tiers des tentatives isolées échoue. Si les tentatives échouaient indépendamment, dix essais n'échoueraient presque jamais tous. Or elles n'échouent pas indépendamment : une tâche à l'énoncé ambigu ou à la fixture manquante met en échec toutes les tentatives de la même manière. Le fan-out vous achète la variance, pas une garantie.
La première ligne est celle que la plupart des équipes choisissent en pratique, et c'est la plus coûteuse. Pas en dollars. Dix Agents sur dix Tasks produisent dix diffs, et chacun d'eux exige qu'une personne le lise, comprenne ce que l'Agent a choisi et assume la responsabilité de le fusionner. Ce coût n'a pas baissé le 22 septembre 2026 et aucune sortie de modèle ne le touche. Nous avons écrit sur pourquoi la relecture humaine est le goulot d'étranglement du travail d'agents en parallèle et sur combien de journées de travail d'agent une journée de travail humaine peut absorber ; l'arithmétique n'en est pas modifiée par des tokens moins chers.
Dix Agents sur Luna, ce n'est pas dix fois la production. C'est dix fois le travail qui arrive. Un modèle moins cher achète des tentatives. Il n'achète pas de capacité de relecture, et les deux sont faciles à confondre quand la facture est le seul chiffre que l'on surveille.
Le coût par changement accepté est le chiffre qui se transpose
Le coût par changement accepté, c'est ce que votre équipe dépense en inférence pour chaque diff qu'une personne lit et accepte réellement. C'est le seul chiffre de coût d'agent qui se rattache au travail livré, car une tentative que personne ne relit n'a rien livré.
Cette définition trie immédiatement les trois configurations. Le fan-out sur une seule Task répartit dix tentatives sur une seule décision de relecture, si bien que des tentatives moins chères font baisser le coût par changement accepté de façon linéaire. L'étalement sur dix Tasks répartit une tentative sur une décision de relecture, dix fois de suite : des tentatives moins chères font baisser la ligne d'inférence tandis que la ligne de relecture reste stable et devient la contrainte. La profondeur sur un seul Agent coûteux achète une plus grande probabilité que l'unique tentative présentée à votre relecteur soit celle qui vaut la peine d'être fusionnée.
Un second effet n'apparaît qu'en pratique. Dix tentatives bon marché et une tentative coûteuse ne se vivent pas de la même manière au quotidien. Artificial Analysis mesure les variantes de raisonnement maximal de ces modèles à 124,23 secondes jusqu'au premier token pour Luna et 102,15 secondes pour Sol, des chiffres tiers qui concernent spécifiquement les variantes max et qu'il vaut la peine de confirmer avant de planifier quoi que ce soit à partir d'eux. Dix Agents qui passent chacun deux minutes en silence avant de produire le moindre caractère ne forment pas un pipeline rapide. Ce sont dix exécutions qui semblent toutes bloquées en même temps, ce qui est un problème de statut plutôt qu'un problème de modèle.
La paire de décisions
Utilisez dix Agents bon marché quand c'est une machine qui décide. Cela signifie que la Task dispose d'un véritable signal d'acceptation qui s'exécute sans personne : un test qui échoue aujourd'hui et doit passer, un typecheck, un build, une règle de lint, un script de reproduction. Le triage, l'étiquetage, l'échafaudage de tests et les refactorisations mécaniques sont éligibles. Tout changement où « est-ce que ça marche » est une commande plutôt qu'une opinion l'est aussi.
Utilisez un seul Agent coûteux quand c'est une personne qui décide. Si accepter le changement exige de lire le code et de se forger un avis, des tentatives supplémentaires n'aident pas : elles multiplient la lecture. Il en va de même pour le travail à long horizon : Anthropic affirme qu'Opus 5.5 reste sur la tâche pendant 18 heures ou plus, et une exécution qui tient un objectif tout un après-midi vaut plus que dix exécutions qui repartent chacune de la même compréhension partielle.
N'utilisez pas le fan-out pour éviter d'écrire le signal d'acceptation. Dix diffs plausibles sans juge automatique, c'est pire qu'un seul diff, car choisir entre dix diffs plausibles est une tâche plus difficile que d'en relire un, et c'est une tâche qui retombe sur la personne que vous cherchiez à protéger.
Ce dont la configuration large a besoin de la couche supérieure
Dix Agents exécutés simultanément posent un problème de coordination avant d'être un problème de coût. Les éléments sont connus : chaque exécution dans son propre worktree pour que deux Agents modifiant le même fichier ne soient pas un incident, un Assignee par Task pour que la propriété ne soit jamais ambiguë, et un statut qui distingue l'exécution de l'attente et de l'échec.
L'Agent définit la manière dont le travail doit être traité. Le Computer fournit l'hôte et les ressources locales. Le Runtime exécute la session. La Task reste l'enregistrement partagé. Quand dix exécutions se terminent à une heure d'intervalle, c'est cette dernière partie qui empêche l'heure de se transformer en chasse au trésor à travers dix terminaux.
Une exécution de Luna terminée devrait renvoyer quelque chose comme ceci à sa Task, et non dans un journal de session privé :
SH-312 Add retry with backoff to the webhook dispatcher
Runtime gpt-6-luna (fan-out, 8 attempts, 3 passed the suite)
Selected attempt 6, smallest diff of the passing set
Evidence typecheck ok, 214 tests pass, build ok, coverage +0.4%
Known limit no test for the 429 path, dispatcher is not idempotent yet
Status Ready for review, waiting on a human
La ligne de sélection est la partie qui compte. Elle indique ce qui a décidé, afin que le relecteur sache s'il confirme le choix d'une machine ou s'il prend lui-même la décision. Dix tentatives sans trace de sélection, c'est dix fois le travail déguisé en une seule Task.
La réponse
Dix Agents bon marché livrent davantage quand une suite de tests décide et que le backlog est assez large pour les occuper. Un seul Agent coûteux livre davantage quand la décision d'acceptation est humaine, que l'horizon est long ou que le signal automatique est faible. La plupart des équipes veulent les deux, orientés selon le type de Task plutôt que selon les préférences, ce qui est l'argument développé dans associer les modèles aux rôles d'agent.
Aucune des deux configurations ne change la dernière étape. Les Agents font la recherche, exécutent, testent et rendent compte. Les personnes donnent la direction, accordent l'autorité et acceptent le résultat. Les prix des modèles ont bougé d'un facteur 40 en une journée, et le nombre de changements que votre équipe peut accepter de manière responsable n'a pas bougé du tout.
Si vous faites déjà tourner plusieurs agents, Sharkly vous offre un seul endroit pour garder le contexte, la progression, les obstacles, les résultats et la relecture humaine visibles de la demande à la mise en production, quel que soit le runtime qui a produit le diff.
