Claude Opus vs Sonnet vs Haiku
Qu'est-ce qui a vraiment besoin du modèle top-tier ?

Tout le monde dans l'ops LLM a la même intuition : la majorité des requêtes n'a pas besoin du modèle top. Personne ne publie les données. Donc on a fait l'expérience nous-mêmes.

Dix mille requêtes prod réelles, classées en six catégories de tâches, chacune envoyée à Claude Haiku 4.5, Sonnet 4.6, et Opus 4.7. Sorties scorées en aveugle par deux évaluateurs humains plus un juge LLM. Voici où la qualité diverge vraiment, et où elle ne diverge pas.

Méthodologie

On a tiré 10 000 requêtes réelles de trois sources : un chatbot de support client, un agent de recherche RAG interne, et une intégration d'assistance au code. Chaque requête a été classée dans une des six catégories par un petit classifier avant routing :

1. Salutations / small talk, "salut", "bonjour", "merci", "ça va"
2. Q&A factuel court, "quelle est la capitale du Portugal", "quand X a été fondée"
3. Résumé, condenser un document de 1-5K tokens en 150 tokens
4. Extraction structurée, tirer entités nommées, dates, ou champs depuis du texte
5. Raisonnement multi-étapes, "compare ces trois approches et recommande"
6. Génération / refactoring de code, tâches code non triviales

Chaque requête a tapé les trois modèles. Sorties scorées de 1 à 5 sur trois axes :

• Correction (factuellement juste, pas d'hallucination)
• Complétude (réponse entière à la question)
• Utilité (un utilisateur réel l'accepterait-il ?)

Deux évaluateurs humains ont noté un échantillon stratifié de 2 000 sorties en aveugle. Un juge LLM (un autre modèle, Gemini 2.5 Pro, pour éviter le biais de self-preference) a noté les 30 000. Accord humain/LLM : 94 % sur la correction, 89 % sur les deux autres axes.

Les résultats principaux

Voici le score moyen par modèle par catégorie, sur une échelle 1-5 :

Le pattern est net : pour les deux premières catégories, les trois modèles sont essentiellement indistinguables. Pour les deux dernières, Haiku s'effondre. Sonnet et Opus sont proches, mais Opus tire devant significativement sur le code.

Où Haiku est vraiment suffisant

Salutations, small talk, Q&A factuel court : les scores sont à 0,05 points d'Opus. Au delta de coût en jeu. Haiku est ~19× moins cher qu'Opus en input, ~19× moins cher en output, c'est rien.

Pour un bot de support client où 40 % des requêtes sont une variante de "salut, je peux reset mon mot de passe", router ces 40 % vers Haiku au lieu d'Opus économise 76 % sur cette tranche de la facture, pour une perte de qualité approximativement nulle.

Résumé et extraction structurée : les scores de Haiku baissent nettement (4,3 vs 4,7+), mais en absolu, une sortie à 4,31 reste utile. Pour du résumé non critique, digests email, blurbs dashboard, notes internes, le delta ne vaut pas 19× le coût. Pour du résumé customer-facing (documents juridiques, infos médicales), tu veux Sonnet minimum.

Où Sonnet est suffisant

Pour résumé, extraction, et la plupart des tâches de raisonnement, Sonnet tape 4,4-4,7, ce qui est essentiellement indistinguable d'Opus pour un évaluateur humain. Les deltas précis :

• Résumé : Opus gagne de 0,08 points
• Extraction : Opus gagne de 0,07 points
• Raisonnement multi-étapes : Opus gagne de 0,33 points

Deux des trois sont dans la marge d'erreur. Le delta raisonnement est réel mais tu peux fermer la plupart avec un meilleur prompting sur Sonnet. Côté coût, Sonnet est 5× moins cher qu'Opus. Pour la grande majorité des tâches de raisonnement, Sonnet est le bon choix.

Où Opus justifie son prix

La génération de code et le raisonnement multi-étapes complexe sont les endroits où Opus justifie sa prime de 5× sur Sonnet et 95× sur Haiku.

Exemples où Opus a tiré net devant dans notre test :

• Refactoring multi-fichier. Sonnet produisait du code qui compilait mais introduisait des bugs subtils (mauvais scope, edge cases oubliés). Opus était systématiquement plus prudent.
• Design d'algorithme nouveau. "Écris un rate limiter qui gère à la fois sliding window et token bucket." La première tentative de Sonnet ratait le problème de contention du sliding window ; Opus l'a attrapé.
• Raisonnement en chaîne longue (7+ étapes). Problèmes où la sortie de chaque étape nourrit la suivante. Le taux d'erreur de Sonnet se composait ; Opus restait stable.

Si ton produit est un assistant de code, un conseiller d'architecture, ou un agent de recherche qui enchaîne beaucoup d'étapes, Opus vaut le coup. Pour la plupart des autres produits, tu surpayes.

La vraie règle des 70 %

Voici la distribution des catégories dans notre échantillon de 10 000 requêtes :

70 % des requêtes (les quatre premières catégories) étaient traitées sans perte de qualité sur Haiku ou Sonnet. Seules 9 %, la tranche code, avaient vraiment besoin d'Opus pour taper le score max.

Si tu routes :

• Salutations + Q&A court → Haiku (40 %)
• Résumé + extraction → Sonnet (32 %)
• Raisonnement → Sonnet (19 %)
• Code → Opus (9 %)

Coût effectif aux tarifs publiés d'Anthropic : 1,32 $ pour 1 000 requêtes. Tout sur Opus : 4,75 $ pour 1 000 requêtes. Soit une réduction de 72 %, mesurable sur un échantillon assez grand pour que la significativité statistique soit serrée (p < 0,001 sur scoring apparié).

Le folklore "70 % des requêtes n'ont pas besoin du modèle top" est approximativement correct. Les données le confirment.

Les caveats et ce que ça ne prouve pas

Trois caveats honnêtes :

1. Le domaine compte. Nos requêtes venaient de trois produits spécifiques. Un outil de recherche scientifique ou un analyseur de contrats juridiques aurait probablement une distribution très différente, avec raisonnement et extraction qui dominent. Il faut lancer cette classification sur ton trafic pour connaître ta répartition.

2. Haiku 4.5 est inhabituellement fort. La version 4.5 a refermé un gros écart de qualité avec Sonnet sur le retrieval et l'extraction. Ces chiffres seraient pires sur Haiku 3.5 ou antérieur. Surveille les versions quand tu planifies tes règles de routing.

3. La dérive de tâche est réelle. Le même utilisateur peut envoyer une salutation, une question de raisonnement, et une tâche code dans une conversation. Il faut classifier par requête, pas par utilisateur ou par session. C'est là qu'un bon router gagne son pain.

Ce que doit faire un router

En partant de ces données, la logique de routing n'est pas mystérieuse :

1. Classer la requête entrante en moins d'1 ms avec un petit modèle ou un classifier à règles.
2. Chercher le bon tier pour cette catégorie, selon ta configuration.
3. Appliquer les overrides, règles par clé, par client, plafonds de coût qui forcent un downgrade.
4. Tracker les résultats, logger quel mapping catégorie-vers-modèle a eu quel taux d'acceptation, et ajuster.

Notre router fait les étapes 1-3 en 0,4 ms en moyenne. L'étape 4 est importante pour le tuning long terme, tu observes ton taux d'acceptation par route et tu ajustes.

La conclusion

Si tu fais tourner toutes tes requêtes sur ton modèle top-tier, tu brûles 3-4 $ pour 1 $ de bénéfice qualité réel sur les 70-80 % de requêtes qui n'en ont pas besoin. Les données sont sans ambiguïté.

La bonne question n'est pas "quel modèle est le meilleur ?". C'est "quel modèle est suffisant, par catégorie de requête ?". Et la réponse, mesurée sur du trafic réel, inclut presque toujours Haiku et Sonnet pour une majorité de ton volume.

---

À lire aussi : Les maths cachées du pricing LLM plonge sur pourquoi ton coût par requête est plus gros que le prix affiché le suggère.