Votre agent renvoie les mêmes 40 000 jetons d'invite système, de définitions d'outils et de documents de politique à chaque appel. Au prix d'entrée de Claude Opus 5.5 de 4 $ par million de jetons, ce préfixe coûte 0,16 $ chaque fois qu'il est transféré, qu'un seul octet ait changé ou non depuis la dernière requête.
La mise en cache des invites est la solution, et Anthropic l'a tarifée de manière agressive sur Opus 5.5. Une lecture mise en cache coûte 0,20 $ par million de jetons contre 4,00 $ pour une entrée fraîche, soit une réduction de 95 %. Mais une écriture en cache coûte 5,00 $ par million, ce qui est plus cher que l'envoi des jetons non mis en cache. La mise en cache n'est donc pas de l'argent gratuit. C'est un pari sur la réutilisation du préfixe, et ce pari a un point de rentabilité précis que presque personne ne calcule avant de l'activer.
Cet article détaille ce calcul. En bref : sur un seul préfixe, vous atteignez le seuil de rentabilité après 1,26 appel, et en régime permanent, vous l'atteignez avec un taux de réussite du cache d'environ 21 %. En dessous de cela, la mise en cache vous coûte de l'argent.
L'ampleur mérite d'être mentionnée en premier. OpenAI a révélé lors de son propre lancement que son chercheur médian dépense plus de 600 $ par jour pour des agents de codage, le 90e centile dépassant 7 000 $ par jour. À ce volume, une différence de 20 points de pourcentage du taux de succès représente un salaire. Pour une vue d'ensemble des prix sur les trois lancements de septembre, consultez notre analyse de la guerre des prix des modèles de septembre 2026.
Les trois taux qui décident de tout
| Type de jeton | Taux de Claude Opus 5.5 par million | Par rapport à l'entrée fraîche |
|---|---|---|
| Entrée fraîche | $4.00 | base |
| Écriture en cache | $5.00 | 1,00 $ de prime |
| Lecture en cache | $0.20 | 3,80 $ d'économie |
| Sortie | $20.00 | la mise en cache n'y touche pas |
Deux faits ressortent directement de ce tableau. Écrire un préfixe dans le cache vous coûte 1,00 $ par million de plus que de ne pas le mettre en cache du tout. Chaque lecture ultérieure de ce préfixe vous fait économiser 3,80 $ par million. La tarification de la sortie ne change jamais, donc un agent qui émet de longues réponses à partir d'une courte invite a peu à gagner ici, tandis qu'un agent qui lit un grand contexte stable et renvoie un verdict court a beaucoup à gagner.
La fiche technique complète, incluant la fenêtre contextuelle de 1 000 000 de jetons et la sortie maximale de 128 000 jetons, se trouve dans qu'est-ce que Claude Opus 5.5.
Le seuil de rentabilité est de 1,26 appel, pas de deux
Prenez un préfixe d'exactement un million de jetons et N appels qui le partagent, une écriture et N moins une lectures.
uncached: N * $4.00
cached: $5.00 + (N - 1) * $0.20
4.00N = 5.00 + 0.20(N - 1)
3.80N = 4.80
N = 1.26
Vous avez besoin de 1,26 appel pour rembourser la prime d'écriture. Étant donné que les appels se font en nombres entiers, cela signifie : si le préfixe est relu ne serait-ce qu'une seule fois, la mise en cache était la bonne décision. Deux appels vous placent déjà 35 % en avance.
| Appels partageant une écriture | Coût non mis en cache par million de préfixes | Coût mis en cache | Économie |
|---|---|---|---|
| 1 | $4.00 | $5.00 | 25 % plus cher |
| 2 | $8.00 | $5.20 | 35 % |
| 5 | $20.00 | $5.80 | 71 % |
| 10 | $40.00 | $6.80 | 83 % |
| 100 | $400.00 | $24.80 | 94 % |
Ce tableau suppose une écriture et une réutilisation parfaite par la suite. Les systèmes réels sont plus complexes, c'est là qu'intervient le deuxième calcul.
En régime permanent, le seul chiffre qui compte est le taux de réussite
Sur une journée de trafic, vous n'écrivez pas qu'une seule fois. Les caches expirent, les préfixes sont modifiés, de nouveaux locataires arrivent. Soit h la fraction de vos jetons de préfixe servis depuis le cache. Un échec de cache est facturé comme une écriture, une réussite comme une lecture :
effective cost per 1M prefix tokens = $5.00 * (1 - h) + $0.20 * h
= $5.00 - $4.80h
break-even against $4.00 uncached: h = 1.00 / 4.80 = 20.8%
Vingt et un pour cent est le chiffre à retenir. Si moins d'environ un sur cinq de vos jetons de préfixe sont servis à partir du cache, l'activation de la mise en cache a fait augmenter votre facture.
| Taux de réussite du cache | Coût effectif par million de préfixes | Par rapport à 4,00 $ non mis en cache |
|---|---|---|
| 0% | $5.00 | 25 % plus cher |
| 20.8% | $4.00 | seuil de rentabilité |
| 50% | $2.60 | 35 % moins cher |
| 75% | $1.40 | 65 % moins cher |
| 90% | $0.68 | 83 % moins cher |
| 95% | $0.44 | 89 % moins cher |
| 99% | $0.25 | 94 % moins cher |
| 100% | $0.20 | 95 % moins cher |
Les deux tableaux représentent la même équation vue sous différents angles, puisque une écriture pour N appels correspond à un taux de réussite de (N-1)/N. Dix appels par écriture donnent un taux de réussite de 90 % et les deux tableaux indiquent 83 %.
Trois formes de requêtes, détaillées
Forme 1 : agent haute fréquence, petit préfixe
Un agent de triage de support avec un préfixe de 40 000 jetons, un tour utilisateur variable de 800 jetons, 600 jetons de sortie, 10 000 appels par jour. Supposons des écritures sur 3 % des appels, soit un taux de réussite de 97 %.
| Non mis en cache | Mis en cache | |
|---|---|---|
| Préfixe, 400M jetons/jour | $1,600.00 | $137.60 |
| Tour variable, 8M jetons/jour | $32.00 | $32.00 |
| Total d'entrée par jour | $1,632.00 | $169.60 |
C'est 89,6 % de réduction sur la ligne d'entrée, soit environ 1 462 $ par jour, ou 43 800 $ par mois. La sortie reste à 120 $ par jour de toute façon. Notez que le préfixe n'est que de 40 000 jetons. La mise en cache est rentable ici en raison de la fréquence, et non de la taille.
Forme 2 : passage unique sur un contexte de 1M
Un million de jetons en entrée, une réponse en sortie, jamais réutilisée. Non mis en cache, cet appel coûte 4,00 $ d'entrée. Mis en cache, il coûte 5,00 $, car vous avez payé pour écrire un préfixe que personne n'a lu. Traitez 500 documents par jour selon ce modèle et la mise en cache vous coûte 500 $ supplémentaires par jour pour rien.
C'est la forme que les gens se trompent le plus souvent, car le contexte est énorme et l'instinct est que les contextes énormes ont évidemment besoin de mise en cache. La taille est sans importance. La réutilisation est la seule variable.
Forme 3 : longue session d'agent sur une fenêtre de 1M
Prenez maintenant le même contexte d'un million de jetons et faites-le relire par un agent sur 200 tours, ce qui correspond exactement à ce à quoi ressemble une boucle de tâche de 18 heures.
| Coût | |
|---|---|
| Non mis en cache, 200 x 4,00 $ | $800.00 |
| Mis en cache, 1 écriture + 199 lectures | $44.80 |
| Mis en cache, 5 écritures + 195 lectures | $64.00 |
Même si le cache devient froid quatre fois en milieu de session et que vous payez cinq écritures complètes, vous êtes toujours 92 % en dessous de la facture non mise en cache. Les longues sessions sont l'endroit où le taux de 0,20 $ gagne sa réputation.
L'erreur coûteuse : mettre en cache la partie qui change
Considérez 5 000 documents de 60 000 jetons chacun, résumés une seule fois derrière un en-tête d'instruction partagé de 6 000 jetons.
| Stratégie | Coût d'entrée |
|---|---|
| Pas de mise en cache du tout | $1,320 |
| Mettre en cache la requête entière, y compris chaque document | $1,650 |
| Mettre en cache seulement l'en-tête de 6 000 jetons | $1,206 |
Mettre en cache la mauvaise limite est 25 % plus cher que de ne pas mettre en cache. Mettre en cache la bonne est 9 % plus avantageux. Même fonctionnalité, mêmes tarifs, un écart de 444 $ entièrement décidé par l'endroit où le préfixe mis en cache se termine.
La règle qui en découle : mettez en cache la plus longue séquence de début d'octets identique entre les appels, et pas un octet de plus. Si un horodatage, un ID de requête ou un document par requête se trouve à l'intérieur de votre préfixe mis en cache, votre taux de réussite s'effondre à zéro et chaque appel est facturé 5,00 $ au lieu de 4,00 $. Les mécanismes généraux de correspondance de préfixe sont couverts dans notre guide de mise en cache des invites.
95 % est une asymptote, pas une réduction que vous recevez
Le chiffre principal est que les lectures mises en cache coûtent 5 % de l'entrée fraîche. Vous ne paierez jamais réellement 5 %, car vous avez toujours payé pour au moins une écriture. À 100 appels par écriture, vous êtes à 94 %. À 10 appels par écriture, vous êtes à 83 %. À 2 appels, vous êtes à 35 %.
Basez votre budget sur le tableau des taux de réussite, pas sur le titre. Une équipe financière qui modélise une économie de 95 % et observe 83 % conclura que la fonctionnalité est défectueuse alors qu'elle fonctionne exactement comme prévu par les prix.
Ce que le matériel de lancement ne vous dit pas
Trois éléments de ce calcul ne figurent pas dans le matériel de lancement d'Opus 5.5 d'Anthropic, et les deviner serait le moyen le plus rapide de se tromper dans un budget :
- Durée de vie du cache. La durée pendant laquelle un préfixe écrit reste "chaud" détermine directement votre taux de réussite en régime permanent. Chaque exemple travaillé ci-dessus considère h comme une hypothèse constante, et non comme une garantie de la plateforme.
- Longueur minimale du préfixe cacheable. Les plateformes refusent généralement de mettre en cache des préfixes très courts. Si le vôtre est en dessous du seuil, votre taux de réussite effectif est de zéro, quelle que soit la stabilité des octets.
- Portée du cache. Le fait qu'un préfixe "chaud" soit partagé entre des clés API, des espaces de travail ou des régions modifie considérablement le nombre d'écritures dans un déploiement multi-tenant.
Vérifiez ces trois points sur la page de tarification du fournisseur avant de vous engager sur un chiffre. Les taux de cet article sont publiés. Ces trois-là ne le sont pas.
Vérifiez que le cache fonctionne réellement
Le mode de défaillance est silencieux. Rien ne déclenche d'erreur lorsqu'un préfixe devient froid. Quelqu'un ajoute un ID de débogage au message système, le taux de réussite chute de 97 % à 0, et le seul signal est une ligne sur une facture trois semaines plus tard.
L'API Messages signale la répartition à chaque réponse :
"usage": {
"input_tokens": 812,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 40960,
"output_tokens": 604
}
Lors du premier appel, `cache_creation_input_tokens` transporte le préfixe. À chaque appel suivant, ce champ doit être à 0 et `cache_read_input_tokens` doit transporter la même charge. Enregistrez la requête une fois dans Apidog, exécutez-la deux fois, et observez quel champ bouge.
Transformez ensuite cette observation en une assertion pour qu'elle ne puisse pas régresser silencieusement. Un scénario de test Apidog qui envoie la requête deux fois et affirme `cache_read_input_tokens > 40000` sur la deuxième réponse échouera en CI dès qu'un coéquipier rendra le préfixe non déterministe. C'est un test d'une ligne qui se dresse entre vous et une augmentation de 25x de la facturation des préfixes, et c'est la chose la plus rentable de cet article.
Où GPT-6 se situe sur les mêmes calculs
GPT-6 Sol affiche l'entrée à 2,00 $ par million avec une réduction de 90 % sur les lectures mises en cache, ce qui place une lecture mise en cache à 0,20 $ par million, le même chiffre que Opus 5.5. GPT-6 Luna à 0,10 $ par million d'entrée correspond à 0,01 $ par million mis en cache.
La différence est ce que nous pouvons calculer. Le matériel de lancement d'OpenAI n'indique pas de taux d'écriture en cache, de sorte que le taux de réutilisation seuil de rentabilité pour GPT-6 ne peut pas être dérivé de la même manière que pour Opus 5.5. Le fait qu'Anthropic publie un prix d'écriture explicite de 5,00 $ est ce qui rend le chiffre de 21 % calculable. Le reste de la publication d'OpenAI sur la mise en cache, y compris les modifications d'effort de préservation du cache et les nouveaux outils de diagnostic, se trouve dans notre article sur la mise en cache des invites de GPT-6.
En résumé
La mise en cache des invites sur Claude Opus 5.5 est une question arithmétique : plus d'un cinquième de vos jetons de préfixe reviendront-ils "chauds" ? Si oui, activez-la et attendez-vous à 83 % à 94 % de réduction sur la ligne d'entrée plutôt que les 95 % annoncés. Si votre charge de travail consiste en des passages uniques sur des documents uniques, désactivez-la et économisez la prime d'écriture de 1,00 $ par million. Et quel que soit votre choix, assurez-vous de `cache_read_input_tokens` en CI, car une régression du cache ne s'annonce jamais.