Claude Fable 5.1 : quand le cache et le traitement par lots réduisent le coût par tâche — et quand ils ne font que déplacer la facture

Périmètre : comparer les modalités sans transposer les prix d’un canal à l’autre

Claude Fable 5.1 est proposé sur plusieurs canaux, notamment Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry et Claude Platform on AWS. La comparaison de ce guide se limite aux règles et aux prix documentés pour la plateforme directe d’Anthropic. Il n’est pas valable de reporter ces tarifs sur Amazon Bedrock ou sur un autre fournisseur cloud : la documentation tarifaire indique que Bedrock et Google Cloud appliquent des tarifs régionaux indépendants.

La documentation du modèle situe la sortie de Claude Fable 5.1 au 1er septembre 2026, annonce une fenêtre de contexte d’un million de tokens et une sortie maximale de 128 000 tokens. Ces limites peuvent influencer à la fois la conception des requêtes et la facture : un contexte qui tient théoriquement dans la fenêtre ne peut pas nécessairement être envoyé à la fréquence, avec la concurrence ou dans le délai requis.

L’objectif n’est donc pas d’affirmer qu’une modalité est universellement moins chère. Il consiste à construire un calcul comparable pour une charge donnée et à mesurer le coût d’une tâche qui se termine correctement. Ce coût inclut les tokens, les nouvelles tentatives, la validation, la récupération après échec et, lorsque le produit l’exige, le coût opérationnel de l’attente d’une réponse asynchrone. Une facture de tokens plus faible ne prouve pas, à elle seule, un coût total inférieur, un meilleur résultat ou moins de revue humaine.

Ce qui est facturé dans Claude Fable 5.1

Sur la plateforme directe, la table propre à Claude Fable 5.1 indique 10 USD par million de tokens d’entrée standard et 50 USD par million de tokens de sortie. Une écriture de cache d’une durée de cinq minutes coûte 12,50 USD par million de tokens ; une écriture d’une heure coûte 20 USD par million. Les lectures de cache coûtent 0,25 USD par million de tokens. Ces montants proviennent de la documentation fournie et doivent être vérifiés de nouveau avant la mise en place d’un budget, car les prix et les conditions commerciales peuvent évoluer.

Une écriture de cache correspond au traitement initial du préfixe du prompt rendu disponible pour réutilisation. Une lecture intervient lorsqu’une requête ultérieure correspond à ce préfixe stocké et peut l’utiliser. La durée de vie commence lorsque le cache est créé. Les durées de cinq minutes et d’une heure ne constituent pas une réservation de capacité et ne garantissent pas à elles seules une réutilisation : si l’appel suivant arrive trop tard, si le préfixe pertinent change ou si aucun succès de cache n’est obtenu, l’économie attendue ne se concrétise pas.

La sortie ne bénéficie pas pour autant d’une réduction liée au cache. Un agent qui produit de longues explications, des correctifs ou des rapports peut conserver une facture élevée, même avec un excellent taux de succès du cache. Il faut aussi comptabiliser la partie dynamique du prompt : seul le préfixe effectivement réutilisé peut profiter de la lecture ; les instructions ou le contexte ajoutés ensuite restent facturés comme entrée standard.

Batch API traite les requêtes de manière asynchrone et la documentation indique une réduction de 50 % par rapport aux prix standard. Le cache et Batch peuvent cumuler leurs réductions. Toutefois, une réduction tarifaire ne fait pas de Batch un remplacement d’une voie interactive : le lot possède un délai d’expiration et une discipline opérationnelle propres. L’équipe doit vérifier si le travail peut attendre et combien coûte le renvoi, la correction ou l’investigation des éléments qui ne se terminent pas comme prévu.

L’unité utile : le coût par tâche correctement achevée

Le coût par appel est un indicateur incomplet. Une tâche peut demander plusieurs tours, un contrôle automatique, une vérification d’un résultat structuré, un appel de récupération ou une nouvelle tentative après une limite de capacité. En outre, une réponse reçue après un délai qui ne sert plus le produit peut avoir peu de valeur opérationnelle, même si elle a été peu coûteuse.

Définissez une tâche correctement achevée avant de comparer les modalités. Par exemple, pour un agent d’ingénierie, il peut s’agir d’une proposition qui réussit les tests et la validation de politique ; pour un assistant documentaire, d’une réponse qui respecte le format et dispose de preuves récupérables ; pour une file nocturne, d’un enregistrement traité avant l’heure de livraison et accepté par les contrôles ultérieurs. Enregistrez séparément les erreurs techniques, les résultats non valides et les travaux nécessitant une intervention humaine.

Sur une fenêtre d’analyse, une mesure pratique est le coût total des requêtes, nouvelles tentatives, validations et récupérations, divisé par les tâches acceptées. Si l’objectif est d’isoler le coût du modèle, excluez les salaires et les systèmes externes, mais ne masquez ni les nouvelles tentatives ni les appels de correction. Si l’objectif est de choisir une architecture produit, ajoutez ces composantes ainsi que le coût du non-respect du délai au moyen d’une hypothèse explicite et révisable.

Modèle paramétrable pour appel standard, cache et lots

Utilisez dans une feuille de calcul des montants en dollars par token, et non par million : entrée standard e = 10/1 000 000 ; sortie s = 50/1 000 000 ; écriture de cinq minutes w5 = 12,50/1 000 000 ; écriture d’une heure w60 = 20/1 000 000 ; lecture r = 0,25/1 000 000. Pour chaque groupe de requêtes ayant le même préfixe réutilisable, définissez P comme le nombre de tokens du préfixe, D comme l’entrée dynamique moyenne par appel, O comme la sortie moyenne et N comme le nombre d’appels effectués avant l’expiration de l’entrée de cache.

Sans cache, le coût du groupe est N multiplié par P plus D, le tout multiplié par e, plus N multiplié par O puis par s. Avec un cache de cinq minutes, le coût approximatif est P multiplié par w5, plus N multiplié par P puis par r, plus N multiplié par D puis par e, plus N multiplié par O puis par s. Avec un cache d’une heure, remplacez w5 par w60. Ces formules supposent un succès de lecture pour tous les appels ultérieurs et une seule écriture initiale ; elles décrivent un cas idéalisé, non une garantie.

Pour intégrer un taux de succès observé H, remplacez N par H multiplié par N dans le terme de lecture et ajoutez, pour les appels sans succès, le coût d’entrée correspondant. L’implémentation exacte doit suivre la manière dont votre application regroupe les préfixes et dont l’API signale l’usage. Il est également préférable de séparer les préfixes distincts : moyenner un corpus très réutilisé avec des requêtes uniques peut cacher le fait que le cache ne fonctionne que pour une fraction de la charge.

Pour Batch, appliquez la réduction documentée de 50 % aux composantes applicables du modèle de votre canal direct, puis ajoutez le coût des renvois et de la validation. Ne supposez pas que tous les travaux d’une file nocturne sont équivalents : ceux qui expirent, requièrent une priorité ou demandent des corrections peuvent finir sur une autre voie, avec un autre tarif.

Trois flux reproductibles pour mesurer le recouvrement réel

Premier cas : l’agent d’ingénierie. Séparez le prompt entre des instructions et politiques stables, un état de dépôt qui évolue à une cadence connue, et la demande ponctuelle de l’utilisateur. Ne supposez pas que l’intégralité du dépôt doit ou peut figurer dans le préfixe. Mesurez combien de tokens du bloc stable sont répétés à l’identique, combien d’actions ont lieu dans le TTL et combien de tours rompent la correspondance à cause de changements d’état. Enregistrez aussi les nouvelles tentatives causées par les validations d’outils, les tests échoués ou les réponses dépassant le budget de sortie.

Deuxième cas : l’assistant qui répond sur un corpus stable. Un corpus commun et des instructions fixes sont des candidats naturels au cache, mais l’analyse doit distinguer le corpus complet envoyé, l’extrait récupéré pour chaque question et l’historique conversationnel. Si chaque question utilise une sélection documentaire différente, le volume apparemment stable peut avoir peu de recouvrement exact. Construisez des groupes par version de corpus et par préfixe, et non un taux global de succès qui mélangerait des comportements incompatibles.

Troisième cas : l’analyse nocturne. Regroupez les travaux qui ne requièrent pas de réponse interactive et mesurez la part qui respecte son heure de livraison avec Batch. Comparez l’économie facturée au coût des exceptions : éléments urgents sortis du lot, renvois, erreurs de format et travaux qui expirent. Si le flux exige un résultat avant de lancer des processus ultérieurs, le temps passé en file fait partie de son coût opérationnel, même s’il n’apparaît pas comme un token.

Dans les trois cas, le compteur de tokens d’usage est la source permettant de reconstituer ce qui est facturé par modalité. La documentation sur les limites explique que plusieurs catégories de tokens comptent dans le budget de tokens d’entrée par minute et fournit une formule pour reconstituer l’entrée totale à partir des données d’usage. Ces informations servent à anticiper la capacité autant qu’à détecter pourquoi une stratégie peu coûteuse sur le papier entraîne des attentes ou de nouvelles tentatives.

Limites, délais et conditions qui modifient le choix

La capacité disponible peut invalider une décision fondée uniquement sur le prix. La documentation de l’API distingue les limites de requêtes par minute, de tokens d’entrée par minute et de tokens de sortie par minute. Les tokens associés au cache comptent dans ces calculs. Une conception qui concentre de nombreuses écritures ou de grandes entrées peut rencontrer les limites, accroître sa propre file ou provoquer des nouvelles tentatives ; dans ce cas, le coût observé par tâche peut augmenter alors même que le tarif théorique est faible.

Batch a également des limites de file documentées et un délai d’expiration. Avant de migrer une file, mesurez sa distribution d’ancienneté et déterminez quelle part peut attendre sans affecter les dépendances. Établissez une voie d’exception pour les travaux urgents et budgétez-la séparément. Une file unique qui mélange des travaux d’urgence différente complique l’attribution de l’économie comme celle du non-respect des délais.

Les succès de cache sont fournis au mieux et dépendent du comportement du trafic, selon la documentation de Batch. Traitez-les comme un résultat mesurable, et non comme une capacité contractuelle. Concevez l’application de manière à ce que l’absence de succès reste fonctionnellement correcte et afin que le budget couvre le scénario de réutilisation raisonnablement le plus faible.

La résidence des données peut introduire un multiplicateur de prix selon les règles commerciales documentées. Si ce point est pertinent dans votre environnement, intégrez-le à tous les termes de la feuille de calcul avant de comparer les alternatives. Il ne faut pas l’appliquer sélectivement à une modalité pour la rendre artificiellement plus attrayante.

Conclusion : une économie vérifiable exige segmentation et contrôle des résultats

Claude Fable 5.1 peut réduire sensiblement la part d’entrée pour les flux qui réutilisent un préfixe important, stable et lu plusieurs fois pendant son TTL. Le cache de cinq minutes constitue souvent le premier point de comparaison lorsque les requêtes sont concentrées ; celui d’une heure exige de démontrer que son écriture plus coûteuse évite suffisamment d’écritures ou permet une réutilisation qui serait autrement perdue. Batch mérite une évaluation distincte pour le travail différable, et non la conversion automatique de toute la charge.

La décision robuste ne part pas d’un prix unique par million de tokens. Elle part de groupes de requêtes réels, des champs d’usage de l’API, du taux de succès, du délai avant réutilisation, de la sortie, des nouvelles tentatives, des travaux acceptés et du délai. Avec ces données, l’organisation peut fixer un seuil explicite : adopter une modalité seulement si elle réduit le coût par tâche correcte tout en maintenant le service dans ses objectifs opérationnels.

Enfin, une réduction de facture ne permet pas de conclure que le modèle répond avec une meilleure qualité, que l’utilisateur perçoit une latence moindre ou que la revue humaine diminue. Ces variables doivent être mesurées au moyen d’évaluations et de métriques distinctes. Elle ne permet pas non plus d’inférer des prix équivalents sur Bedrock ou d’autres canaux cloud. L’incertitude doit rester visible dans le tableau de bord et dans toute décision financière fondée sur ce guide.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.