Quel modèle Claude Code : Opus, Sonnet ou Haiku 5.5 ?

En trois semaines, Anthropic a renouvelé toute sa gamme : Opus 5.5 le 22 septembre 2026 (claude-opus-5-5), Sonnet 5.5 le 28 septembre (claude-sonnet-5-5) et Haiku 5.5 le 7 octobre (claude-haiku-5-5). Dans Claude Code, les alias suivent : opus pointe vers Opus 5.5 depuis la v2.1.280, sonnet vers Sonnet 5.5 depuis la v2.1.284 et haiku vers Haiku 5.5 depuis la v2.1.293, sur l'API Anthropic.

Le paradoxe tient en une ligne : le modèle le plus cher n'est plus le meilleur partout. Sur Terminal-Bench 4.0, Sonnet 5.5 obtient 70,6 % contre 66,4 % pour Opus 5.5, à moitié prix. Et pourtant Opus 5.5 est désormais le modèle par défaut sur Pro et Team. Si tu ne règles rien, toute ton équipe tourne sur le modèle le plus cher, y compris pour renommer une variable. Cet article te donne une grille pour répartir les trois modèles par rôle et régler l'effort de chacun.

Quel modèle choisir dans Claude Code ? La réponse courte

Dans Claude Code, choisir un modèle consiste à attribuer Opus, Sonnet ou Haiku à un rôle (planification, implémentation, revue, sous-agents) selon le rapport entre le coût d'une erreur et le volume de tokens consommés. Voici la grille de départ que je recommande. Elle découle des prix et des positionnements officiels, pas d'une mesure sur ta base de code : mesure avant de la figer.

• Planification, architecture, debug retors : Opus 5.5, effort high ou xhigh. Peu de tokens, enjeu élevé : une erreur de cadrage se paie sur tout ce qui suit.
• Implémentation (features, tests, refactoring) : Sonnet 5.5, effort medium. C'est l'essentiel du volume de tokens, donc l'essentiel de la facture.
• Revue de code : Sonnet 5.5 en première passe, Opus 5.5 sur les diffs sensibles (authentification, paiement, migrations de schéma).
• Sous-agents de recherche, résumé, lecture de logs : Haiku 5.5, effort low. Anthropic le positionne explicitement comme sous-agent d'Opus et Sonnet.
• CI et tâches batch : Sonnet 5.5, sans fast mode (la doc le déconseille hors session interactive).

Combien coûtent Opus 5.5, Sonnet 5.5 et Haiku 5.5 ?

Tarifs par million de tokens (entrée / sortie), relevés sur les pages de lancement Anthropic à la date de publication :

• Opus 5.5 : 4 $ / 20 $, soit 20 % de moins qu'Opus 5 (5 $ / 25 $). Lecture de cache 0,20 $, écriture 5 $. Fast mode : 8 $ / 40 $, jusqu'à 2,5 fois plus rapide (annonce Opus 5.5).
• Sonnet 5.5 : 2 $ / 10 $, écriture de cache 2,50 $. La lecture de cache est annoncée à 0,20 $ au lancement, puis à 0,10 $ dans le changelog Claude Code v2.1.296 et sur la page Haiku 5.5 : revérifie la grille avant de budgéter (annonce Sonnet 5.5).
• Haiku 5.5 : 0,10 $ / 0,50 $ pour les prompts jusqu'à 100k tokens, puis 0,50 $ / 2,50 $ au-delà. Environ 75 % moins cher en moyenne que Haiku 4.5, et premier Haiku doté d'un réglage d'effort (annonce Haiku 5.5).

Piège de lecture : le palier de Haiku 5.5 s'applique par requête. Dans un agent qui accumule du contexte, le tarif bas ne vaut que pour les sous-agents à contexte court et jetable. C'est précisément leur cas d'usage, mais un Haiku utilisé comme agent principal sur une longue session perd une bonne partie de son avantage. Les trois modèles tournent par ailleurs avec une fenêtre de 1M tokens par défaut dans Claude Code.

Sonnet 5.5 bat-il vraiment Opus 5.5 en code agentique ?

Non, pas de façon tranchée. Sonnet 5.5 obtient 70,6 % sur Terminal-Bench 4.0 contre 66,4 % pour Opus 5.5, mais Anthropic indique une marge d'erreur de ±2,6 points sur ce test, et Opus 5.5 reprend l'avantage ailleurs : CursorBench 4.0 (57,8 % contre 55,5 %), Humanity's Last Exam avec outils (67,7 % contre 64,5 %), OSWorld 2.1 (81,8 % contre 80,1 %). La lecture honnête : Sonnet 5.5 et Opus 5.5 sont au coude à coude, avec un léger avantage d'Opus sur le raisonnement et le contexte large. Haiku 5.5, lui, plafonne à 39,2 % sur Terminal-Bench 4.0 : Anthropic recommande elle-même Sonnet ou Opus pour le code agentique complexe.

Ce qui change la décision, c'est le ratio : à qualité comparable, Sonnet coûte deux fois moins cher qu'Opus. Sur l'implémentation, qui concentre le volume, cet écart se retrouve directement sur la facture. C'est la suite logique de ce qu'on observait déjà avec Sonnet 5, proche d'Opus en agentique pour un prix moindre : l'écart de qualité se resserre à chaque génération, l'écart de prix reste.

Configurer le modèle dans Claude Code : /model, opusplan et settings

Ordre de priorité pour le modèle de session, du plus fort au plus faible : /model en cours de session, l'option --model, la variable ANTHROPIC_MODEL, puis le champ model des settings. Ce champ fixe le modèle initial, il n'interdit rien : pour restreindre les choix de l'équipe, la doc de configuration des modèles décrit availableModels et enforceAvailableModels.

L'alias opusplan est le raccourci naturel de la grille : Opus en plan mode, Sonnet à l'exécution. Combiné à un modèle par défaut pour les sous-agents, il se versionne dans le dépôt :

{
  "model": "opusplan",
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
  }
}

Ce fichier .claude/settings.json commité transforme une préférence individuelle en convention d'équipe. Personne n'a plus à se souvenir de passer sur Sonnet : c'est le comportement par défaut du dépôt. Contrepartie à connaître : chaque modèle a son propre cache de prompt, donc chaque bascule entre plan et exécution reconstruit le cache. Sur une tâche courte, enchaîner plusieurs allers-retours plan-exécution peut coûter plus que rester sur Sonnet.

Comment régler l'effort par modèle ?

Depuis la v2.1.280, /effort mémorise un niveau par modèle, et chaque nouveau modèle démarre à son effort par défaut. Opus 5.5, Sonnet 5.5 et Haiku 5.5 acceptent low, medium, high, xhigh et max, avec medium par défaut dans Claude Code. Un effort élevé sur une tâche simple brûle des tokens de raisonnement sans rien rapporter.

# Dans la session
/effort            # sélecteur ; Entrée = sauvegarde pour ce modèle
/effort high       # niveau direct pour le modèle actif
/effort auto       # efface le niveau sauvegardé pour ce modèle
/model opusplan    # Opus en plan mode, Sonnet en exécution

# Au lancement ou en CI
claude --model sonnet --effort medium
CLAUDE_CODE_EFFORT_LEVEL=medium claude -p "Corrige les tests en échec"

Résolution de l'effort, premier match gagnant : CLAUDE_CODE_EFFORT_LEVEL, --effort ou /effort, puis les settings, puis le défaut du modèle. Attention à un piège documenté : la clé effortLevel de premier niveau des settings ne s'applique pas à Opus 5.5, qui démarre à son propre défaut tant que tu n'as pas choisi un niveau pour lui via /effort. En CI, la variable d'environnement reste le seul verrou fiable.

Pourquoi passer les sous-agents sur Haiku 5.5 ?

Un sous-agent d'exploration lit beaucoup et décide peu : il parcourt le dépôt, grep, résume, puis rend la main. C'est exactement le profil pour lequel Haiku 5.5 a été conçu. La doc des sous-agents fixe l'ordre de résolution de leur modèle : le paramètre model passé par Claude à l'outil Agent, puis le frontmatter model de la définition, puis CLAUDE_CODE_SUBAGENT_MODEL, puis le modèle de la conversation. Avant la v2.1.251, la variable d'environnement passait en premier : si de vieux scripts s'appuyaient dessus, le comportement a changé.

---
name: repo-scout
description: Explore le dépôt (grep, lecture de fichiers) et renvoie un résumé factuel avec chemins et lignes. À utiliser avant toute modification multi-fichiers.
tools: Read, Grep, Glob
model: haiku
effort: low
---

Tu es un éclaireur de code. Tu ne modifies rien.
Réponds par : 1) fichiers pertinents (chemin:ligne), 2) conventions observées,
3) points d'attention. Maximum 40 lignes, aucune spéculation.

Ce fichier va dans .claude/agents/repo-scout.md. Haiku collecte, il ne tranche pas : ne lui confie pas une décision d'architecture. Depuis la v2.1.292, l'outil Agent accepte aussi un paramètre effort, ce qui permet à Claude de lancer un sous-agent au niveau demandé. Pour imposer un modèle à tous les sous-agents sans exception (budget strict, CI), CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 (v2.1.257+) ignore le frontmatter. Le recul sur la génération précédente est dans l'équation coût/qualité de Haiku 4.5.

Combien coûte une tâche avec chaque modèle ?

Hypothèses illustratives, pas des mesures : une tâche d'implémentation agentique consomme 150k tokens d'entrée fraîche, 100k d'écriture de cache, 1,2M de lecture de cache et 40k de sortie. Je suppose le même volume de tokens sur chaque modèle, ce qui est faux en pratique : Anthropic annonce que Sonnet 5.5 consomme jusqu'à 30 % de moins par tâche que Sonnet 5, et un modèle plus faible peut itérer davantage.

• Opus 5.5 : 0,15 × 4 + 0,10 × 5 + 1,2 × 0,20 + 0,04 × 20 = 2,14 $ par tâche.
• Sonnet 5.5 (lecture de cache à 0,10 $) : 0,15 × 2 + 0,10 × 2,5 + 1,2 × 0,10 + 0,04 × 10 = 1,07 $ par tâche (1,19 $ avec une lecture de cache à 0,20 $).
• Sous-agent de recherche, 10 appels de 30k tokens d'entrée et 10k de sortie au total : 0,035 $ sur Haiku 5.5, 0,70 $ sur Sonnet 5.5, 1,40 $ sur Opus 5.5. Un facteur 20 entre Haiku et Sonnet.

À 600 tâches par mois pour une équipe, l'écart entre Opus et Sonnet sur l'implémentation représente environ 640 $. Sur abonnement, ce calcul se traduit en consommation des limites sur 5 heures plutôt qu'en dollars, mais le levier est le même. Pour le cadrage budgétaire complet côté direction, voir le coût réel des agents de code pour un CTO.

Les pièges à connaître avant de déployer la grille

• Fast mode réservé à Opus (5.5, 5 et 4.8). Sur abonnement, il est facturé en crédits d'usage hors limites du plan, et doit être activé par un Owner sur Team et Enterprise. Au premier passage en fast, tout le contexte est refacturé au tarif fast non caché : active-le en début de session, pas à 400k tokens de contexte.
• Thinking non désactivable sur Opus 5.5. Si tes workflows coupaient le thinking sur Opus, leur profil de coût change. Pour Sonnet, Anthropic recommande de passer au réglage between_tools avant de migrer vers 5.5 si tu tournais sans thinking.
• Le défaut a changé sous tes pieds. Avant la v2.1.280, Pro et Team Standard démarraient sur Sonnet 5 ; c'est désormais Opus 5.5. Une équipe qui ne change rien consomme ses limites plus vite. Fixe model dans les settings du projet.
• Alias en retard sur les clouds tiers. Sur Bedrock, Vertex et Foundry, les alias peuvent résoudre vers des versions antérieures. Pinne avec ANTHROPIC_DEFAULT_OPUS_MODEL et ses équivalents avant de déployer à l'équipe.
• Compteurs de coût. Avant la v2.1.296, /cost comptait la lecture de cache Sonnet 5.5 à 0,20 $. Mets Claude Code à jour avant de comparer tes mesures.

Trois décisions à prendre cette semaine

• Sors du défaut. Commite un .claude/settings.json avec "model": "opusplan" : Opus pour planifier, Sonnet pour exécuter.
• Passe tes sous-agents sur Haiku 5.5. Crée deux ou trois éclaireurs (repo-scout, log-reader) avec effort: low et vérifie sur trois tâches réelles que la synthèse suffit.
• Mesure toi-même. Une tâche récurrente, deux modèles, même consigne : compare le coût par tâche acceptée (PR mergée), pas le coût par token. Ton usage compte plus que n'importe quel benchmark public.

Le réflexe « Opus partout » reposait sur un écart de qualité qui ne tient plus partout et sur un prix qui a changé. Le modèle le plus puissant se réserve aux moments où une erreur coûte cher ; le reste tourne sur Sonnet, et les éclaireurs sur Haiku. Une bonne répartition ne vaut cependant que si toute l'équipe l'applique de la même façon : mêmes sous-agents, mêmes réglages d'effort, même configuration versionnée. C'est souvent là que les gains se perdent, et c'est ce qu'on cale en formation, sur les projets réels de l'équipe.

Écrit par

Flavien Métivier

Expert PHP/Symfony indépendant depuis 2014, ancien CTO de Kartable et d'Extrabat. Plus de 80 projets menés, de l'audit à la migration.

Mon parcours