Fable 5 : la qualité a un prix

Depuis quelques mois, un changement discret mais majeur traverse les outils d'IA : la performance brute ne suffit plus. Il faut désormais regarder combien elle coûte.

Claude Fable 5 illustre parfaitement cette tension. Le modèle est présenté comme l'un des plus avancés pour les tâches longues, le raisonnement complexe, le code et les agents. Il sait gérer des workflows ambitieux, suivre des instructions sur de longues sessions et travailler avec beaucoup de contexte.

Mais cette puissance a un prix : Fable 5 peut consommer bien plus de tokens que des modèles plus légers du marché. Et dans un monde où l'IA est de plus en plus facturée à l'usage, ce détail devient un sujet stratégique.

Les meilleurs modèles réfléchissent plus longtemps

Pour comprendre le coût de Fable 5, il faut revenir à une idée simple : tous les tokens ne proviennent pas uniquement de ce que l'utilisateur écrit ou de ce que le modèle répond.

Quand un modèle avancé s'attaque à une tâche complexe, il consomme aussi des tokens pour analyser, planifier, utiliser des outils, lire du contexte, exécuter des étapes intermédiaires et corriger ses propres erreurs.

C'est particulièrement vrai des modèles orientés agent. Un chatbot classique répond à une question. Un agent, lui, explore un dépôt, lit plusieurs fichiers, tente une correction, lance des tests, interprète les erreurs, révise son plan, puis recommence. Chaque étape consomme des tokens.

Or Fable 5 est précisément conçu pour ce type de tâches longues. Il peut exceller sur des problèmes difficiles, mais aussi rester « en réflexion » bien plus longtemps qu'un modèle plus simple. Résultat : une tâche qui paraît courte côté utilisateur peut devenir coûteuse en arrière-plan.

C'est là que le sujet devient intéressant. Un modèle plus intelligent peut parfois coûter moins cher s'il trouve vite la bonne réponse. Mais il peut aussi coûter beaucoup plus s'il explore trop, lit trop de contexte ou suranalyse une tâche simple.

Fable 5 et le paramètre « effort »

Autour de Fable 5, Anthropic introduit une logique importante : le contrôle de l'effort. Le paramètre « effort » permet d'ajuster la profondeur de raisonnement du modèle. Plus l'effort est élevé, plus le modèle peut passer de temps à analyser et à travailler. Utile pour une migration complexe, une investigation technique ou une tâche agentique longue ; inutilement coûteux pour une correction mineure, une reformulation ou une recherche simple.

Autrement dit, Fable 5 n'est pas qu'un modèle. C'est un moteur à plusieurs régimes.

Le hic, comme souvent, c'est que les utilisateurs veulent la meilleure qualité sans payer la complexité qui la rend possible. Position admirablement humaine : réclamer une Formule 1 pour aller chercher du pain, puis s'étonner de la facture d'essence.

Dans une équipe de développement, une nouvelle question surgit donc : faut-il vraiment dégainer le modèle le plus puissant pour chaque tâche ? La réponse est non. Pour relire un texte, classer une demande, expliquer un message d'erreur simple ou générer une documentation basique, un modèle plus léger suffit souvent. Pour analyser une architecture, corriger un bug retors ou piloter un agent sur un dépôt complexe, Fable 5 se justifie.

Le bon usage n'est donc pas « tout mettre sur le meilleur modèle ». C'est de choisir le niveau d'intelligence adapté à la tâche.

Pourquoi consomme-t-il autant ?

Il y a trois raisons principales.

La première est le contexte. Les modèles avancés servent souvent sur des tâches riches : beaucoup de fichiers, d'historique, de dépendances, d'instructions. Or tout ce contexte doit être lu, converti en tokens et traité.

La deuxième est le raisonnement. Plus un modèle analyse en profondeur, plus il consomme. Même invisible dans la réponse finale, ce raisonnement pèse sur le coût global.

La troisième est le fonctionnement agentique. Un agent ne répond pas d'un coup : il procède par boucle — lire, comprendre, agir, vérifier, corriger. Cette boucle est puissante, mais elle multiplie les appels, les outils, les lectures et les sorties intermédiaires.

Voilà pourquoi Fable 5 peut devenir cher sur des workflows de code. Il ne se contente pas de produire une fonction : il inspecte un projet, manipule des fichiers, suit une piste, l'abandonne, recommence et livre une solution plus robuste. Ce comportement est utile. Il est aussi coûteux.

Éviter la consommation inutile de tokens

Avec les modèles puissants, le risque ne tient pas qu'au prix par token. Il tient au token burn : la consommation inutile de tokens.

Un agent peut beaucoup consommer faute de direction. Il lit trop de fichiers, réclame trop de contexte, s'engage dans une mauvaise hypothèse, code avant de comprendre, corrige sans plan, puis recommence à plusieurs reprises.

Ce n'est pas forcément la faute du modèle. Souvent, c'est celle du workflow. Une demande vague comme « améliore cette fonctionnalité » oblige l'agent à deviner. Une demande claire comme « corrige ce bug dans ce module, sans changer l'API publique, en ajoutant un test de non-régression » réduit fortement l'espace d'exploration. Moins l'agent doit deviner, moins il gaspille.

Le brainstorming

À première vue, ajouter une étape de brainstorming semble paradoxal. Pourquoi faire réfléchir l'agent davantage si l'objectif est de réduire les tokens ? Parce qu'un bon brainstorming n'est pas une errance. C'est une courte phase de cadrage.

Dans un workflow de code, il sert à explorer rapidement plusieurs approches avant d'écrire. L'agent peut repérer les options possibles, les risques, les fichiers probablement concernés, les hypothèses à vérifier et les critères de succès.

Cette étape évite un travers classique : foncer sur une solution, modifier du code trop tôt, découvrir ensuite que l'approche était mauvaise, puis tout reprendre. Exactement comme dans le développement humain — sauf que l'humain appelle ça « expérience » après avoir cassé trois environnements.

Un plugin comme Superpowers, qui intègre une phase de brainstorming dans un workflow plus structuré, vise justement à éviter ces boucles inutiles. Il pousse l'agent à clarifier, concevoir, planifier, coder puis vérifier. L'idée n'est pas de faire parler l'IA davantage, mais de la faire agir dans le bon ordre.

L'importance d'un workflow structuré

Un agent consomme beaucoup quand il revient en arrière. Le coût vient rarement d'une seule réponse : il vient des itérations inutiles. Un workflow structuré réduit cette consommation de plusieurs façons :

• Il force la clarification. L'agent vérifie le besoin avant de produire du code, ce qui évite les corrections hors sujet.
• Il limite l'exploration. En identifiant les fichiers pertinents avant de lire tout le dépôt, il réduit les tokens d'entrée.
• Il produit un plan. Un plan précis permet d'exécuter plus directement, avec moins de tentatives ratées.
• Il vérifie le résultat. Tests et critères d'acceptation indiquent si la tâche est terminée, au lieu de modifier le code indéfiniment.

Le brainstorming n'a donc rien de magique. Il ne compresse pas les tokens : il réduit surtout le désordre. Et dans les agents de code, le désordre coûte cher.

Que retenir ?

Fable 5 pose une question plus large que son seul prix : comment utiliser les modèles puissants sans les laisser tout consommer ?

• Ne pas mobiliser le modèle le plus avancé pour les tâches simples. Les modèles plus légers suffisent souvent aux résumés, reformulations, classifications, petites corrections ou scripts simples.
• Cadrer les tâches. Plus une demande est précise, moins l'agent a besoin d'explorer.
• Limiter le contexte. Donner tout le dépôt à un modèle « au cas où » est rarement une bonne stratégie. Mieux vaut fournir les bons fichiers, les bons logs et les bonnes contraintes.
• Mesurer. Il faut suivre le coût par tâche réussie, pas seulement par requête. Une réponse chère peut être rentable si elle évite deux jours de travail ; une réponse bon marché peut être inutile si elle produit une mauvaise correction.
• Recourir aux workflows. Brainstorming, planification, test-driven development, validation humaine et vérification automatique ne sont pas des détails. Ce sont des garde-fous économiques.

Et dans un futur proche ?

Les modèles comme Fable 5 montrent que l'IA entre dans une phase plus mature. La question n'est plus seulement « quel modèle est le plus fort ? », mais « quel modèle, avec quel effort, sur quelle tâche, à quel coût ? »

Les entreprises qui exploiteront bien l'IA ne seront pas forcément celles qui auront accès au modèle le plus cher, mais celles qui sauront orchestrer plusieurs niveaux d'intelligence : un modèle léger pour les tâches simples, un modèle intermédiaire pour le travail courant, un modèle très puissant pour les problèmes vraiment complexes.

Fable 5 n'est donc pas qu'un progrès technique. C'est aussi un rappel économique : quand l'IA devient capable de travailler longtemps, elle devient aussi capable de dépenser longtemps.

La vraie compétence ne sera pas seulement de demander à l'IA d'en faire plus. Ce sera de lui apprendre à ne pas faire n'importe quoi avant de commencer.