Rétrograder est le dernier levier, pas le premier
Passer d'Opus 4.8 à Sonnet 4.6 réduit les prix par token de 40 %, et remet en jeu chaque réponse que donne votre produit. C'est le compromis vers lequel la plupart des équipes se tournent en premier, et il est généralement prématuré, car deux remises plus importantes figurent déjà sur la grille tarifaire du modèle que vous utilisez aujourd'hui : le prompt caching lit le contexte répété à environ un dixième du prix de l'entrée, et la Batch API applique une réduction forfaitaire de moitié sur tout ce qui peut attendre. Ni l'une ni l'autre ne change la moindre réponse. Elles se cumulent. Et si vous les appliquez d'abord, la rétrogradation que vous appréhendiez cesse souvent d'être nécessaire.
Pour garder des chiffres honnêtes, nous continuons de travailler sur le même patient : le chatbot de support dont nous avons disséqué la facture de $1,460 dans la première partie. Quatre leviers, appliqués dans l'ordre, sans changement de modèle pour le trafic qui compte :
| Élément | Montant |
|---|---|
| Facture de la partie 1 | $1,460 |
| + prompt caching | $1,332 |
| + routage | $799 |
| + réduction de la sortie | $673 |
Le chatbot de la partie 1, quatre leviers plus tard
Opus 4.8, 10,000 conversations / mois · leviers appliqués de gauche à droite
Modélisé d'après les hypothèses de la partie 1 (10,000 conversations de quatre tours ; un bloc système de 1,500 tokens ; questions de 500 tokens, réponses de 700 tokens ; Opus 4.8 à $5 / $25 par 1M). La mise en cache utilise des fenêtres de 5 minutes et respecte le préfixe minimal cachable de 4,096 tokens d'Opus 4.8, si bien qu'elle ne commence à payer qu'à partir du tour 3. Le routage envoie la moitié la plus facile des conversations vers Haiku 4.5 ($1 / $5) et change ces réponses. La réduction diminue les réponses de ~30% avec l'entrée inchangée, ce qui garde l'estimation prudente.
Levier 1 : le prompt caching, la remise cachée dans votre contexte répété
La première partie a montré que le contexte renvoyé est le plus gros poste d'une facture conversationnelle : le même prompt système et le même historique grandissant, refacturés à chaque tour. La mise en cache s'attaque précisément à ce poste. Vous marquez le préfixe stable de votre requête, payez une surcharge unique pour l'écrire (1.25x le prix de l'entrée sur le palier de 5 minutes, 2x sur le palier d'1 heure), et chaque requête ultérieure qui commence par les mêmes octets le relit à environ un dixième du prix.
| Palier de cache | Surcharge d'écriture | Prix de lecture | Devient rentable |
|---|---|---|---|
| 5 minutes | 1.25x le prix de l'entrée, une fois | ~0.1x le prix de l'entrée | À la 2e utilisation du préfixe |
| 1 heure | 2x le prix de l'entrée, une fois | ~0.1x le prix de l'entrée | À la 3e utilisation |
Deux réserves honnêtes avant d'inscrire 90 % au crayon. D'abord, la remise s'applique à la portion mise en cache, pas à la facture : notre chatbot passe de $1,460 à $1,332, soit une baisse de 9 %, parce que ses conversations sont courtes. Sur Opus 4.8, rien en dessous de 4,096 tokens ne peut être mis en cache, si bien qu'une conversation de quatre tours ne franchit ce seuil qu'au troisième tour ; les tours les plus profonds et les plus coûteux profitent de la remise, les premiers non. Ensuite, la surcharge d'écriture signifie que mettre en cache un préfixe que personne ne réutilise revient à payer plus cher. La mise en cache brille lorsque le contexte est volumineux ou que les conversations sont longues, c'est-à-dire précisément là où la première partie situait la douleur.
Levier 2 : la Batch API, une réduction forfaitaire de moitié sur tout ce qui peut attendre
La Batch API est la remise la plus simple du catalogue : soumettez le travail de façon asynchrone, récupérez les résultats en quelques minutes à quelques heures, payez 50 % du prix standard sur chaque token du job, tokens en cache compris. Il n'y a aucun compromis sur la qualité ; c'est le même modèle produisant les mêmes réponses, simplement pas pendant que quelqu'un regarde tourner un indicateur de chargement.
Le piège tient à la définition de « ce qui peut attendre ». Un client en pleine conversation ne le peut pas, si bien que le trafic en direct de notre chatbot ne tire rien de ce levier, et c'est pourquoi il n'apparaît pas dans la cascade ci-dessus. Mais presque tout produit d'IA porte une charge de travail de l'ombre qui, elle, peut attendre : les résumés nocturnes de ces conversations de support, la classification en masse, la génération de rapports, les pipelines de contenu. Chiffrez-les séparément et traitez-les par lots par défaut ; payer le tarif en direct pour un travail que personne n'attend est la fuite la plus discrète de la plupart des factures.
Levier 3 : router selon la difficulté, pas par défaut
Toutes les conversations n'ont pas besoin de votre meilleur modèle. Les réinitialisations de mot de passe et les questions sur le statut d'une livraison n'exigent pas Opus 4.8 ; elles exigent une recherche correcte et une phrase polie, ce que Haiku 4.5 fournit à $1 / $5 par million de tokens, cinq fois moins cher par token. Dans notre modèle, envoyer la moitié la plus facile des conversations vers Haiku fait passer la facture de $1,332 à $799, la plus grande marche de la cascade.
Traitez ce levier différemment des deux précédents, car c'est le premier qui change les sorties. La mise en cache et le traitement par lots renvoient des réponses identiques ; le routage confie à la part routée un modèle différent. La discipline qui le garde sûr : classez de façon prudente, ne routez que le trafic qu'un modèle moins cher réussit de façon prouvée sur votre propre jeu de tests, et conservez une voie d'escalade vers le grand modèle dès que la conversation cesse d'être facile.
Levier 4 : réduire du côté de la sortie, car elle est facturée cinq fois l'entrée
Chaque modèle Claude facture les tokens de sortie exactement cinq fois le prix de l'entrée, si bien que la longueur de vos réponses est une décision tarifaire, que vous l'ayez prise délibérément ou non. Les réponses de support gonflées de questions reformulées et de formules de politesse finales coûtent de l'argent bien réel à grande échelle. Demander à l'assistant de répondre sous la forme la plus courte qui résout entièrement le ticket réduit nos réponses modélisées d'environ 30 % et fait passer la facture de $799 à $673, et dans la famille Opus, le réglage d'effort est le même bouton un cran au-dessus : baissez-le pour le trafic de routine et le modèle dépense moins de tokens de raisonnement pour arriver au même point.
La limite ici n'est pas technique mais humaine : coupez au-delà du point d'utilité et les réponses commencent à paraître sèches, ce qui ressurgit plus tard sous forme de contacts répétés. Coupez le remplissage, gardez le fond.
D'où viennent réellement les 50 à 90 %
Empilez les leviers sur notre chatbot et la facture atterrit à $673, 54 % en dessous de là où la première partie l'avait laissée, la moitié difficile du trafic restant sur exactement le même modèle produisant exactement les mêmes réponses. Que votre propre chiffre se rapproche plutôt de 50 ou de 90 dépend de deux propriétés de votre charge de travail : quelle part de votre entrée est du contexte répété, et quelle part de votre travail peut attendre.
| Charge de travail | Économisé |
|---|---|
| Chatbot de support en direct | -54% |
| Pipeline documentaire nocturne | -64% |
| Agent asynchrone, contexte partagé lourd | -88% |
L'ampleur de la coupe dépend de la forme
Part de la facture mensuelle économisée, modélisée par charge de travail
Trois charges de travail modélisées, mêmes modèles d'un bout à l'autre. Chatbot : les hypothèses de la partie 1 plus les trois leviers ci-dessus ($1,460 à $673). Pipeline : 60,000 documents par mois sur Sonnet 4.6 ($3 / $15), un bloc d'instructions partagé de 2,500 tokens (mis en cache) plus un document de 3,000 tokens en entrée et 500 tokens en sortie, exécuté la nuit via la Batch API ($1,440 à $518). Agent : 100,000 appels asynchrones par mois sur Opus 4.8 avec un pack de contexte partagé de 10,000 tokens maintenu au chaud, 200 en entrée / 300 en sortie par appel, traité par lots ($5,850 à $675). Les accès au cache à l'intérieur des exécutions Batch relèvent du best effort, considérez donc les extrémités droites comme des plafonds.
Un chatbot en direct se situe à l'extrémité modeste, parce que les conversations courtes se mettent en cache tardivement et qu'aucun trafic en direct ne peut être traité par lots. Un pipeline documentaire nocturne fait mieux : son bloc d'instructions se met parfaitement en cache et chaque token du job bénéficie de la remise batch. Et l'agent asynchrone avec un grand pack de contexte partagé est justement la forme pour laquelle ces remises ont été conçues ; neuf dixièmes de son entrée se lisent depuis le cache et l'ensemble de l'exécution passe par lots, si bien que 88 % de la facture disparaissent tout simplement.
Le test d'éligibilité
Avant de toucher à l'identifiant du modèle, parcourez une fois votre charge de travail à l'aide de ce tableau.
| Levier | Ce que votre charge de travail exige | Économie réaliste | À surveiller |
|---|---|---|---|
| Prompt caching | Un préfixe stable au-dessus du minimum du modèle, réutilisé dans la fenêtre de cache | ~90% de réduction sur la portion répétée | La surcharge d'écriture se retourne contre vous en dessous de 2-3 réutilisations ; les conversations courtes commencent à se mettre en cache tard |
| Batch API | Une tolérance à une latence de quelques minutes à quelques heures | -50% forfaitaire sur l'ensemble du job | Jamais pour un utilisateur qui attend ; les accès au cache à l'intérieur des lots relèvent du best effort |
| Routage selon la difficulté | Une part du trafic qu'un modèle moins cher gère de façon prouvée | Jusqu'à 5x sur la part routée | Modifie les sorties ; testez d'abord la qualité et conservez une voie d'escalade |
| Réduction de la sortie + effort | Factures à forte sortie (la sortie est facturée 5x l'entrée) | Proportionnelle à la réduction | Trop agressif donne des réponses sèches et incomplètes |
Menez l'audit dans cet ordre : la mise en cache d'abord si un contexte se répète, traitez par lots tout ce qu'aucun utilisateur n'attend, réduisez la sortie que de toute façon vous ne lisiez jamais, puis routez la part dont la simplicité est prouvée. Ce n'est qu'une fois les quatre en place que la question de la rétrogradation mérite une réponse, et à ce stade c'est une bien plus petite question. Et si le chiffre auquel vous aboutissez vous paraît encore trop élevé au regard de ce que la fonctionnalité rapporte, la question n'est plus comment la faire tourner moins cher ; c'est de savoir si elle devrait exister, ce à quoi sert précisément la troisième partie.
