Mise en cache des invites

La mise en cache des invites optimise votre utilisation de l'API en vous permettant de reprendre à partir de préfixes spécifiques dans vos invites. Cela 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.

Il y a deux façons d'activer la mise en cache des invites :

• Mise en cache automatique : Ajoutez un seul champ cache_control au niveau supérieur de votre requête. Le système applique automatiquement le point de rupture du cache au dernier bloc pouvant être mis en cache et le déplace vers l'avant à mesure que les conversations se développent. Idéal pour les conversations multi-tours où l'historique des messages croissant doit être automatiquement mis en cache.
• Points de rupture de cache explicites : Placez cache_control directement sur les blocs de contenu individuels pour un contrôle fin-grained sur exactement ce qui est mis en cache.

Le moyen le plus simple de commencer est la mise en cache automatique :

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.",
    messages=[
        {
            "role": "user",
            "content": "Analyze the major themes in 'Pride and Prejudice'.",
        }
    ],
)
print(response.usage.model_dump_json())

Avec la mise en cache automatique, le système met en cache tout le contenu jusqu'à et y compris le dernier bloc pouvant être mis en cache. Sur les requêtes suivantes avec le même préfixe, le contenu mis en cache est réutilisé automatiquement.

Comment fonctionne la mise en cache des invites

Lorsque vous envoyez une requête 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.

C'est particulièrement utile pour :

• Les invites avec de nombreux exemples
• De grandes quantités de contexte ou d'informations de base
• 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é.

Tarification

La mise en cache des invites introduit une nouvelle structure de tarification. Le tableau ci-dessous montre le prix par million de jetons pour chaque modèle pris en charge :

Modèles pris en charge

La mise en cache des invites (automatique et explicite) est prise en charge sur tous les modèles Claude actifs.

Mise en cache automatique

La mise en cache automatique est le moyen le plus simple d'activer la mise en cache des invites. Au lieu de placer cache_control sur les blocs de contenu individuels, ajoutez un seul champ cache_control au niveau supérieur de votre corps de requête. Le système applique automatiquement le point de rupture du cache au dernier bloc pouvant être mis en cache.

Comment fonctionne la mise en cache automatique dans les conversations multi-tours

Avec la mise en cache automatique, le point de cache se déplace vers l'avant automatiquement à mesure que les conversations se développent. Chaque nouvelle requête met en cache tout jusqu'au dernier bloc pouvant être mis en cache, et le contenu précédent est lu à partir du cache.

Le point de rupture du cache se déplace automatiquement vers le dernier bloc pouvant être mis en cache dans chaque requête, vous n'avez donc pas besoin de mettre à jour les marqueurs cache_control à mesure que la conversation se développe.

Support TTL

Par défaut, la mise en cache automatique utilise un TTL de 5 minutes. Vous pouvez spécifier un TTL d'1 heure à 2 fois le prix du jeton d'entrée de base :

{ "cache_control": { "type": "ephemeral", "ttl": "1h" } }

Combinaison avec la mise en cache au niveau des blocs

La mise en cache automatique est compatible avec les points de rupture de cache explicites. Lorsqu'ils sont utilisés ensemble, le point de rupture du cache automatique utilise l'un des 4 emplacements de point de rupture disponibles.

Cela vous permet de combiner les deux approches. Par exemple, utilisez des points de rupture explicites pour mettre en cache votre invite système et vos outils indépendamment, tandis que la mise en cache automatique gère la conversation :

{
  "model": "claude-opus-4-7",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "system": [
    {
      "type": "text",
      "text": "You are a helpful assistant.",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "What are the key terms?" }]
}

Ce qui reste identique

La mise en cache automatique utilise la même infrastructure de mise en cache sous-jacente. La tarification, les seuils de jetons minimums, les exigences d'ordre du contexte et la fenêtre de lookback de 20 blocs s'appliquent tous de la même manière qu'avec les points de rupture explicites.

Cas limites

• Si le dernier bloc a déjà un cache_control explicite avec le même TTL, la mise en cache automatique est un no-op.
• Si le dernier bloc a un cache_control explicite avec un TTL différent, l'API retourne une erreur 400.
• Si 4 points de rupture explicites au niveau des blocs existent déjà, l'API retourne une erreur 400 (aucun emplacement disponible pour la mise en cache automatique).
• Si le dernier bloc n'est pas admissible comme cible de point de rupture de cache automatique, le système marche silencieusement vers l'arrière pour trouver le bloc admissible le plus proche. Si aucun n'est trouvé, la mise en cache est ignorée.

Points de rupture de cache explicites

Pour plus de contrôle sur la mise en cache, vous pouvez placer cache_control directement sur les blocs de contenu individuels. C'est utile lorsque vous devez mettre en cache différentes sections qui changent à des fréquences différentes, ou lorsque vous avez besoin d'un contrôle fin-grained sur exactement ce qui est mis en cache.

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 en utilisant le 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 le plus long qu'une requête antérieure a déjà écrit dans le cache. Comprendre comment cela fonctionne vous aide à optimiser votre stratégie de mise en cache.

Trois principes fondamentaux :

1. Les écritures de cache se produisent uniquement à votre point de rupture. Marquer un bloc avec cache_control écrit exactement une entrée de cache : un hash du préfixe se terminant à ce bloc. Le système n'écrit pas d'entrées pour aucune position antérieure. Parce que le hash est cumulatif, couvrant tout jusqu'à et y compris le point de rupture, modifier n'importe quel bloc au point de rupture ou avant produit un hash différent à la requête suivante.

2. Les lectures de cache regardent vers l'arrière pour les entrées que les requêtes antérieures ont écrites. À chaque requête, le système calcule le hash du préfixe à votre point de rupture et vérifie une entrée de cache correspondante. Si aucune n'existe, il marche vers l'arrière un bloc à la fois, vérifiant si le hash du préfixe à chaque position antérieure correspond à quelque chose déjà dans le cache. Il cherche des écritures antérieures, pas du contenu stable.

3. La fenêtre de lookback est de 20 blocs. Le système vérifie au maximum 20 positions par point de rupture, en comptant le point de rupture lui-même comme le premier. Si le système ne trouve aucune entrée correspondante dans cette fenêtre, la vérification s'arrête (ou reprend à partir du prochain point de rupture explicite, le cas échéant).

Exemple : Lookback dans une conversation croissante

Vous ajoutez de nouveaux blocs à chaque tour et définissez cache_control sur le bloc final de chaque requête :

• Tour 1 : 10 blocs, point de rupture sur le bloc 10. Aucune entrée de cache antérieure n'existe. Le système écrit une entrée au bloc 10.
• Tour 2 : 15 blocs, point de rupture sur le bloc 15. Le bloc 15 n'a pas d'entrée, donc le système marche vers l'arrière jusqu'au bloc 10 et trouve l'entrée du tour 1. Cache hit au bloc 10 ; le système traite uniquement les blocs 11 à 15 en frais et écrit une nouvelle entrée au bloc 15.
• Tour 3 : 35 blocs, point de rupture sur le bloc 35. Le système vérifie 20 positions (blocs 35 à 16) et ne trouve rien. L'entrée du tour 2 au bloc 15 est une position en dehors de la fenêtre, donc il n'y a pas de cache hit. Ajouter un deuxième point de rupture au bloc 15 démarre une deuxième fenêtre de lookback là, qui trouve l'entrée du tour 2.

Erreur courante : Point de rupture sur du contenu qui change à chaque requête

Votre invite a un grand contexte système statique (blocs 1 à 5) suivi d'un bloc par requête contenant un horodatage et le message de l'utilisateur (bloc 6). Vous définissez cache_control sur le bloc 6 :

• Requête 1 : Écriture de cache au bloc 6. Le hash inclut l'horodatage.
• Requête 2 : L'horodatage diffère, donc le hash du préfixe au bloc 6 diffère. Le lookback marche à travers les blocs 5, 4, 3, 2 et 1, mais le système n'a jamais écrit d'entrée à aucune de ces positions. Pas de cache hit. Vous payez pour une écriture de cache en frais à chaque requête et n'obtenez jamais une lecture.

Le lookback ne trouve pas du contenu stable derrière votre point de rupture et ne le met en cache. Il trouve des entrées que les requêtes antérieures ont déjà écrites, et les écritures se produisent uniquement aux points de rupture. Déplacez cache_control au bloc 5, le dernier bloc qui reste identique entre les requêtes, et chaque requête suivante lit le préfixe mis en cache. La mise en cache automatique tombe dans le même piège : elle place le point de rupture sur le dernier bloc pouvant être mis en cache, qui dans cette structure est celui qui change à chaque requête, donc utilisez plutôt un point de rupture explicite sur le bloc 5.

Point clé : Placez cache_control sur le dernier bloc dont le préfixe est identique entre les requêtes que vous souhaitez partager un cache. Dans une conversation croissante, le bloc final fonctionne tant que chaque tour ajoute moins de 20 blocs : le contenu antérieur ne change jamais, donc le lookback de la requête suivante trouve l'écriture antérieure. Pour une invite avec un suffixe variable (horodatages, contexte par requête, le message entrant), placez le point de rupture à la fin du préfixe statique, pas sur le bloc variable.

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 un cache hit lorsqu'une conversation croissante pousse votre point de rupture 20 blocs ou plus au-delà de la dernière écriture de cache

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 uniquement facturé 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 5 minutes)
• Lectures de cache : Lorsque le contenu mis en cache est utilisé (10 % du prix du jeton 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.

Stratégies de mise en cache et considérations

Limitations de la mise en cache

La longueur minimale d'invite pouvant être mise en cache est :

• 4096 jetons pour Claude Mythos Preview, Claude Opus 4.7, Claude Opus 4.6 et Claude Opus 4.5
• 2048 jetons pour Claude Sonnet 4.6
• 1024 jetons pour Claude Sonnet 4.5, Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4 et Claude Sonnet 3.7 (déprécié)
• 4096 jetons pour Claude Haiku 4.5
• 2048 jetons pour Claude Haiku 3.5 (déprécié) 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 requête pour mettre en cache moins que ce nombre de jetons sera traitée sans mise en cache, et aucune erreur n'est retournée. Pour vérifier si une invite a été mise en cache, vérifiez les champs d'utilisation de la réponse : si à la fois cache_creation_input_tokens et cache_read_input_tokens sont 0, l'invite n'a pas été mise en cache (probablement parce qu'elle ne répondait pas à l'exigence de longueur minimale).

Si votre invite est juste en dessous du minimum pour le modèle que vous utilisez, étendre le contenu mis en cache pour atteindre le seuil vaut souvent la peine. Les lectures de cache coûtent considérablement moins que les jetons d'entrée non mis en cache, donc atteindre le minimum peut réduire les coûts pour les invites fréquemment réutilisées.

Pour les requêtes 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 de cache hits pour les requêtes parallèles, attendez la première réponse avant d'envoyer les requêtes 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.

Ce qui peut être mis en cache

La plupart des blocs de la requête peuvent être mis en cache. 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 mis en cache, soit automatiquement, soit en les marquant avec cache_control.

Ce qui ne peut pas être mis en cache

Bien que la plupart des blocs de requête 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 avec d'autres contenus lorsqu'ils apparaissent dans les tours d'assistant précédents. Lorsqu'ils sont mis en cache de cette manière, 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. Au lieu de cela, 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 : tools → system → messages. 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.

Suivi des performances du cache

Surveillez les performances du cache en utilisant 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 requête.
• input_tokens : Nombre de jetons d'entrée qui n'ont pas été lus ou utilisés pour créer un cache (c'est-à-dire, les jetons après le dernier point de rupture de cache).

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

Mise en cache avec blocs de réflexion

Lors de l'utilisation de la réflexion étendue avec la mise en cache des invites, les blocs de réflexion ont un comportement particulier :

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 les résultats des 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 des outils sont fournis en tant que messages utilisateur
• Le cache est invalidé lorsque du contenu utilisateur autre que les résultats des outils 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 :

Request 1: User: "What's the weather in Paris?"
Response: [thinking_block_1] + [tool_use block 1]

Request 2:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True]
Response: [thinking_block_2] + [text block 2]
# Request 2 caches its request content (not the response)
# The cache includes: user message, thinking_block_1, tool_use block 1, and tool_result_1

Request 3:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]
# Non-tool-result user block causes all thinking blocks to be ignored
# This request is processed as if thinking blocks were never present

Lorsqu'un bloc utilisateur autre que le résultat d'un outil est inclus, il désigne une nouvelle boucle d'assistant et tous les blocs de réflexion précédents sont supprimés du contexte.

Pour plus d'informations 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. Les 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'au bloc marqué avec le contrôle du cache inclus.

• 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 à celle que vous obtiendriez si la mise en cache des invites n'était pas utilisée.

Meilleures pratiques pour une mise en cache efficace

Pour optimiser les performances de la mise en cache des invites :

• Commencez par la mise en cache automatique pour les conversations multi-tours. Elle gère automatiquement la gestion des points d'arrêt.
• Utilisez les points d'arrêt explicites au niveau des blocs lorsque vous devez mettre en cache différentes sections avec des fréquences de modification différentes.
• Mettez en cache le contenu stable et réutilisable comme les instructions système, les informations générales, les contextes volumineux 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 d'arrêt du cache de manière stratégique pour séparer différentes sections de préfixe pouvant être mises en cache.
• Placez le point d'arrêt sur le dernier bloc qui reste identique dans les demandes. Pour une invite avec un préfixe statique et un suffixe variable (horodatages, contexte par demande, le message entrant), c'est la fin du préfixe, pas le bloc variable.
• 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 des instructions longues 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 documents volumineux : 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 généralement 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 ou plus de réponses de haute qualité et diversifiées.
• Utilisation d'outils d'agent : 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 en laissant les utilisateurs lui 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 dans les appels. Pour les points d'arrêt explicites, vérifiez que les marqueurs cache_control sont aux mêmes emplacements
• 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 des images restent cohérents entre les appels
• Validez que vous mettez en cache au moins le nombre minimum de jetons pour le modèle que vous utilisez (voir Limitations du cache). Les défaillances de mise en cache basées sur la longueur sont silencieuses : la demande réussit mais cache_creation_input_tokens et cache_read_input_tokens seront tous les deux 0
• Confirmez que votre point d'arrêt se trouve sur un bloc qui reste identique dans les demandes. Les écritures de cache se produisent uniquement au point d'arrêt, et si ce bloc change (horodatages, contexte par demande, le message entrant), le hachage du préfixe ne correspond jamais. La recherche rétroactive ne trouve pas le contenu stable derrière le point d'arrêt ; elle ne trouve que les entrées que les demandes antérieures ont écrites à leurs propres points d'arrêt
• 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

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": "1h"
}

La réponse inclura des informations détaillées sur le cache comme suit :

{
  "usage": {
    "input_tokens": 2048,
    "cache_read_input_tokens": 1800,
    "cache_creation_input_tokens": 248,
    "output_tokens": 503,

    "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 qui sont utilisées à un rythme régulier (c'est-à-dire des invites système qui sont 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 qui sont probablement utilisées moins fréquemment que toutes les 5 minutes, mais plus fréquemment que chaque heure. Par exemple, lorsqu'un agent auxiliaire d'agent 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.

Mélange de 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 de TTL, l'API détermine 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.

Vous serez facturé pour :

1. Jetons lus 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 représente les jetons d'entrée de 3 demandes, chacune ayant différents accès au cache et défaillances de cache. Chacune a une facturation calculée différente, affichée dans les boîtes colorées, en conséquence.

Exemples de mise en cache des invites

Pour vous aider à démarrer avec la mise en cache des invites, le guide de mise en cache des invites fournit des exemples détaillés et les meilleures pratiques.

Les extraits de code suivants présentent différents modèles de mise en cache des invites. Ces exemples montrent comment implémenter la mise en cache dans différents scénarios, vous aidant à comprendre les applications pratiques de cette fonctionnalité :

Rétention des données

La mise en cache des invites (automatique et explicite) est admissible à ZDR. Anthropic ne stocke pas le texte brut de vos invites ni les réponses de Claude.

Les représentations du cache KV (clé-valeur) et les hachages cryptographiques du contenu mis en cache sont conservés en mémoire uniquement et ne sont pas stockés au repos. Les entrées en cache ont une durée de vie minimale de 5 minutes (standard) ou 60 minutes (étendue), après quoi elles sont supprimées rapidement, bien que pas immédiatement. Les entrées en cache sont isolées entre les organisations.

Pour l'admissibilité à ZDR sur toutes les fonctionnalités, voir Rétention des données et API.

FAQ

C'est important pour comprendre à la fois les coûts et les limites de débit, car input_tokens sera généralement beaucoup plus petit que votre entrée totale lors de l'utilisation efficace de la mise en cache.