Après la sortie de Sonnet 5, une question revenait sans cesse en commentaire : les benchmarks, c'est bien, mais en vrai, ça donne quoi face à Opus 4.8 ? Cette vidéo y répond avec un duel terrain, pas un décryptage de fiches techniques.
Le principe : Sonnet 5, le « petit » modèle, environ 2,5 fois moins cher, contre Opus 4.8, le « gros ». Trois défis de code, du plus simple au plus vicieux, avec le coût en dollars et le temps affichés en direct. Spoiler annoncé dès la description : ce n'est pas 3-0.
Pour que la comparaison soit équitable :
- le même prompt pour les deux modèles ;
- le même niveau d'effort, xhigh, des deux côtés ;
- deux bases de code séparées, pour qu'aucun modèle ne voie le code de l'autre ;
- la même stack : Next.js 16 ;
- le coût réel de chaque essai, mesuré via la status line de Claude Code.
Les prix de référence au moment du test : 2 $ / 10 $ par million de tokens pour Sonnet 5 (tarif de lancement), 5 $ / 25 $ pour Opus 4.8.
Les trois défis sont des simulations physiques. C'est un bon terrain de test : il faut à la fois du raisonnement (la physique), de la précision (les collisions) et du code d'interface (le rendu).
Premier défi, le plus simple : une balle qui rebondit à l'intérieur d'un octogone en rotation. Il faut gérer la gravité, les rebonds sur des parois qui bougent, et le rendu.
Résultat : un rendu quasi identique. Mais Opus 4.8 a coûté 3,57 $, et Sonnet 5 moins cher : avantage Sonnet. C'est la première leçon du duel : à qualité égale, le coût fait la différence.
On monte d'un cran : 15 balles, avec les collisions entre elles, dans un heptagone. Les collisions multiples sont un piège classique : il faut détecter chaque contact, calculer les rebonds et éviter que les balles se traversent ou restent collées.
C'est le défi où Opus 4.8 reprend l'avantage : 1,67 $ en 6 min 57, contre 2,45 $ pour Sonnet 5. Plus rapide et moins cher, un résultat contre-intuitif puisque son prix au token est plus élevé. Une explication plausible : un modèle plus capable peut arriver au résultat en moins d'allers-retours et donc en moins de tokens, ce qui compense un tarif plus élevé.
Dernier défi, le plus exigeant : passer à la 3D avec React Three Fiber, la bibliothèque qui permet d'utiliser Three.js en React.
C'est là que l'écart de prix explose : Sonnet 5 livre le rendu pour 4,60 $ en 14 min 49, quand Opus 4.8 coûte 14,51 $ en environ 40 minutes, pour le même rendu. Avantage Sonnet, trois fois moins cher.
Score final : deux défis pour Sonnet 5, un pour Opus 4.8. Pas un 3-0, et c'est justement l'enseignement le plus utile : selon la tâche, l'un ou l'autre modèle est le meilleur choix, et le prix au token ne dit pas tout. Ce qui compte, c'est le coût total pour arriver au résultat. La vidéo détaille le verdict, défi par défi.
Le coût d'une tâche, c'est le prix au token multiplié par le nombre de tokens consommés. Et ce second facteur varie énormément d'un modèle à l'autre.
Prenons un exemple fictif pour illustrer. Un modèle A coûte 2,5 fois moins cher au token qu'un modèle B. Si A a besoin de trois allers-retours et de plusieurs corrections pour réussir là où B réussit du premier coup, A peut consommer trois fois plus de tokens, et finir plus cher au total. À l'inverse, sur une tâche simple que les deux réussissent directement, A sera nettement moins cher.
Autrement dit :
- sur les tâches simples et bien cadrées, le modèle le moins cher au token a toutes les chances de gagner ;
- sur certaines tâches, le modèle le plus capable peut devenir le plus économique s'il évite des tentatives ratées ;
- sur les tâches longues, chaque aller-retour relit tout l'historique, ce qui amplifie l'écart.
Le duel illustre ce point : le résultat dépend du défi, et non d'un classement figé. Même sur le défi le plus exigeant, la 3D, c'est ici Sonnet 5 qui l'a emporté.
Le meilleur benchmark reste celui que tu fais sur tes propres tâches. Quelques conseils pour reproduire ce genre de comparaison :
- Isole les essais. Deux dossiers ou deux worktrees séparés, pour qu'un modèle ne s'inspire pas du travail de l'autre.
- Fixe les variables. Même prompt, même niveau d'effort, même version de Claude Code.
- Mesure le coût réel. La status line de Claude Code peut afficher le coût et la consommation de la session, et
/usage donne un récapitulatif.
- Mesure le temps. Un modèle moins cher mais deux fois plus lent n'est pas toujours un bon choix.
- Juge le résultat, pas le chemin. Est-ce que ça marche ? Est-ce que le code est maintenable ?
- Répète. Les modèles ne sont pas déterministes : un seul essai peut être trompeur.
La description de la vidéo mentionne un kit (prompts, dépôt Next.js 16 et grille de résultats) pour refaire le test de ton côté.
- Sonnet 5 tient la comparaison sur beaucoup de tâches, pour moins cher.
- Opus 4.8 peut être plus économique sur certaines tâches, comme le défi des 15 balles.
- Le coût total compte plus que le prix au token.
- Le bon réflexe : choisir le modèle selon la tâche, et mesurer plutôt que supposer.
- Duel : Sonnet 5 contre Opus 4.8, même prompt, effort xhigh, Next.js 16, bases de code séparées.
- Défi 1 (balle dans un octogone) : rendu quasi identique, avantage Sonnet sur le coût.
- Défi 2 (15 balles dans un heptagone) : Opus 4.8 plus rapide et moins cher (1,67 $ contre 2,45 $).
- Défi 3 (3D avec React Three Fiber) : Sonnet 5 à 4,60 $ contre 14,51 $ pour Opus 4.8, même rendu.
- Verdict : 2-1 pour Sonnet 5, et un rappel que le coût réel se mesure à la tâche.
