+160 XP

La famille de modèles Claude : opus, sonnet, haiku, et quand utiliser chacun

Choisir le mauvais tier Claude est la façon la plus courante de brûler de l'argent ou de livrer quelque chose de lent et de bête. Anthropic propose trois familles de modèles, et la différence entre elles n'est pas « meilleur » contre « moins bon ». C'est un arbitrage assumé entre capacité brute, latence et coût, et votre travail de builder consiste à router chaque tâche vers le tier le moins cher qui passe encore la barre de qualité.

Voici le modèle mental avant les détails : Opus pour le raisonnement le plus difficile et le travail agentique long, Sonnet pour l'équilibre quotidien entre intelligence et rapidité, et Haiku pour les tâches à fort volume, sensibles à la latence, où il vous faut une réponse en un clin d'œil.

Les trois tiers, par mission et non par ego

Voyez les familles comme des rôles dans une équipe, pas comme un classement.

Haiku est votre répondeur rapide. C'est l'option la moins chère et la plus faible en latence, conçue pour la classification, l'extraction, le routing, les résumés courts et la boucle interne des pipelines qui tournent des milliers de fois. Quand votre budget par appel est serré et que la tâche est bien cadrée, Haiku est le choix par défaut.

Sonnet est le cheval de trait. Il absorbe l'essentiel du trafic de production : rédaction, code, raisonnement multi-étapes, usage d'outils et analyse de documents. Il est plus solide que Haiku tout en restant assez rapide et abordable pour tourner à l'échelle. Si vous ne savez pas par où commencer, commencez ici.

Opus est le penseur lourd. Sortez-le pour les problèmes vraiment difficiles : gros refactors sur de nombreux fichiers, synthèse de recherche approfondie, workflows agentiques délicats où une étape intermédiaire erronée se propage, et tout ce où le coût d'une mauvaise réponse écrase le coût de l'appel.

Les numéros de version bougent (Anthropic a livré des générations Claude 4.x de Sonnet et Opus, avec Haiku mis à jour en parallèle), donc récupérez toujours les model IDs et les capacités à jour depuis l'aperçu des modèles dans la doc plutôt que de les coder en dur de mémoire. **Les *familles* sont le concept stable ; c'est le suffixe de version qui change**.

Un exemple concret de routing

Vous construisez un outil de support avec deux missions très différentes.

Mission A : taguer les tickets entrants par catégorie et urgence. Cela tourne sur chaque ticket, toute la journée, et doit être rapide et peu coûteux. L'espace de décision est petit et le prompt est le même à chaque fois. C'est du Haiku manuel scolaire.

python
from anthropic import Anthropic

client = Anthropic()

def classify_ticket(text: str) -> str:
    resp = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=20,
        system="Classify the ticket. Reply with exactly one of: BILLING, BUG, FEATURE, OTHER.",
        messages=[{"role": "user", "content": text}],
    )
    return resp.content[0].text.strip()

print(classify_ticket("I was charged twice this month"))

Notez le max_tokens serré et la sortie contrainte. Sur une tâche de classification, vous ne payez pas un modèle pour penser à voix haute, vous payez pour un label.

Mission B : un agent qui résout un bug complexe en lisant un repo multi-fichiers, en reproduisant le problème et en proposant un patch. C'est long-horizon, multi-étapes, et un mauvais mouvement précoce gâche tout le run. On est en territoire Opus (ou un bon Sonnet si le budget est serré et la codebase petite). Ici l'appel a une autre allure : budget de tokens élevé, accès aux outils, et extended thinking activé.

On arrive à ce contrôle juste après.

La grande fenêtre de contexte change la façon de prompter

Les modèles Claude embarquent une grande fenêtre de contexte (de l'ordre de quelques centaines de milliers de tokens sur les tiers standards, avec un contexte encore plus large disponible dans certaines configurations). En pratique, cela veut dire que vous pouvez déposer un module entier de codebase, un long contrat ou une transcription complète de réunion directement dans un seul message au lieu de tout pré-découper via du retrieval.

Cela ne rend pas le RAG obsolète. Cela change *quand* vous y recourez. La règle empirique :

  • Si le matériel pertinent tient confortablement et que vous l'interrogez une ou deux fois, mettez-le simplement dans le prompt. Plus simple, moins de pièces mobiles.
  • Si le corpus est énorme, change constamment, ou que vous l'interrogez des milliers de fois, faites du retrieval pour ne pas payer la relecture des mêmes tokens à chaque appel.

Un levier de coût non évident est le prompt caching. Quand vous envoyez le même grand préfixe (un long system prompt, un gros document, un schéma d'outils) sur de nombreux appels, Anthropic peut le mettre en cache pour que vous ne payiez pas plein tarif à le retraiter chaque fois. Pour les boucles agentiques qui renvoient le même contexte à chaque tour, l'économie est importante. La mécanique est décrite dans la documentation de la Messages API.

Contrôles d'effort et de thinking

C'est là que le choix de tier cesse d'être binaire. Les modèles Claude modernes exposent l'extended thinking (aussi appelé le budget de raisonnement ou de « thinking » du modèle) : vous pouvez laisser le modèle produire un raisonnement interne avant sa réponse finale, et vous contrôlez la dose.

Plus de thinking signifie de meilleurs résultats sur les problèmes difficiles et multi-étapes, au prix de plus de tokens et de plus de latence. Moins de thinking (ou pas du tout) signifie des réponses rapides et peu coûteuses, très correctes pour des tâches directes.

Vous réglez cela avec un paramètre thinking et un budget de tokens :

python
resp = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=8000,
    thinking={"type": "enabled", "budget_tokens": 4000},
    messages=[{"role": "user", "content": "Refactor this module for testability:\n\n" + source}],
)

Le workflow pratique est une décision à deux axes, pas un :

  1. Choisissez la famille (Haiku / Sonnet / Opus) pour le plancher de capacité dont vous avez besoin.
  2. Réglez le budget de thinking selon la difficulté de *cet appel précis*.

Un Sonnet avec un budget de thinking généreux peut surpasser un Opus sans thinking sur certaines tâches de raisonnement, et coûter moins cher. Mesurez donc sur vos propres evals avant de supposer que « le plus gros modèle gagne ». L'objectif est la combinaison fiable la moins chère, pas la plus chère.

Claude's extended thinking, explained

Watch on YouTube

Où apparaissent les tiers dans l'écosystème

Les mêmes familles alimentent tout ce que livre Anthropic, mais la surface change le tier que vous touchez et la manière de le piloter.

Dans les applications Claude (web, desktop, mobile), vous choisissez généralement le modèle dans un menu déroulant. Les Projects permettent d'épingler un modèle ainsi qu'un contexte et des fichiers persistants pour un corps de travail. Les Artifacts affichent documents, applications et diagrammes générés dans un panneau latéral sur lequel vous pouvez itérer. Les Styles permettent d'enregistrer un ton et un format pour que la sortie corresponde à votre voix sans re-prompter chaque fois.

Les Skills empaquettent des instructions et des ressources réutilisables que le modèle peut invoquer pour des tâches répétables, et les Connectors (y compris la marketplace de connecteurs) relient Claude à des outils et sources de données externes. Sous le capot, les connecteurs parlent MCP, le Model Context Protocol, le standard ouvert pour exposer outils, données et prompts à un modèle de façon cohérente. Apprendre MCP une fois signifie que vos intégrations fonctionnent dans les apps, dans Claude Code et dans vos propres agents API.

Pour les builders, trois surfaces comptent le plus :

  • La Messages API est l'endpoint brut où vous choisissez le model ID, réglez max_tokens et thinking, attachez des outils et activez le prompt caching. Tout le reste s'appuie dessus.
  • Claude Code est l'outil de codage agentique d'Anthropic qui tourne dans votre terminal et votre éditeur, lit et modifie votre repo, exécute des commandes et se connecte à des serveurs MCP. Il utilise par défaut un tier capable pour le gros du travail et c'est là que vivent réellement les tâches de codage agentique longues.
  • Le Claude Agent SDK (avec les managed agents) vous donne le harnais sur lequel Claude Code est construit, pour que vous puissiez bâtir vos propres agents avec la même boucle : usage d'outils, accès aux fichiers et exécution multi-tours. Les repos et exemples sont sur github.com/anthropics, et l'intégration GitHub permet à Claude d'ouvrir des pull requests et de répondre aux issues directement.

La logique de routing vue plus haut s'applique à l'intérieur de tout cela. Un managed agent peut utiliser Haiku pour trier quels fichiers comptent, puis escalader vers Opus pour le correctif proprement dit. Ce type de routing par tiers au sein d'un même workflow est le pattern avancé à intérioriser.

Vérification des acquis

1. Selon la leçon, quel est l'objectif premier quand on choisit entre les tiers de modèles Claude ?

2. La leçon décrit la différence entre les familles de modèles comme laquelle des propositions suivantes ?

3. Dans l'exemple de l'outil de support, pourquoi Haiku est-il le bon choix pour taguer les tickets entrants par catégorie et urgence ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les affirmations qui décrivent correctement les cas où recourir à Opus.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les affirmations qui reflètent les recommandations de la leçon sur les familles de modèles et les versions.

Sélectionnez toutes les réponses correctes.

Une politique de routing simple, réellement livrable

Ne routez pas au feeling. Écrivez la politique. Voici un modèle de départ qui associe forme de tâche et tier.

yaml
routing:
  - task: classification_or_extraction
    model: haiku
    thinking: disabled
    notes: high volume, constrained output, tiny max_tokens

  - task: drafting_summarizing_coding
    model: sonnet
    thinking: low_to_medium
    notes: default for most production traffic

  - task: long_agentic_or_deep_reasoning
    model: opus
    thinking: high
    notes: refactors across files, research synthesis, costly-to-be-wrong

Ensuite, faites deux choses. D'abord, posez des garde-fous : plafonnez max_tokens par tier pour qu'un agent qui s'emballe ne puisse pas brûler votre budget en silence. Ensuite, construisez un petit eval set de tâches réelles et faites tourner chaque tier dessus. Vous constaterez d'ordinaire que Sonnet passe la barre sur plus de tâches que prévu, et que vous n'avez besoin d'Opus que sur une minorité. C'est exactement le résultat souhaité : cela veut dire que vous dépensez de l'argent Opus uniquement là où ça paie.

Une note sur la discipline de coût

La tarification est au token et diffère fortement selon le tier (Haiku est le moins cher, Opus le plus cher, avec un écart large). Comme les chiffres exacts changent, vérifiez les tarifs en cours sur la page de pricing officielle avant de modéliser votre unit economics. Les principes durables :

  • Les tokens de thinking sont de vrais tokens. Un budget de thinking généreux sur Opus grimpe vite à l'échelle.
  • Le prompt caching est le plus gros levier pour les appels répétitifs à grand contexte.
  • L'escalade vaut mieux que la montée en gamme généralisée. Faites tourner le tier bon marché d'abord, détectez une faible confiance ou un échec, puis réessayez sur un tier plus puissant.

Points clés à retenir

  • Routez par tâche, pas par prestige. Haiku pour la classification et l'extraction à fort volume, Sonnet comme choix par défaut au quotidien, Opus pour le travail agentique long et le raisonnement profond où une mauvaise réponse coûte cher.
  • Traitez le tier et le budget de thinking comme deux molettes distinctes. Réglez la famille de modèles pour le plancher de capacité et le budget thinking pour la difficulté de l'appel précis ; un Sonnet bien réglé bat souvent un Opus qui réfléchit trop peu.
  • Utilisez la grande fenêtre de contexte délibérément. Mettez le matériel dans le prompt quand il tient et que vous l'interrogez rarement ; faites du retrieval quand le corpus est énorme ou sollicité en permanence ; mettez en cache le préfixe répété dans les deux cas.
  • Écrivez votre politique de routing et appuyez-la sur un vrai eval set. Vous aurez généralement besoin d'Opus moins souvent que l'instinct ne le suggère, et c'est bien le but.
  • Les mêmes familles alimentent tout l'écosystème. Que vous soyez dans les apps, dans Claude Code ou dans l'Agent SDK au-dessus de la Messages API, MCP et le routing par tiers sont les compétences qui se transposent partout.

À faire, tiré de cette leçon

Ces actions sont compilées dans le plan d'action du rôle.

  • Répartissez les tâches entre Haiku, Sonnet et Opus selon le coût et la difficulté
  • Réglez le tier de modèle et le thinking budget comme deux curseurs distincts
  • Activer le prompt caching sur les appels répétés à large contexte
  • N'escalader vers un tier supérieur qu'en cas de faible confiance détectée
Voir le plan d'action complet →

Articles liés

Les articles récents du blog qui s'appuient sur cette leçon.