La mise en cache des invites est une fonctionnalité puissante qui optimise votre utilisation de l’API en vous permettant de reprendre à partir de préfixes spécifiques dans vos invites. Cette approche réduit considérablement le temps de traitement et les coûts pour les tâches répétitives ou les invites avec des éléments cohérents. Voici un exemple de la façon d’implémenter la mise en cache des invites avec l’API Messages en utilisant un bloc cache_control :
curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": [
      {
        "type": "text",
        "text": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.\n"
      },
      {
        "type": "text",
        "text": "<the entire contents of Pride and Prejudice>",
        "cache_control": {"type": "ephemeral"}
      }
    ],
    "messages": [
      {
        "role": "user",
        "content": "Analyze the major themes in Pride and Prejudice."
      }
    ]
  }'

# Call the model again with the same inputs up to the cache checkpoint
curl https://api.anthropic.com/v1/messages # rest of input
JSON
{"cache_creation_input_tokens":188086,"cache_read_input_tokens":0,"input_tokens":21,"output_tokens":393}
{"cache_creation_input_tokens":0,"cache_read_input_tokens":188086,"input_tokens":21,"output_tokens":393}
Dans cet exemple, le texte entier de « Pride and Prejudice » est mis en cache à l’aide du paramètre cache_control. Cela permet de réutiliser ce grand texte dans plusieurs appels API sans le retraiter à chaque fois. Modifier uniquement le message utilisateur vous permet de poser diverses questions sur le livre tout en utilisant le contenu mis en cache, ce qui entraîne des réponses plus rapides et une meilleure efficacité.

Comment fonctionne la mise en cache des invites

Lorsque vous envoyez une demande avec la mise en cache des invites activée :
  1. Le système vérifie si un préfixe d’invite, jusqu’à un point de rupture de cache spécifié, est déjà mis en cache à partir d’une requête récente.
  2. S’il est trouvé, il utilise la version mise en cache, réduisant le temps de traitement et les coûts.
  3. Sinon, il traite l’invite complète et met en cache le préfixe une fois que la réponse commence.
Ceci est particulièrement utile pour :
  • Les invites avec de nombreux exemples
  • De grandes quantités de contexte ou d’informations générales
  • Les tâches répétitives avec des instructions cohérentes
  • Les longues conversations multi-tours
Par défaut, le cache a une durée de vie de 5 minutes. Le cache est actualisé sans frais supplémentaires chaque fois que le contenu mis en cache est utilisé.
Si vous trouvez que 5 minutes est trop court, Anthropic propose également une durée de cache d’1 heure à un coût supplémentaire. Le cache d’1 heure est actuellement en version bêta.Pour plus d’informations, consultez Durée du cache d’1 heure.
La mise en cache des invites met en cache le préfixe completLa mise en cache des invites référence l’invite complète - tools, system et messages (dans cet ordre) jusqu’à et y compris le bloc désigné avec cache_control.

Tarification

La mise en cache des invites introduit une nouvelle structure tarifaire. Le tableau ci-dessous montre le prix par million de jetons pour chaque modèle pris en charge :
ModelBase Input Tokens5m Cache Writes1h Cache WritesCache Hits & RefreshesOutput Tokens
Claude Opus 4.1$15 / MTok$18.75 / MTok$30 / MTok$1.50 / MTok$75 / MTok
Claude Opus 4$15 / MTok$18.75 / MTok$30 / MTok$1.50 / MTok$75 / MTok
Claude Sonnet 4.5$3 / MTok$3.75 / MTok$6 / MTok$0.30 / MTok$15 / MTok
Claude Sonnet 4$3 / MTok$3.75 / MTok$6 / MTok$0.30 / MTok$15 / MTok
Claude Sonnet 3.7 (deprecated)$3 / MTok$3.75 / MTok$6 / MTok$0.30 / MTok$15 / MTok
Claude Haiku 4.5$1 / MTok$1.25 / MTok$2 / MTok$0.10 / MTok$5 / MTok
Claude Haiku 3.5$0.80 / MTok$1 / MTok$1.6 / MTok$0.08 / MTok$4 / MTok
Claude Opus 3 (deprecated)$15 / MTok$18.75 / MTok$30 / MTok$1.50 / MTok$75 / MTok
Claude Haiku 3$0.25 / MTok$0.30 / MTok$0.50 / MTok$0.03 / MTok$1.25 / MTok
Le tableau ci-dessus reflète les multiplicateurs de tarification suivants pour la mise en cache des invites :
  • Les jetons d’écriture de cache de 5 minutes coûtent 1,25 fois le prix des jetons d’entrée de base
  • Les jetons d’écriture de cache d’1 heure coûtent 2 fois le prix des jetons d’entrée de base
  • Les jetons de lecture du cache coûtent 0,1 fois le prix des jetons d’entrée de base

Comment implémenter la mise en cache des invites

Modèles pris en charge

La mise en cache des invites est actuellement prise en charge sur :
  • Claude Opus 4.1
  • Claude Opus 4
  • Claude Sonnet 4.5
  • Claude Sonnet 4
  • Claude Sonnet 3.7
  • Claude Haiku 4.5
  • Claude Haiku 3.5
  • Claude Haiku 3
  • Claude Opus 3 (obsolète)

Structurer votre invite

Placez le contenu statique (définitions d’outils, instructions système, contexte, exemples) au début de votre invite. Marquez la fin du contenu réutilisable pour la mise en cache à l’aide du paramètre cache_control. Les préfixes de cache sont créés dans l’ordre suivant : tools, system, puis messages. Cet ordre forme une hiérarchie où chaque niveau s’appuie sur les précédents.

Comment fonctionne la vérification automatique des préfixes

Vous pouvez utiliser un seul point de rupture de cache à la fin de votre contenu statique, et le système trouvera automatiquement le préfixe correspondant le plus long. Comprendre comment cela fonctionne vous aide à optimiser votre stratégie de mise en cache. Trois principes fondamentaux :
  1. Les clés de cache sont cumulatives : Lorsque vous mettez explicitement en cache un bloc avec cache_control, la clé de hachage du cache est générée en hachant tous les blocs précédents dans la conversation de manière séquentielle. Cela signifie que le cache pour chaque bloc dépend de tout le contenu qui l’a précédé.
  2. Vérification séquentielle rétroactive : Le système vérifie les accès au cache en travaillant à rebours à partir de votre point de rupture explicite, en vérifiant chaque bloc précédent dans l’ordre inverse. Cela garantit que vous obtenez l’accès au cache le plus long possible.
  3. Fenêtre de recherche rétroactive de 20 blocs : Le système ne vérifie que jusqu’à 20 blocs avant chaque point de rupture cache_control explicite. Après avoir vérifié 20 blocs sans correspondance, il arrête la vérification et passe au point de rupture explicite suivant (le cas échéant).
Exemple : Comprendre la fenêtre de recherche rétroactive Considérez une conversation avec 30 blocs de contenu où vous définissez cache_control uniquement sur le bloc 30 :
  • Si vous envoyez le bloc 31 sans modifications aux blocs précédents : Le système vérifie le bloc 30 (correspondance !). Vous obtenez un accès au cache au bloc 30, et seul le bloc 31 nécessite un traitement.
  • Si vous modifiez le bloc 25 et envoyez le bloc 31 : Le système vérifie à rebours du bloc 30 → 29 → 28… → 25 (pas de correspondance) → 24 (correspondance !). Puisque le bloc 24 n’a pas changé, vous obtenez un accès au cache au bloc 24, et seuls les blocs 25-30 nécessitent un retraitement.
  • Si vous modifiez le bloc 5 et envoyez le bloc 31 : Le système vérifie à rebours du bloc 30 → 29 → 28… → 11 (vérification #20). Après 20 vérifications sans trouver de correspondance, il arrête la recherche. Puisque le bloc 5 est au-delà de la fenêtre de 20 blocs, aucun accès au cache ne se produit et tous les blocs nécessitent un retraitement. Cependant, si vous aviez défini un point de rupture cache_control explicite sur le bloc 5, le système continuerait à vérifier à partir de ce point de rupture : bloc 5 (pas de correspondance) → bloc 4 (correspondance !). Cela permet un accès au cache au bloc 4, démontrant pourquoi vous devriez placer des points de rupture avant le contenu modifiable.
Point clé : Définissez toujours un point de rupture de cache explicite à la fin de votre conversation pour maximiser vos chances d’accès au cache. De plus, définissez des points de rupture juste avant les blocs de contenu qui pourraient être modifiables pour assurer que ces sections peuvent être mises en cache indépendamment.

Quand utiliser plusieurs points de rupture

Vous pouvez définir jusqu’à 4 points de rupture de cache si vous souhaitez :
  • Mettre en cache différentes sections qui changent à des fréquences différentes (par exemple, les outils changent rarement, mais le contexte se met à jour quotidiennement)
  • Avoir plus de contrôle sur exactement ce qui est mis en cache
  • Assurer la mise en cache du contenu plus de 20 blocs avant votre point de rupture final
  • Placer des points de rupture avant le contenu modifiable pour garantir des accès au cache même lorsque des modifications se produisent au-delà de la fenêtre de 20 blocs
Limitation importante : Si votre invite a plus de 20 blocs de contenu avant votre point de rupture de cache, et que vous modifiez le contenu plus tôt que ces 20 blocs, vous n’obtiendrez pas d’accès au cache à moins d’ajouter des points de rupture explicites supplémentaires plus proches de ce contenu.

Limitations du cache

La longueur minimale d’invite pouvant être mise en cache est :
  • 1024 jetons pour Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4.5, Claude Sonnet 4, Claude Sonnet 3.7 (obsolète) et Claude Opus 3 (obsolète)
  • 4096 jetons pour Claude Haiku 4.5
  • 2048 jetons pour Claude Haiku 3.5 et Claude Haiku 3
Les invites plus courtes ne peuvent pas être mises en cache, même si elles sont marquées avec cache_control. Toute demande de mise en cache de moins que ce nombre de jetons sera traitée sans mise en cache. Pour voir si une invite a été mise en cache, consultez les champs d’utilisation de la réponse. Pour les demandes concurrentes, notez qu’une entrée de cache ne devient disponible qu’après le début de la première réponse. Si vous avez besoin d’accès au cache pour les demandes parallèles, attendez la première réponse avant d’envoyer les demandes suivantes. Actuellement, « ephemeral » est le seul type de cache pris en charge, qui a par défaut une durée de vie de 5 minutes.

Comprendre les coûts des points de rupture de cache

Les points de rupture de cache eux-mêmes n’ajoutent aucun coût. Vous êtes facturé uniquement pour :
  • Écritures de cache : Lorsque du nouveau contenu est écrit dans le cache (25 % de plus que les jetons d’entrée de base pour TTL de 5 minutes)
  • Lectures de cache : Lorsque le contenu mis en cache est utilisé (10 % du prix des jetons d’entrée de base)
  • Jetons d’entrée réguliers : Pour tout contenu non mis en cache
Ajouter plus de points de rupture cache_control n’augmente pas vos coûts - vous payez toujours le même montant en fonction du contenu réellement mis en cache et lu. Les points de rupture vous donnent simplement le contrôle sur les sections qui peuvent être mises en cache indépendamment.

Ce qui peut être mis en cache

La plupart des blocs de la demande peuvent être désignés pour la mise en cache avec cache_control. Cela inclut :
  • Outils : Définitions d’outils dans le tableau tools
  • Messages système : Blocs de contenu dans le tableau system
  • Messages texte : Blocs de contenu dans le tableau messages.content, pour les tours utilisateur et assistant
  • Images et documents : Blocs de contenu dans le tableau messages.content, dans les tours utilisateur
  • Utilisation d’outils et résultats d’outils : Blocs de contenu dans le tableau messages.content, dans les tours utilisateur et assistant
Chacun de ces éléments peut être marqué avec cache_control pour activer la mise en cache pour cette partie de la demande.

Ce qui ne peut pas être mis en cache

Bien que la plupart des blocs de demande puissent être mis en cache, il y a quelques exceptions :
  • Les blocs de réflexion ne peuvent pas être mis en cache directement avec cache_control. Cependant, les blocs de réflexion PEUVENT être mis en cache aux côtés d’autre contenu lorsqu’ils apparaissent dans les tours assistant précédents. Lorsqu’ils sont mis en cache de cette façon, ils COMPTENT comme des jetons d’entrée lorsqu’ils sont lus à partir du cache.
  • Les blocs de sous-contenu (comme les citations) eux-mêmes ne peuvent pas être mis en cache directement. À la place, mettez en cache le bloc de niveau supérieur. Dans le cas des citations, les blocs de contenu de document de niveau supérieur qui servent de matériel source pour les citations peuvent être mis en cache. Cela vous permet d’utiliser la mise en cache des invites avec les citations efficacement en mettant en cache les documents que les citations référenceront.
  • Les blocs de texte vides ne peuvent pas être mis en cache.

Ce qui invalide le cache

Les modifications du contenu mis en cache peuvent invalider une partie ou la totalité du cache. Comme décrit dans Structurer votre invite, le cache suit la hiérarchie : toolssystemmessages. Les modifications à chaque niveau invalident ce niveau et tous les niveaux suivants. Le tableau suivant montre quelles parties du cache sont invalidées par différents types de modifications. ✘ indique que le cache est invalidé, tandis que ✓ indique que le cache reste valide.
Ce qui changeCache des outilsCache systèmeCache des messagesImpact
Définitions d’outilsModifier les définitions d’outils (noms, descriptions, paramètres) invalide l’intégralité du cache
Basculement de recherche WebL’activation/désactivation de la recherche Web modifie l’invite système
Basculement des citationsL’activation/désactivation des citations modifie l’invite système
Choix d’outilLes modifications du paramètre tool_choice n’affectent que les blocs de messages
ImagesL’ajout/suppression d’images n’importe où dans l’invite affecte les blocs de messages
Paramètres de réflexionLes modifications des paramètres de réflexion étendue (activation/désactivation, budget) affectent les blocs de messages
Résultats non-outils transmis aux demandes de réflexion étendueLorsque des résultats non-outils sont transmis dans les demandes tandis que la réflexion étendue est activée, tous les blocs de réflexion précédemment mis en cache sont supprimés du contexte, et tous les messages en contexte qui suivent ces blocs de réflexion sont supprimés du cache. Pour plus de détails, consultez Mise en cache avec les blocs de réflexion.

Suivi des performances du cache

Surveillez les performances du cache à l’aide de ces champs de réponse API, dans usage dans la réponse (ou événement message_start si streaming) :
  • cache_creation_input_tokens : Nombre de jetons écrits dans le cache lors de la création d’une nouvelle entrée.
  • cache_read_input_tokens : Nombre de jetons récupérés du cache pour cette demande.
  • input_tokens : Nombre de jetons d’entrée qui n’ont pas été lus ou utilisés pour créer un cache.

Meilleures pratiques pour une mise en cache efficace

Pour optimiser les performances de la mise en cache des invites :
  • Mettez en cache le contenu stable et réutilisable comme les instructions système, les informations générales, les grands contextes ou les définitions d’outils fréquentes.
  • Placez le contenu mis en cache au début de l’invite pour de meilleures performances.
  • Utilisez les points de rupture de cache de manière stratégique pour séparer différentes sections de préfixe pouvant être mises en cache.
  • Définissez les points de rupture de cache à la fin des conversations et juste avant le contenu modifiable pour maximiser les taux d’accès au cache, en particulier lorsque vous travaillez avec des invites ayant plus de 20 blocs de contenu.
  • Analysez régulièrement les taux d’accès au cache et ajustez votre stratégie selon les besoins.

Optimisation pour différents cas d’utilisation

Adaptez votre stratégie de mise en cache des invites à votre scénario :
  • Agents conversationnels : Réduisez le coût et la latence pour les conversations prolongées, en particulier celles avec de longues instructions ou des documents téléchargés.
  • Assistants de codage : Améliorez l’autocomplétion et les questions-réponses sur la base de code en gardant les sections pertinentes ou une version résumée de la base de code dans l’invite.
  • Traitement de grands documents : Incorporez du matériel long complet, y compris des images, dans votre invite sans augmenter la latence de réponse.
  • Ensembles d’instructions détaillées : Partagez des listes étendues d’instructions, de procédures et d’exemples pour affiner les réponses de Claude. Les développeurs incluent souvent un ou deux exemples dans l’invite, mais avec la mise en cache des invites, vous pouvez obtenir des performances encore meilleures en incluant 20+ exemples divers de réponses de haute qualité.
  • Utilisation d’outils agentiques : Améliorez les performances pour les scénarios impliquant plusieurs appels d’outils et des modifications de code itératives, où chaque étape nécessite généralement un nouvel appel API.
  • Parlez à des livres, des articles, de la documentation, des transcriptions de podcasts et d’autres contenus longs : Donnez vie à n’importe quelle base de connaissances en intégrant le ou les documents entiers dans l’invite, et laissez les utilisateurs poser des questions.

Dépannage des problèmes courants

Si vous rencontrez un comportement inattendu :
  • Assurez-vous que les sections mises en cache sont identiques et marquées avec cache_control aux mêmes emplacements dans tous les appels
  • Vérifiez que les appels sont effectués dans la durée de vie du cache (5 minutes par défaut)
  • Vérifiez que tool_choice et l’utilisation d’images restent cohérents entre les appels
  • Validez que vous mettez en cache au moins le nombre minimum de jetons
  • Le système vérifie automatiquement les accès au cache aux limites des blocs de contenu précédents (jusqu’à ~20 blocs avant votre point de rupture). Pour les invites avec plus de 20 blocs de contenu, vous devrez peut-être ajouter des paramètres cache_control supplémentaires plus tôt dans l’invite pour assurer que tout le contenu peut être mis en cache
  • Vérifiez que les clés de vos blocs de contenu tool_use ont un ordre stable car certains langages (par exemple Swift, Go) randomisent l’ordre des clés lors de la conversion JSON, ce qui casse les caches
Les modifications apportées à tool_choice ou la présence/absence d’images n’importe où dans l’invite invalideront le cache, nécessitant la création d’une nouvelle entrée de cache. Pour plus de détails sur l’invalidation du cache, consultez Ce qui invalide le cache.

Mise en cache avec les blocs de réflexion

Lorsque vous utilisez la réflexion étendue avec la mise en cache des invites, les blocs de réflexion ont un comportement spécial : Mise en cache automatique aux côtés d’autre contenu : Bien que les blocs de réflexion ne puissent pas être explicitement marqués avec cache_control, ils sont mis en cache dans le cadre du contenu de la demande lorsque vous effectuez des appels API ultérieurs avec des résultats d’outils. Cela se produit généralement lors de l’utilisation d’outils lorsque vous transmettez les blocs de réflexion pour continuer la conversation. Comptage des jetons d’entrée : Lorsque les blocs de réflexion sont lus à partir du cache, ils comptent comme des jetons d’entrée dans vos métriques d’utilisation. C’est important pour le calcul des coûts et la budgétisation des jetons. Modèles d’invalidation du cache :
  • Le cache reste valide lorsque seuls les résultats d’outils sont fournis en tant que messages utilisateur
  • Le cache est invalidé lorsque du contenu utilisateur non-résultat d’outil est ajouté, ce qui entraîne la suppression de tous les blocs de réflexion précédents
  • Ce comportement de mise en cache se produit même sans marqueurs cache_control explicites
Pour plus de détails sur l’invalidation du cache, consultez Ce qui invalide le cache. Exemple avec utilisation d’outils :
Demande 1 : Utilisateur : « Quel est le temps à Paris ? »
Réponse : [thinking_block_1] + [bloc tool_use 1]

Demande 2 :
Utilisateur : [« Quel est le temps à Paris ? »],
Assistant : [thinking_block_1] + [bloc tool_use 1],
Utilisateur : [tool_result_1, cache=True]
Réponse : [thinking_block_2] + [bloc texte 2]
# La demande 2 met en cache son contenu de demande (pas la réponse)
# Le cache inclut : message utilisateur, thinking_block_1, bloc tool_use 1 et tool_result_1

Demande 3 :
Utilisateur : [« Quel est le temps à Paris ? »],
Assistant : [thinking_block_1] + [bloc tool_use 1],
Utilisateur : [tool_result_1, cache=True],
Assistant : [thinking_block_2] + [bloc texte 2],
Utilisateur : [Réponse texte, cache=True]
# Le bloc utilisateur non-résultat d'outil entraîne l'ignorance de tous les blocs de réflexion
# Cette demande est traitée comme si les blocs de réflexion n'avaient jamais été présents
Lorsqu’un bloc utilisateur non-résultat d’outil est inclus, il désigne une nouvelle boucle assistant et tous les blocs de réflexion précédents sont supprimés du contexte. Pour des informations plus détaillées, consultez la documentation sur la réflexion étendue.

Stockage et partage du cache

  • Isolation organisationnelle : Les caches sont isolés entre les organisations. Différentes organisations ne partagent jamais les caches, même si elles utilisent des invites identiques.
  • Correspondance exacte : Les accès au cache nécessitent une correspondance à 100 % des segments d’invite, y compris tout le texte et les images jusqu’à et y compris le bloc marqué avec le contrôle de cache.
  • Génération de jetons de sortie : La mise en cache des invites n’a aucun effet sur la génération de jetons de sortie. La réponse que vous recevez sera identique à ce que vous obtiendriez si la mise en cache des invites n’était pas utilisée.

Durée du cache d’1 heure

Si vous trouvez que 5 minutes est trop court, Anthropic propose également une durée de cache d’1 heure à un coût supplémentaire. Pour utiliser le cache étendu, incluez ttl dans la définition cache_control comme ceci :
"cache_control": {
    "type": "ephemeral",
    "ttl": "5m" | "1h"
}
La réponse inclura des informations de cache détaillées comme suit :
{
    "usage": {
        "input_tokens": ...,
        "cache_read_input_tokens": ...,
        "cache_creation_input_tokens": ...,
        "output_tokens": ...,

        "cache_creation": {
            "ephemeral_5m_input_tokens": 456,
            "ephemeral_1h_input_tokens": 100,
        }
    }
}
Notez que le champ cache_creation_input_tokens actuel est égal à la somme des valeurs dans l’objet cache_creation.

Quand utiliser le cache d’1 heure

Si vous avez des invites utilisées à un rythme régulier (c’est-à-dire des invites système utilisées plus fréquemment que toutes les 5 minutes), continuez à utiliser le cache de 5 minutes, car celui-ci continuera à être actualisé sans frais supplémentaires. Le cache d’1 heure est mieux utilisé dans les scénarios suivants :
  • Lorsque vous avez des invites susceptibles d’être utilisées moins fréquemment que toutes les 5 minutes, mais plus fréquemment que toutes les heures. Par exemple, lorsqu’un agent auxiliaire agentique prendra plus de 5 minutes, ou lorsque vous stockez une longue conversation de chat avec un utilisateur et vous vous attendez généralement à ce que cet utilisateur ne réponde pas dans les 5 prochaines minutes.
  • Lorsque la latence est importante et que vos invites de suivi peuvent être envoyées au-delà de 5 minutes.
  • Lorsque vous souhaitez améliorer votre utilisation des limites de débit, car les accès au cache ne sont pas déduits de votre limite de débit.
Le cache de 5 minutes et d’1 heure se comportent de la même manière en ce qui concerne la latence. Vous verrez généralement un temps-au-premier-jeton amélioré pour les longs documents.

Mélanger différents TTL

Vous pouvez utiliser à la fois les contrôles de cache d’1 heure et de 5 minutes dans la même demande, mais avec une contrainte importante : Les entrées de cache avec un TTL plus long doivent apparaître avant les TTL plus courts (c’est-à-dire qu’une entrée de cache d’1 heure doit apparaître avant toute entrée de cache de 5 minutes). Lors du mélange des TTL, nous déterminons trois emplacements de facturation dans votre invite :
  1. Position A : Le nombre de jetons au plus haut accès au cache (ou 0 s’il n’y a pas d’accès).
  2. Position B : Le nombre de jetons au plus haut bloc cache_control d’1 heure après A (ou égal à A s’il n’en existe pas).
  3. Position C : Le nombre de jetons au dernier bloc cache_control.
Si B et/ou C sont supérieurs à A, ils seront nécessairement des accès manqués au cache, car A est l’accès au cache le plus élevé.
Vous serez facturé pour :
  1. Jetons de lecture du cache pour A.
  2. Jetons d’écriture de cache d’1 heure pour (B - A).
  3. Jetons d’écriture de cache de 5 minutes pour (C - B).
Voici 3 exemples. Ceci dépict les jetons d’entrée de 3 demandes, chacune ayant différents accès au cache et accès manqués au cache. Chacun a une tarification calculée différente, affichée dans les boîtes colorées, en conséquence. Diagramme de mélange des TTL

Exemples de mise en cache des invites

Pour vous aider à démarrer avec la mise en cache des invites, nous avons préparé un livre de recettes de mise en cache des invites avec des exemples détaillés et des meilleures pratiques. Ci-dessous, nous avons inclus plusieurs extraits de code qui présentent divers modèles de mise en cache des invites. Ces exemples démontrent comment implémenter la mise en cache dans différents scénarios, vous aidant à comprendre les applications pratiques de cette fonctionnalité :
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": [
        {
            "type": "text",
            "text": "You are an AI assistant tasked with analyzing legal documents."
        },
        {
            "type": "text",
            "text": "Here is the full text of a complex legal agreement: [Insert full text of a 50-page legal agreement here]",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "What are the key terms and conditions in this agreement?"
        }
    ]
}'
Cet exemple démontre l’utilisation basique de la mise en cache des invites, en mettant en cache le texte complet de l’accord juridique en tant que préfixe tout en gardant l’instruction utilisateur non mise en cache.Pour la première demande :
  • input_tokens : Nombre de jetons dans le message utilisateur uniquement
  • cache_creation_input_tokens : Nombre de jetons dans l’intégralité du message système, y compris le document juridique
  • cache_read_input_tokens : 0 (pas d’accès au cache à la première demande)
Pour les demandes suivantes dans la durée de vie du cache :
  • input_tokens : Nombre de jetons dans le message utilisateur uniquement
  • cache_creation_input_tokens : 0 (pas de nouvelle création de cache)
  • cache_read_input_tokens : Nombre de jetons dans l’intégralité du message système mis en cache
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "tools": [
        {
            "name": "get_weather",
            "description": "Get the current weather in a given location",
            "input_schema": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "The city and state, e.g. San Francisco, CA"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"],
                        "description": "The unit of temperature, either celsius or fahrenheit"
                    }
                },
                "required": ["location"]
            }
        },
        # many more tools
        {
            "name": "get_time",
            "description": "Get the current time in a given time zone",
            "input_schema": {
                "type": "object",
                "properties": {
                    "timezone": {
                        "type": "string",
                        "description": "The IANA time zone name, e.g. America/Los_Angeles"
                    }
                },
                "required": ["timezone"]
            },
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "What is the weather and time in New York?"
        }
    ]
}'
Dans cet exemple, nous démontrons la mise en cache des définitions d’outils.Le paramètre cache_control est placé sur l’outil final (get_time) pour désigner tous les outils comme faisant partie du préfixe statique.Cela signifie que toutes les définitions d’outils, y compris get_weather et tous les autres outils définis avant get_time, seront mis en cache en tant que préfixe unique.Cette approche est utile lorsque vous avez un ensemble cohérent d’outils que vous souhaitez réutiliser dans plusieurs demandes sans les retraiter à chaque fois.Pour la première demande :
  • input_tokens : Nombre de jetons dans le message utilisateur
  • cache_creation_input_tokens : Nombre de jetons dans toutes les définitions d’outils et l’invite système
  • cache_read_input_tokens : 0 (pas d’accès au cache à la première demande)
Pour les demandes suivantes dans la durée de vie du cache :
  • input_tokens : Nombre de jetons dans le message utilisateur
  • cache_creation_input_tokens : 0 (pas de nouvelle création de cache)
  • cache_read_input_tokens : Nombre de jetons dans toutes les définitions d’outils et l’invite système mises en cache
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": [
        {
            "type": "text",
            "text": "...long system prompt",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Hello, can you tell me more about the solar system?",
                }
            ]
        },
        {
            "role": "assistant",
            "content": "Certainly! The solar system is the collection of celestial bodies that orbit our Sun. It consists of eight planets, numerous moons, asteroids, comets, and other objects. The planets, in order from closest to farthest from the Sun, are: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune. Each planet has its own unique characteristics and features. Is there a specific aspect of the solar system you would like to know more about?"
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Good to know."
                },
                {
                    "type": "text",
                    "text": "Tell me more about Mars.",
                    "cache_control": {"type": "ephemeral"}
                }
            ]
        }
    ]
}'
Dans cet exemple, nous démontrons comment utiliser la mise en cache des invites dans une conversation multi-tours.À chaque tour, nous marquons le bloc final du message final avec cache_control afin que la conversation puisse être progressivement mise en cache. Le système recherchera automatiquement et utilisera le préfixe précédemment mis en cache le plus long pour les messages de suivi. C’est-à-dire que les blocs qui ont été précédemment marqués avec un bloc cache_control ne sont pas marqués ultérieurement, mais ils seront toujours considérés comme un accès au cache (et aussi une actualisation du cache !) s’ils sont atteints dans les 5 minutes.De plus, notez que le paramètre cache_control est placé sur le message système. Ceci est pour assurer que s’il est évincé du cache (après ne pas avoir été utilisé pendant plus de 5 minutes), il sera rajouté au cache à la prochaine demande.Cette approche est utile pour maintenir le contexte dans les conversations en cours sans retraiter à plusieurs reprises les mêmes informations.Lorsque ceci est configuré correctement, vous devriez voir ce qui suit dans la réponse d’utilisation de chaque demande :
  • input_tokens : Nombre de jetons dans le nouveau message utilisateur (sera minimal)
  • cache_creation_input_tokens : Nombre de jetons dans les nouveaux tours assistant et utilisateur
  • cache_read_input_tokens : Nombre de jetons dans la conversation jusqu’au tour précédent
curl https://api.anthropic.com/v1/messages \
     --header "x-api-key: $ANTHROPIC_API_KEY" \
     --header "anthropic-version: 2023-06-01" \
     --header "content-type: application/json" \
     --data \
'{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "tools": [
        {
            "name": "search_documents",
            "description": "Search through the knowledge base",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "Search query"
                    }
                },
                "required": ["query"]
            }
        },
        {
            "name": "get_document",
            "description": "Retrieve a specific document by ID",
            "input_schema": {
                "type": "object",
                "properties": {
                    "doc_id": {
                        "type": "string",
                        "description": "Document ID"
                    }
                },
                "required": ["doc_id"]
            },
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "system": [
        {
            "type": "text",
            "text": "You are a helpful research assistant with access to a document knowledge base.\n\n# Instructions\n- Always search for relevant documents before answering\n- Provide citations for your sources\n- Be objective and accurate in your responses\n- If multiple documents contain relevant information, synthesize them\n- Acknowledge when information is not available in the knowledge base",
            "cache_control": {"type": "ephemeral"}
        },
        {
            "type": "text",
            "text": "# Knowledge Base Context\n\nHere are the relevant documents for this conversation:\n\n## Document 1: Solar System Overview\nThe solar system consists of the Sun and all objects that orbit it...\n\n## Document 2: Planetary Characteristics\nEach planet has unique features. Mercury is the smallest planet...\n\n## Document 3: Mars Exploration\nMars has been a target of exploration for decades...\n\n[Additional documents...]",
            "cache_control": {"type": "ephemeral"}
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": "Can you search for information about Mars rovers?"
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "tool_use",
                    "id": "tool_1",
                    "name": "search_documents",
                    "input": {"query": "Mars rovers"}
                }
            ]
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "tool_result",
                    "tool_use_id": "tool_1",
                    "content": "Found 3 relevant documents: Document 3 (Mars Exploration), Document 7 (Rover Technology), Document 9 (Mission History)"
                }
            ]
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "text",
                    "text": "I found 3 relevant documents about Mars rovers. Let me get more details from the Mars Exploration document."
                }
            ]
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Yes, please tell me about the Perseverance rover specifically.",
                    "cache_control": {"type": "ephemeral"}
                }
            ]
        }
    ]
}'
Cet exemple complet démontre comment utiliser les 4 points de rupture de cache disponibles pour optimiser différentes parties de votre invite :
  1. Cache des outils (point de rupture de cache 1) : Le paramètre cache_control sur la dernière définition d’outil met en cache toutes les définitions d’outils.
  2. Cache des instructions réutilisables (point de rupture de cache 2) : Les instructions statiques dans l’invite système sont mises en cache séparément. Ces instructions changent rarement entre les demandes.
  3. Cache du contexte RAG (point de rupture de cache 3) : Les documents de la base de connaissances sont mis en cache indépendamment, vous permettant de mettre à jour les documents RAG sans invalider le cache des outils ou des instructions.
  4. Cache de l’historique de conversation (point de rupture de cache 4) : La réponse de l’assistant est marquée avec cache_control pour activer la mise en cache progressive de la conversation au fur et à mesure qu’elle progresse.
Cette approche offre une flexibilité maximale :
  • Si vous mettez à jour uniquement le message utilisateur final, les quatre segments de cache sont réutilisés
  • Si vous mettez à jour les documents RAG mais conservez les mêmes outils et instructions, les deux premiers segments de cache sont réutilisés
  • Si vous modifiez la conversation mais conservez les mêmes outils, instructions et documents, les trois premiers segments sont réutilisés
  • Chaque point de rupture de cache peut être invalidé indépendamment en fonction de ce qui change dans votre application
Pour la première demande :
  • input_tokens : Jetons dans le message utilisateur final
  • cache_creation_input_tokens : Jetons dans tous les segments mis en cache (outils + instructions + documents RAG + historique de conversation)
  • cache_read_input_tokens : 0 (pas d’accès au cache)
Pour les demandes suivantes avec uniquement un nouveau message utilisateur :
  • input_tokens : Jetons dans le nouveau message utilisateur uniquement
  • cache_creation_input_tokens : Tous les nouveaux jetons ajoutés à l’historique de conversation
  • cache_read_input_tokens : Tous les jetons précédemment mis en cache (outils + instructions + documents RAG + conversation précédente)
Ce modèle est particulièrement puissant pour :
  • Les applications RAG avec de grands contextes de documents
  • Les systèmes d’agents qui utilisent plusieurs outils
  • Les conversations longues qui doivent maintenir le contexte
  • Les applications qui doivent optimiser différentes parties de l’invite indépendamment

FAQ

Dans la plupart des cas, un seul point de rupture de cache à la fin de votre contenu statique suffit. Le système vérifie automatiquement les accès au cache à toutes les limites des blocs de contenu précédents (jusqu’à 20 blocs avant votre point de rupture) et utilise le préfixe correspondant le plus long.Vous n’avez besoin de plusieurs points de rupture que si :
  • Vous avez plus de 20 blocs de contenu avant votre point de cache souhaité
  • Vous souhaitez mettre en cache des sections qui se mettent à jour à des fréquences différentes indépendamment
  • Vous avez besoin d’un contrôle explicite sur ce qui est mis en cache pour l’optimisation des coûts
Exemple : Si vous avez des instructions système (changent rarement) et un contexte RAG (change quotidiennement), vous pourriez utiliser deux points de rupture pour les mettre en cache séparément.
Non, les points de rupture de cache eux-mêmes sont gratuits. Vous payez uniquement pour :
  • L’écriture de contenu dans le cache (25 % de plus que les jetons d’entrée de base pour TTL de 5 minutes)
  • La lecture à partir du cache (10 % du prix des jetons d’entrée de base)
  • Les jetons d’entrée réguliers pour le contenu non mis en cache
Le nombre de points de rupture n’affecte pas la tarification - seule la quantité de contenu mis en cache et lu compte.
La durée de vie minimale par défaut du cache (TTL) est de 5 minutes. Cette durée de vie est actualisée chaque fois que le contenu mis en cache est utilisé.Si vous trouvez que 5 minutes est trop court, Anthropic propose également un TTL de cache d’1 heure.
Vous pouvez définir jusqu’à 4 points de rupture de cache (en utilisant les paramètres cache_control) dans votre invite.
Non, la mise en cache des invites est actuellement disponible uniquement pour Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4.5, Claude Sonnet 4, Claude Sonnet 3.7, Claude Haiku 4.5, Claude Haiku 3.5, Claude Haiku 3 et Claude Opus 3 (obsolète).
Les invites système mises en cache et les outils seront réutilisés lorsque les paramètres de réflexion changent. Cependant, les modifications de réflexion (activation/désactivation ou modifications de budget) invalideront les préfixes d’invite précédemment mis en cache avec le contenu des messages.Pour plus de détails sur l’invalidation du cache, consultez Ce qui invalide le cache.Pour plus d’informations sur la réflexion étendue, y compris son interaction avec l’utilisation d’outils et la mise en cache des invites, consultez la documentation sur la réflexion étendue.
Pour activer la mise en cache des invites, incluez au moins un point de rupture cache_control dans votre demande API.
Oui, la mise en cache des invites peut être utilisée aux côtés d’autres fonctionnalités de l’API comme l’utilisation d’outils et les capacités de vision. Cependant, modifier s’il y a des images dans une invite ou modifier les paramètres d’utilisation d’outils cassera le cache.Pour plus de détails sur l’invalidation du cache, consultez Ce qui invalide le cache.
La mise en cache des invites introduit une nouvelle structure tarifaire où les écritures de cache coûtent 25 % de plus que les jetons d’entrée de base, tandis que les accès au cache coûtent seulement 10 % du prix des jetons d’entrée de base.
Actuellement, il n’y a aucun moyen d’effacer manuellement le cache. Les préfixes mis en cache expirent automatiquement après un minimum de 5 minutes d’inactivité.
Vous pouvez surveiller les performances du cache à l’aide des champs cache_creation_input_tokens et cache_read_input_tokens dans la réponse de l’API.
Consultez Ce qui invalide le cache pour plus de détails sur l’invalidation du cache, y compris une liste des modifications qui nécessitent la création d’une nouvelle entrée de cache.
La mise en cache des invites est conçue avec des mesures fortes de confidentialité et de séparation des données :
  1. Les clés de cache sont générées à l’aide d’un hachage cryptographique des invites jusqu’au point de contrôle de cache. Cela signifie que seules les demandes avec des invites identiques peuvent accéder à un cache spécifique.
  2. Les caches sont spécifiques à l’organisation. Les utilisateurs au sein de la même organisation peuvent accéder au même cache s’ils utilisent des invites identiques, mais les caches ne sont pas partagés entre différentes organisations, même pour des invites identiques.
  3. Le mécanisme de mise en cache est conçu pour maintenir l’intégrité et la confidentialité de chaque conversation ou contexte unique.
  4. Il est sûr d’utiliser cache_control n’importe où dans vos invites. Pour l’efficacité des coûts, il est préférable d’exclure les parties très variables (par exemple, l’entrée arbitraire de l’utilisateur) de la mise en cache.
Ces mesures garantissent que la mise en cache des invites maintient la confidentialité et la sécurité des données tout en offrant des avantages en matière de performances.
Oui, il est possible d’utiliser la mise en cache des invites avec vos demandes Batches API. Cependant, parce que les demandes de lot asynchrones peuvent être traitées simultanément et dans n’importe quel ordre, les accès au cache sont fournis sur la base du meilleur effort.Le cache d’1 heure peut aider à améliorer vos accès au cache. La façon la plus rentable de l’utiliser est la suivante :
  • Rassemblez un ensemble de demandes de messages qui ont un préfixe partagé.
  • Envoyez une demande de lot avec juste une seule demande qui a ce préfixe partagé et un bloc de cache d’1 heure. Cela sera écrit dans le cache d’1 heure.
  • Dès que c’est terminé, soumettez le reste des demandes. Vous devrez surveiller le travail pour savoir quand il se termine.
C’est généralement mieux que d’utiliser le cache de 5 minutes simplement parce qu’il est courant que les demandes de lot prennent entre 5 minutes et 1 heure pour se terminer. Nous envisageons des moyens d’améliorer ces taux d’accès au cache et de rendre ce processus plus simple.
Cette erreur apparaît généralement lorsque vous avez mis à niveau votre SDK ou que vous utilisez des exemples de code obsolètes. La mise en cache des invites est maintenant généralement disponible, vous n’avez donc plus besoin du préfixe bêta. Au lieu de :
python client.beta.prompt_caching.messages.create(...)
Utilisez simplement :
python client.messages.create(...)
Cette erreur apparaît généralement lorsque vous avez mis à niveau votre SDK ou que vous utilisez des exemples de code obsolètes. La mise en cache des invites est maintenant généralement disponible, vous n’avez donc plus besoin du préfixe bêta. Au lieu de :
TypeScript
client.beta.promptCaching.messages.create(...)
Utilisez simplement :
client.messages.create(...)