Fable, Opus, Sonnet, Haiku : le guide d’Anthropic qui déconseille son propre haut de gamme

Le 9 novembre, le blog développeurs d’Anthropic a publié un long mode d’emploi signé Addy Osmani : quel modèle Claude choisir, avec quel niveau d’effort, pour quelle tâche. Sur le papier, c’est un guide d’achat. En le lisant avec une calculette, c’est autre chose : un document où l’éditeur reconnaît, chiffres maison à l’appui, que le haut de gamme et les réglages maximaux coûtent beaucoup pour rapporter peu. Ce n’est pas moi qui le dis. C’est écrit dans leurs propres tableaux.

Ce que le guide recommande vraiment

La conclusion tient en une ligne : démarrer presque tout avec Opus 5.5 en effort medium, toucher à l’effort avant de toucher au modèle, descendre vers Sonnet ou Haiku pour le volume, ne monter vers Fable que pour les chantiers les plus lourds, et mesurer sur son propre travail.

Rien de révolutionnaire. Mais regardez ce que cela implique : le modèle par défaut conseillé n’est pas le plus cher. Fable 5.2, la vitrine, est cantonné aux refactors et migrations majeurs, à la planification d’architecture, au pilotage de nombreux sous-agents et à la recherche approfondie. Autrement dit, à une minorité d’usages.

Les tarifs API expliquent pourquoi :

Fable coûte exactement le double d’Opus par token. Les quatre modèles partagent pourtant la même fenêtre de contexte d’un million de tokens et la même sortie maximale de 128K. Le surcoût achète de la capacité de raisonnement, pas de l’espace. Pour la plupart des tâches, l’éditeur lui-même vous dit que vous n’en avez pas besoin.

L’effort maximal, ou la réduflation à l’envers

Le passage le plus instructif concerne les niveaux d’effort. Sur SWE-bench Pro, avec Opus 5.5 :

• passer de high à medium coûte environ 2,5 points pour environ 70 % du prix ;
• passer à low coûte environ 8 points pour un tiers du prix ;
• passer de high à xhigh rapporte environ 1,4 point pour 2,5 fois le prix.

Relisez la dernière ligne. Deux fois et demie la facture pour un gain qui tient dans la marge d’erreur d’un benchmark. Le guide le dit d’ailleurs à sa manière : au-delà de high, un cran d’effort supplémentaire peut coûter autant qu’un modèle plus gros, et l’effort n’apporte ni connaissance ni compétence que le modèle n’a pas déjà.

J’ai décrit dans L’illusion Claude Fable 5 la réduflation appliquée aux forfaits : on vous vend un x20, on vous livre un x6,7. Ici, c’est le mouvement inverse et tout aussi rentable pour le vendeur. Les curseurs qui vont jusqu’à max existent pour qu’on les pousse. Le marketing parle de puissance, le tableau parle de rendements décroissants.

Le mode advisor : un produit dont la notice dit qu’il ne sert à rien

Le mode advisor, en bêta, associe un exécutant rapide et bon marché à un conseiller plus puissant qu’il peut consulter en cours de tâche. L’idée est séduisante : payer l’essentiel des tokens au tarif du petit modèle, et ne solliciter le gros que lorsque c’est utile.

Sauf que le guide de coût de la plateforme, cité dans l’article, est d’une prudence remarquable : aucune des quatre combinaisons de son propre tableau ne bat clairement l’exécutant seul. L’exemple donné est cruel : Opus 5.5 en high, épaulé par un conseiller Fable, gagne 1,7 point pour environ 2,1 fois le coût. Une marge que l’article qualifie lui-même de proche du bruit entre deux exécutions.

Il faut saluer l’honnêteté. Mais il faut aussi en tirer la conséquence : une fonctionnalité dont la documentation officielle peine à démontrer l’intérêt économique est d’abord une fonctionnalité qui consomme.

La délégation ne paie que si elle remplace

Le seul résultat franchement favorable du guide concerne la délégation. Sur un benchmark interne de recherche de défauts portant sur environ 22 millions de tokens de code, un Opus 5.5 qui pilote jusqu’à 25 workers Sonnet 5.5 coûte environ un tiers de moins qu’Opus seul, pour un score comparable.

C’est intéressant, et cela précise ce que j’écrivais à propos des dynamic workflows : multiplier les sous-agents n’est pas une économie en soi. L’économie vient de ce qu’on retire au gros modèle pour le confier aux petits. Si l’orchestration s’ajoute au travail au lieu de le remplacer, le compteur tourne simplement plus vite.

La règle que donne le guide est saine : confier aux petits modèles ce dont l’erreur se voit tout de suite (recherche de fichiers, lecture de logs, exécution de tests), garder les modifications de code et les jugements sur le modèle principal. Concrètement, dans Claude Code, cela se règle par un model: haiku dans la définition d’un sous-agent, ou par la variable CLAUDE_CODE_SUBAGENT_MODEL. Le sous-agent Explore intégré, lui, tourne par défaut sur le modèle de la session : c’est à vous de le redéfinir si vous ne voulez pas payer du Opus pour faire un grep.

Le guide reconnaît aussi que les petits modèles tiennent mal les longues boucles agentiques. Haiku n’est donc pas une solution miracle : il est excellent pour ce qui se vérifie, médiocre pour ce qui s’enchaîne.

Le cache, ou la petite laisse

Un détail technique mérite qu’on s’y arrête : le cache appartient au modèle qui l’a écrit. Changer de modèle en cours de conversation impose de repayer une écriture complète du cache, sauf à compacter ou résumer d’abord.

Sur le plan technique, c’est logique. Sur le plan économique, c’est une friction de plus pour quiconque voudrait jongler librement entre les modèles. J’ai montré dans mon guide sur le prompt caching que le cache peut diviser une facture par dix. Le revers de la médaille, c’est que plus votre architecture repose sur le cache, plus il devient coûteux de sortir du rail sur lequel vous êtes engagé. Ajoutez le verrouillage des tokens d’abonnement que je décrivais dans Pourquoi j’envisage d’annuler mon abonnement Claude, et la cage dorée gagne un barreau.

Autre détail révélateur : l’alias haiku pointe vers Haiku 5.5 sur l’API Anthropic, mais encore vers Haiku 4.5 sur Bedrock, Google Cloud et Microsoft Foundry. Selon le tuyau par lequel vous passez, le même nom ne désigne pas le même modèle. Pour qui prétend comparer des coûts, c’est une source d’erreur silencieuse.

Le chiffre que tout le monde devrait encadrer

Dans un benchmark de recherche portant sur vingt problèmes, deux d’entre eux représentaient 43 % de la dépense totale.

C’est sans doute la phrase la plus utile de tout l’article. Le coût de l’IA n’est pas linéaire : il se concentre sur une poignée de tâches difficiles où le modèle tourne en rond, relance, explore. Raisonner sur un coût moyen par requête, c’est se condamner à découvrir la vraie facture en fin de mois. C’est précisément ce que je décrivais dans Le mirage de l’IA illimitée : l’IA n’est pas un logiciel à coût marginal nul, c’est un service énergétique, et ses queues de distribution sont épaisses.

Mesurer avant de payer : le protocole qu’il faut voler

Si le guide a un mérite durable, c’est son protocole de mesure, qu’il faut reprendre tel quel :

1. Constituer un échantillon de vraies tâches, chacune avec un critère de réussite vérifiable : un test qui passe, un ticket fermé, un résultat juste.
2. Faire tourner chaque modèle à deux ou trois niveaux d’effort, chacun dans sa propre session pour ne pas fausser le cache.
3. Relever le coût réel de chaque tâche terminée dans le champ usage des réponses.
4. Tracer score et dépense, et n’adopter une configuration multi-modèles que si elle bat tous les points obtenus par un modèle seul.
5. Faire tourner le gagnant en parallèle sur une partie du trafic réel avant de basculer.

Le point 4 est le plus important, et le plus ignoré. Une architecture sophistiquée qui ne bat pas un modèle seul bien réglé n’est pas de l’ingénierie : c’est de la décoration facturée au token. Même l’alias opusplan d’Anthropic (Opus pour planifier, Sonnet pour exécuter) doit, selon l’article lui-même, être mesuré avant d’être adopté par défaut.

Pour un test rapide dans Claude Code : lancer la même tâche sur deux modèles avec /model et comparer ce qu’affiche /usage. Dix minutes, et vous saurez si votre abonnement brûle des tokens pour rien.

Ce qu’il faut retenir

Ce guide est un document de fournisseur, avec des benchmarks maison qu’il faut prendre comme tels. Mais il a une vertu rare : il dit, à qui sait lire, que la valeur n’est pas en haut de la gamme. Elle est dans le réglage, la délégation bien pensée et la mesure.

C’est cohérent avec ce que j’observe depuis des mois, et que j’écrivais dans Suffisamment bon, cinquante fois moins cher : la question n’est plus de savoir quel modèle est le meilleur, mais lequel suffit. Anthropic vient de le reconnaître pour sa propre gamme. Il reste à en tirer la conclusion que l’éditeur ne tirera pas pour vous : chaque cran au-dessus du nécessaire est une marge que vous offrez au vendeur, et comme je le rappelais à propos de la sûreté de l’IA, la vraie variable de toute cette industrie reste le prix du token.

Le meilleur réglage n’est pas max. C’est celui que vous avez mesuré.