Le Calcul du Coût des Agents IA : Quand Haiku Bat Sonnet (et Quand Non)

Table des matières

Mis à jour juin 2026.

TL;DR : Choisir Claude Haiku plutôt que Sonnet peut réduire le coût par appel d’un ordre de grandeur, mais seulement quand la tâche tolère le taux de réussite plus faible de Haiku. La métrique qui compte est le coût par résultat réussi — coût de l’appel plus les nouvelles tentatives plus le nettoyage humain — pas le prix affiché par token. Je route par tâche, et une part significative de mes étapes à fort volume tourne sur Haiku tandis que les décisions de jugement restent sur Sonnet.

Lecture de l’opérateur : Je gère plus de 100 agents, et l’inférence est un poste de dépense réel. Mais j’ai vu des équipes « économiser » en forçant tout sur le modèle le moins cher, puis payer la facture en nouvelles tentatives, escalades et clients mécontents. Le calcul de coût ne fonctionne que quand on mesure tout l’entonnoir.

Le modèle le moins cher n’est pas celui qui a le prix par token le plus bas. C’est celui qui a le coût total le plus bas pour faire le travail correctement. Ce sont des chiffres différents, et l’écart entre eux est là où la plupart des décisions de coût d’agents dérapent.

L’économie des tokens, dite simplement

Anthropic facture Claude au million de tokens, l’entrée et la sortie étant facturées séparément, la sortie coûtant plusieurs fois plus cher que l’entrée. Les chiffres exacts évoluent avec le temps, alors vérifiez les tarifs actuels d’Anthropic — mais c’est la structure qui guide la décision :

• Haiku est le palier bon marché et rapide — de loin le coût par token le plus bas de la famille.
• Sonnet se situe au milieu — nettement plus cher que Haiku, nettement moins cher qu’Opus.
• Opus est le palier premium pour le raisonnement le plus difficile.

Deux choses en découlent. D’abord, les tokens de sortie dominent le coût sur les tâches génératives, donc un modèle verbeux coûte plus cher même au même prix par token. Ensuite, l’écart de prix par token entre Haiku et Sonnet est suffisamment grand pour qu’à une étape à fort volume il se voie absolument sur la facture. C’est l’argument en faveur de Haiku. Maintenant l’argument contre.

La métrique qui compte vraiment : le coût par résultat réussi

Le coût par appel est un chiffre de vanité. Voici la formule que j’utilise réellement :

cout_par_succes = (cout_appel × tentatives) + cout_nettoyage
                   ÷ taux_de_reussite

Où tentatives tient compte des nouvelles tentatives, et cout_nettoyage est le coût attendu d’un humain corrigeant les échecs qui passent au travers. Regardez ce que cela fait à la comparaison.

Supposons que Haiku coûte environ un dixième de Sonnet par appel. Si Haiku réussit 80 % du temps sur une tâche et Sonnet 98 %, les économies par appel paraissent énormes. Mais si chaque échec de Haiku déclenche une nouvelle tentative et qu’1 sur 10 nécessite encore un humain qui coûte de l’argent réel, le terme de nettoyage peut engloutir les économies de tokens. Sur une tâche à faible enjeu et fort volume, le calcul favorise Haiku de façon écrasante. Sur une tâche où un échec envoie un e-mail au mauvais client, il peut s’inverser complètement.

Vous ne pouvez pas trancher sans mesurer le taux de réussite par modèle — ce qui est exactement ce que vous donne un banc d’évaluation. Exécutez le même jeu d’évaluation contre les deux modèles et lisez les taux de réussite sur le même étalon.

Là où Haiku gagne de façon décisive

Haiku est le bon choix quand la tâche est étroite, structurée et vérifiable :

• Classification et routage — « ce message entrant est-il une réservation, une réclamation ou du spam ? » Trois catégories, facile à vérifier, tourne en continu. Haiku toute la journée.
• Extraction avec un schéma — extraire une date, un nom, un montant d’un texte, validé avec Zod. Si la sortie se parse, elle est presque certainement correcte.
• Réécritures courtes et formatage — ajustements de ton, résumer une entrée connue comme bonne, normaliser des données.
• Filtrage de premier passage — Haiku trie, et seuls les cas ambigus sont escaladés vers Sonnet. C’est le pattern à plus fort levier.

Le fil commun : le coût d’une erreur de Haiku est faible et l’erreur est bon marché à détecter. Quand la vérification est bon marché et l’enjeu faible, le modèle bon marché gagne.

Là où Sonnet mérite son prix

Sonnet (et parfois Opus) en vaut la peine quand la tâche est ouverte, multi-étapes ou coûteuse à rater :

• Boucles d’agent multi-outils où un mauvais appel d’outil se propage en cascade. Une plus grande fiabilité de raisonnement se cumule à travers les étapes — les patterns d’orchestration que je couvre dans l’orchestration multi-agents reposent sur le fait que le modèle ne perde pas le fil.
• Génération face au client où une mauvaise sortie coûte la confiance, pas seulement une nouvelle tentative.
• Tout ce où la vérification est elle-même difficile. Si vous ne pouvez pas dire à bas coût si la sortie est correcte, vous ne pouvez pas vous permettre un modèle qui se trompe souvent.

Un échec ici ne coûte pas une nouvelle tentative — il coûte un remboursement, un client perdu, ou mon temps. Face à cela, la prime par token est une erreur d’arrondi.

La règle de routage que je déploie réellement

Je ne choisis pas un modèle par agent. Je route par tâche à l’intérieur de l’agent, généralement avec un classificateur bon marché qui décide quel modèle en aval traite le travail :

function pickModel(task: Task): string {
  // Bon marché, vérifiable, fort volume → Haiku
  if (task.type === "classify" || task.type === "extract") {
    return "claude-haiku";
  }
  // Ouvert ou face au client → Sonnet
  if (task.customerFacing || task.steps > 2) {
    return "claude-sonnet";
  }
  return "claude-sonnet"; // par défaut, le choix sûr
}

Deux principes encodés ici. Par défaut, le modèle sûr, pas le bon marché — on optimise le coût vers le bas depuis une base qui fonctionne, jamais la fiabilité vers le haut depuis une base cassée. Et escaladez, ne pariez pas : laissez Haiku gérer les 80 % faciles et confiez les 20 % difficiles à Sonnet. Cet hybride bat presque toujours le fait de tout faire tourner sur l’un ou l’autre modèle seul.

Il y a aussi le cache de prompts à ajouter par-dessus : si votre prompt système est volumineux et réutilisé, le cache réduit substantiellement le coût d’entrée quel que soit le palier, ce qui rend parfois Sonnet assez bon marché pour que la question de Haiku devienne sans objet.

Un exemple travaillé issu de mon propre stack

Prenez une étape de triage de messages entrants à fort volume. Elle tourne des milliers de fois, la tâche est une classification à trois voies, et une erreur signifie simplement que l’élément atterrit dans une file de revue — bon marché à détecter, faible enjeu. C’est une tâche Haiku de manuel, et la sortir de Sonnet a réduit significativement le coût de cette étape sans impact mesurable sur le résultat qui comptait.

Maintenant prenez l’étape qui rédige la vraie réponse au client. Volume plus faible, ouverte, et un mauvais brouillon qui part coûte la confiance. Celle-là reste sur Sonnet. Même agent, deux modèles, routés par enjeu. Je surveille le coût par exécution et les métriques de réussite des deux, comme je le décris dans comment je mesure si un agent IA fonctionne vraiment — et je ne fais descendre une étape d’un palier qu’après que l’évaluation a dit que le modèle moins cher maintient le taux de réussite.

FAQ

Claude Haiku est-il toujours moins cher que Sonnet en pratique ?

Par token, oui — de loin. Par résultat réussi, pas toujours. Si le taux de réussite plus faible de Haiku déclenche des nouvelles tentatives et du nettoyage humain, le coût total peut dépasser celui de Sonnet sur des tâches où les erreurs sont coûteuses à détecter ou corriger.

Comment décider entre Haiku et Sonnet pour une tâche donnée ?

Notez la tâche sur deux axes : à quel point la sortie est vérifiable et à quel point une erreur est coûteuse. Le travail bon marché à vérifier, à faible enjeu et fort volume va à Haiku ; le travail ouvert, face au client ou difficile à vérifier va à Sonnet. Routez par tâche, pas par agent.

Quelle est l’unique métrique de coût que je dois suivre ?

Le coût par résultat réussi — coût de l’appel multiplié par les tentatives plus le coût de nettoyage attendu, divisé par le taux de réussite. Le prix par appel seul cache les nouvelles tentatives et le temps humain, là où les modèles bon marché deviennent discrètement chers.

Puis-je utiliser les deux modèles dans un seul agent ?

Oui, et vous devriez généralement le faire. Le pattern le plus fort est un premier passage bon marché (Haiku classe ou filtre) qui n’escalade que les cas ambigus vers Sonnet. Cet hybride bat typiquement le fait de tout faire tourner sur un seul palier.