> ## Documentation Index > Fetch the complete documentation index at: https://docs.aihubmix.com/llms.txt > Use this file to discover all available pages before exploring further. # Mise en cache des prompts Claude > La mise en cache des prompts réduit le temps de traitement des tâches répétitives ou des prompts à éléments constants et diminue le coût en jetons. Le seuil minimum de mise en cache varie selon le modèle Claude (512 / 1 024 / 2 048 / 4 096) et n'est pas proportionnel au numéro de version : par exemple Opus 4.8 = 1 024, Opus 4.7 = 2 048, Opus 4.6 / Opus 4.5 et Haiku 4.5 = 4 096. La répartition complète figure dans la section « Limitations du cache » ci-dessous. Un contenu inférieur au seuil n'est pas écrit dans le cache, même s'il est marqué avec `cache_control`, et aucune erreur n'est renvoyée. Voici un exemple d'implémentation de la mise en cache des prompts avec la Messages API à l'aide d'un bloc cache\_control : ```shell Curl theme={null} curl https://aihubmix.com/v1/messages \ -H "content-type: application/json" \ -H "x-api-key: AIHUBMIX_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -d '{ "stream": true, "model": "claude-opus-4-20250514", "max_tokens": 20000, "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." }, { "type": "text", "text": "Pride and Prejudice by Jane Austen... [Place complete text content here]", "cache_control": {"type": "ephemeral"} } ], "thinking": { "type": "enabled", "budget_tokens": 16000 }, "messages": [ { "role": "user", "content": "Analyze the major themes in Pride and Prejudice." } ] }' ``` ```py Python (Anthropic SDK - Recommended) theme={null} import os import anthropic client = anthropic.Anthropic( api_key="sk-***", # Replace with the key you generated in AiHubMix base_url="https://aihubmix.com" ) # Streaming response with caching with client.messages.stream( model="claude-opus-4-20250514", max_tokens=20000, 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": "", "cache_control": {"type": "ephemeral"} } ], thinking={ "type": "enabled", "budget_tokens": 16000 }, messages=[ {"role": "user", "content": "Analyze the major themes in 'Pride and Prejudice'."} ] ) as stream: for text in stream.text_stream: print(text, end="", flush=True) # Non-streaming response message = client.messages.create( model="claude-opus-4-20250514", max_tokens=20000, system=[ { "type": "text", "text": "You are an AI assistant tasked with analyzing literary works." }, { "type": "text", "text": "", "cache_control": {"type": "ephemeral"} } ], messages=[ {"role": "user", "content": "Analyze the major themes in 'Pride and Prejudice'."} ] ) print(message.content) ``` ```py Python (Requests - Alternative) theme={null} import requests url = "https://aihubmix.com/v1/messages" headers = { "content-type": "application/json", "x-api-key": "sk-***", # Replace with the key you generated in AiHubMix "anthropic-version": "2023-06-01" } data = { "stream": True, "model": "claude-opus-4-20250514", "max_tokens": 20000, "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": "", "cache_control": {"type": "ephemeral"} } ], "thinking": { "type": "enabled", "budget_tokens": 16000 }, "messages": [{"role": "user", "content": "Analyze the major themes in 'Pride and Prejudice'."}] } response = requests.post(url, headers=headers, json=data, stream=True) # Check response status if response.status_code == 200: # Process the streaming response for line in response.iter_lines(): if line: print(line.decode('utf-8')) else: print(f"Error: {response.status_code}, {response.text}") ``` **Réponse :** ```json theme={null} {"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 intégral de « Orgueil et Préjugés » est mis en cache à l'aide du paramètre cache\_control. Cela permet de réutiliser ce grand bloc de texte à travers plusieurs appels d'API sans avoir à le retraiter à chaque fois. En modifiant uniquement le message utilisateur, vous pouvez poser diverses questions sur le livre tout en exploitant le contenu mis en cache, ce qui se traduit par des réponses plus rapides et une efficacité accrue. ## Fonctionnement de la mise en cache des prompts Lorsque vous envoyez une requête avec la mise en cache des prompts activée : 1. Le système vérifie si un préfixe de prompt, 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'intégralité du prompt et met en cache le préfixe dès que la réponse commence. Cela est particulièrement utile pour : * Les prompts contenant de nombreux exemples * De grandes quantités de contexte ou d'informations de fond * 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 rafraîchi sans coût supplémentaire chaque fois que le contenu mis en cache est utilisé. Nous prenons également en charge un **cache d'1 heure** pour les scénarios nécessitant une durée de cache plus longue. ## La mise en cache des prompts met en cache le préfixe complet La mise en cache des prompts référence l'ensemble du prompt — `tools`, `system` et `messages` (dans cet ordre), jusqu'au bloc désigné avec `cache_control` (inclus). ## Erreur courante : « écrire le cache sans jamais le lire » L'échec le plus courant ressemble à ceci : à chaque requête, `cache_creation_input_tokens` est élevé (le cache est écrit en permanence), mais `cache_read_input_tokens` reste à `0` (il n'est jamais relu) — vous n'économisez donc rien. Il n'y a qu'une seule cause racine : **le contenu placé avant le point de rupture de cache (`cache_control`) a changé entre deux requêtes.** Un hit de cache exige que le point de rupture et tout ce qui le précède (dans l'ordre `tools` → `system` → `messages`) soient identiques octet par octet ; si ne serait-ce qu'un seul caractère avant le point de rupture change, l'intégralité du préfixe en cache est invalidée et réécrite. ### ❌ Mauvaise approche : placer la question variable à chaque tour avant le point de rupture ```json theme={null} { "messages": [ { "role": "user", "content": [ { "type": "text", "text": "请总结这份资料的核心观点。" }, // ← changes every turn, yet placed before the breakpoint { "type": "text", "text": "<大文档>", "cache_control": { "type": "ephemeral" } } // breakpoint ] } ] } ``` Au tour suivant, lorsque la question devient « 请列出其中的关键风险点。 », le contenu avant le point de rupture change, et le cache du grand document qui suit n'est donc plus lu. ### ✅ Bonne approche : grand document en premier + point de rupture + question en dernier ```json theme={null} { "messages": [ { "role": "user", "content": [ { "type": "text", "text": "<固定不变的大文档/参考资料，≥4096 token>", "cache_control": { "type": "ephemeral" } }, // breakpoint; prefix stays constant { "type": "text", "text": "请总结这份资料的核心观点。" } // ← the per-turn question, placed after the breakpoint ] } ] } ``` Au tour suivant, ne remplacez que ce dernier bloc de question (laissez le grand document intact) pour obtenir un hit de cache. ### Comparaison mesurée (claude-opus-4-6, quelques secondes entre les deux appels) | Approche | Ce qui a changé au 2ᵉ appel | `cache_creation` | `cache_read` | Résultat | | ---------- | ---------------------------------------------------- | ---------------- | ------------ | -------------------------------------- | | ❌ Mauvaise | Contenu **avant** le point de rupture | 19821 | **0** | Préfixe entièrement réécrit, aucun hit | | ✅ Bonne | Uniquement la question **après** le point de rupture | **0** | **19814** | Hit complet | Points clés : 1. Placez le bloc fixe et volumineux (document de référence, contexte long) tout au **début** du message utilisateur `messages`, avec `cache_control` à sa fin, et **n'en modifiez pas un seul caractère** ; 2. Placez la question/instruction variable à chaque tour **après** le point de rupture (après le grand document dans le même message `user`, ou dans les messages suivants) ; dans les conversations multi-tours, **ajoutez uniquement** — ne revenez jamais en arrière pour modifier les messages précédents ; 3. Lorsque `thinking` est activé, les blocs thinking des tours assistant précédents doivent être **renvoyés tels quels**, sinon le préfixe se brise de la même manière (voir « Ce qui ne peut pas être mis en cache » ci-dessous) ; 4. Si un bloc est plus petit que le seuil minimum de cache (de 512 à 4 096 jetons selon le modèle, voir la section « Limitations du cache » ci-dessous), il ne sera pas écrit dans le cache même s'il est marqué avec `cache_control` — c'est le comportement attendu, voir « Limitations du cache » ci-dessous. ## Tarification La mise en cache des prompts introduit une nouvelle structure tarifaire. Le tableau ci-dessous indique le prix par million de jetons pour chaque modèle pris en charge : | Modèle | Jetons d'entrée de base | Écritures cache 5 min | Écritures cache 1 h | Lectures et rafraîchissements de cache | Jetons de sortie | | ----------------- | ----------------------- | --------------------- | ------------------- | -------------------------------------- | ---------------- | | Claude Opus 4 | Tarif plateforme | 1,25x prix de base | 2x prix de base | 0,1x prix de base | Tarif plateforme | | Claude Sonnet 4 | Tarif plateforme | 1,25x prix de base | 2x prix de base | 0,1x prix de base | Tarif plateforme | | Claude Sonnet 3.7 | Tarif plateforme | 1,25x prix de base | 2x prix de base | 0,1x prix de base | Tarif plateforme | | Claude Sonnet 3.5 | Tarif plateforme | 1,25x prix de base | 2x prix de base | 0,1x prix de base | Tarif plateforme | | Claude Haiku 3.5 | Tarif plateforme | 1,25x prix de base | 2x prix de base | 0,1x prix de base | Tarif plateforme | | Claude Opus 3 | Tarif plateforme | 1,25x prix de base | 2x prix de base | 0,1x prix de base | Tarif plateforme | | Claude Haiku 3 | Tarif plateforme | 1,25x prix de base | 2x prix de base | 0,1x prix de base | Tarif plateforme | Remarques : * Les jetons d'écriture en cache (5 minutes) sont 1,25 fois le prix des jetons d'entrée de base * Les jetons d'écriture en cache (1 heure) sont 2 fois le prix des jetons d'entrée de base * Les jetons de lecture en cache sont 0,1 fois le prix des jetons d'entrée de base * Les jetons d'entrée et de sortie réguliers sont facturés aux tarifs standard de la plateforme ## Comment implémenter la mise en cache des prompts ### Modèles pris en charge Toute la gamme des modèles Anthropic Claude prend en charge la mise en cache des prompts, y compris les modèles actuels Opus 4.8 / 4.7 / 4.6 / 4.5, Sonnet 5 / 4.6 / 4.5, Haiku 4.5, Fable 5, ainsi que les modèles antérieurs Opus 4, Sonnet 4, Sonnet 3.7, Sonnet 3.5, Haiku 3.5, Haiku 3 et Opus 3. Le seuil minimum de chaque modèle figure dans la section « Limitations du cache » ci-dessous. ### Mise en cache automatique (cache\_control au niveau racine) Ajoutez un champ `cache_control` à la racine du corps de requête pour activer la mise en cache automatique : le système applique automatiquement le point de rupture de cache au dernier bloc pouvant être mis en cache et le fait avancer à mesure que la conversation s'allonge, ce qui convient à la mise en cache glissante des conversations multi-tours. Le point de rupture automatique occupe 1 des 4 emplacements de points de rupture et peut être combiné avec des points de rupture explicites au niveau des blocs. Amazon Bedrock ne prend pas en charge la mise en cache automatique. ```json theme={null} { "model": "claude-sonnet-5", "max_tokens": 1024, "cache_control": {"type": "ephemeral"}, "system": "You are an AI assistant tasked with analyzing literary works.", "messages": [ {"role": "user", "content": "Analyze the major themes in Pride and Prejudice."} ] } ``` Lorsque la limite du cache doit être contrôlée précisément, utilisez les points de rupture explicites au niveau des blocs décrits ci-dessous. ### Structuration de votre prompt Placez le contenu statique (définitions d'outils, instructions système, contexte, exemples) au début de votre prompt. Marquez la fin du contenu réutilisable à mettre 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`. À l'aide du paramètre `cache_control`, vous pouvez définir jusqu'à 4 points de rupture de cache, ce qui vous permet de mettre en cache séparément différentes sections réutilisables. Pour chaque point de rupture, le système vérifiera automatiquement les correspondances en cache aux positions précédentes et utilisera le préfixe correspondant le plus long s'il en trouve un. ### Limitations du cache La longueur minimale d'un prompt pouvant être mis en cache dépend du modèle : | Token minimum de cache | Modèles | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 512 | Claude Fable 5, Claude Mythos 5 (1 024 sur Amazon Bedrock) | | 1 024 | Claude Opus 4.8, Claude Sonnet 5, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4, Claude Sonnet 3.7, Claude Sonnet 3.5, Claude Opus 3 | | 2 048 | Claude Opus 4.7, Claude Haiku 3.5, Claude Haiku 3 | | 4 096 | Claude Opus 4.6, Claude Opus 4.5, Claude Haiku 4.5 | Les prompts plus courts ne peuvent pas être mis en cache, même s'ils sont marqués avec `cache_control`. Toute requête tentant de mettre en cache moins que ce nombre de jetons sera traitée sans mise en cache. Pour savoir si un prompt a été mis en cache, consultez les [champs](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching#tracking-cache-performance) `usage` dans la réponse. Pour les requêtes concurrentes, notez qu'une entrée de cache n'est disponible qu'après le début de la première réponse. Si vous avez besoin de hits de cache pour des requêtes parallèles, attendez la première réponse avant d'envoyer les requêtes suivantes. Durées de vie de cache actuellement prises en charge : * **« ephemeral »** : durée de vie par défaut de 5 minutes * **Cache d'1 heure** : réglez `"ttl": "1h"` dans `cache_control`, pour les scénarios nécessitant une durée de cache plus longue ### Durée de cache d'1 heure Pour les scénarios nécessitant une durée de cache plus longue, nous proposons une option de cache d'1 heure. Il suffit d'inclure `ttl` dans la définition de `cache_control`, aucun en-tête supplémentaire n'est requis : ```shell theme={null} curl https://aihubmix.com/v1/messages \ -H "content-type: application/json" \ -H "x-api-key: AIHUBMIX_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -d '{ "model": "claude-opus-4-20250514", "system": [ { "type": "text", "text": "Long-term instructions...", "cache_control": { "type": "ephemeral", "ttl": "1h" } } ], "messages": [...] }' ``` ```json theme={null} { "cache_control": { "type": "ephemeral", "ttl": "5m" | "1h" } } ``` #### Quand utiliser le cache d'1 heure Le cache d'1 heure est particulièrement adapté à : * **Traitement par lots** : traitement de gros volumes de requêtes avec des préfixes communs * **Sessions de longue durée** : conversations nécessitant le maintien du contexte sur des périodes prolongées * **Analyse de documents volumineux** : plusieurs types d'analyses différentes sur le même document * **Questions-réponses sur du code** : multiples requêtes sur la même base de code sur des périodes prolongées #### Mélanger différents TTL Vous pouvez mélanger différentes durées de cache au sein d'une même requête : ```json theme={null} { "system": [ { "type": "text", "text": "Long-term instructions...", "cache_control": { "type": "ephemeral", "ttl": "1h" } }, { "type": "text", "text": "Short-term context...", "cache_control": { "type": "ephemeral", "ttl": "5m" } } ] } ``` ### Ce qui peut être mis en cache Chaque bloc de la requête peut être désigné pour 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 : blocs de contenu dans le tableau `messages.content`, à la fois 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`, à la fois pour les tours utilisateur et assistant Chacun de ces éléments peut être marqué avec `cache_control` pour activer la mise en cache de cette portion de la requête. ### Ce qui ne peut pas être mis en cache Bien que la plupart des blocs de requête puissent être mis en cache, il existe certaines exceptions : * Les **blocs thinking** ne peuvent pas être mis en cache directement avec `cache_control`. Cependant, les blocs thinking PEUVENT être mis en cache aux côtés d'autres contenus lorsqu'ils apparaissent dans des tours assistant précédents. Lorsqu'ils sont mis en cache de cette manière, ils COMPTENT comme jetons d'entrée lorsqu'ils sont lus depuis le cache. * Les **sous-blocs de contenu** (comme les citations) ne peuvent pas être mis en cache directement. Mettez plutôt en cache le bloc de niveau supérieur. * Les **blocs de texte vides** ne peuvent pas être mis en cache. ### 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 dans l'événement `message_start` si vous utilisez le [streaming](https://docs.anthropic.com/en/api/messages-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 depuis le cache pour cette requête. * `input_tokens` : nombre de jetons d'entrée qui n'ont pas été lus depuis ou utilisés pour créer un cache. ### Bonnes pratiques pour une mise en cache efficace Pour optimiser les performances de la mise en cache des prompts : * Mettez en cache du contenu stable et réutilisable comme les instructions système, les informations de fond, les contextes volumineux ou les définitions d'outils fréquentes. * Placez le contenu mis en cache au début du prompt 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. * Analysez régulièrement les taux de succès du cache et ajustez votre stratégie au besoin. * Pour le contenu à long terme, envisagez d'utiliser le cache d'1 heure pour une meilleure efficacité des coûts. ### Optimisation selon les cas d'usage Adaptez votre stratégie de mise en cache des prompts à 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 programmation : améliorez l'auto-complé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 le prompt. * Traitement de documents volumineux : intégrez du contenu long complet, y compris des images, dans votre prompt 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 le prompt, mais avec la mise en cache des prompts, vous pouvez obtenir de meilleures performances en incluant plus de 20 exemples variés de réponses de haute qualité. * Utilisation agentique d'outils : améliorez les performances pour les scénarios impliquant plusieurs appels d'outils et modifications itératives de code, où chaque étape nécessite généralement un nouvel appel d'API. * Dialoguer avec des livres, articles, documentations, transcriptions de podcasts et autres contenus longs : donnez vie à n'importe quelle base de connaissances en intégrant l'ensemble du ou des documents dans le prompt, et permettez aux utilisateurs de poser des questions. ### Dépannage des problèmes courants En cas de comportement inattendu : * Assurez-vous que les sections mises en cache sont identiques et marquées avec cache\_control aux mêmes emplacements à travers les appels * Vérifiez que les appels sont effectués dans la durée de vie du cache (5 minutes ou 1 heure) * Vérifiez que `tool_choice` et l'utilisation des images restent cohérents entre les appels * Vérifiez que vous mettez en cache au moins le nombre minimum de jetons * Bien que le système tentera d'utiliser le contenu précédemment mis en cache aux positions antérieures à un point de rupture de cache, vous pouvez utiliser un paramètre `cache_control` supplémentaire pour garantir la recherche en cache sur les portions précédentes du prompt, ce qui peut être utile pour les requêtes contenant de très longues listes de blocs de contenu Notez que les modifications de `tool_choice` ou la présence/absence d'images n'importe où dans le prompt invalideront le cache, nécessitant la création d'une nouvelle entrée de cache. ### Stockage et partage du cache * **Isolation par organisation :** les caches sont isolés entre les organisations. Différentes organisations ne partagent jamais leurs caches, même si elles utilisent des prompts identiques. * **Correspondance exacte :** les hits de cache nécessitent des segments de prompt 100 % identiques, y compris tous les textes et images jusqu'au bloc marqué avec cache\_control (inclus). Le même bloc doit être marqué avec cache\_control lors des lectures et créations de cache. * **Génération de jetons de sortie :** la mise en cache des prompts n'a aucun effet sur la génération des jetons de sortie. La réponse que vous recevez sera identique à celle que vous obtiendriez sans la mise en cache des prompts. *** ## Activer la mise en cache Claude dans les clients / plateformes De nombreux clients n'offrent aucun champ pour renseigner directement `cache_control` ; à la place, ils l'injectent pour vous via leur propre « sucre syntaxique » ou des commutateurs. La règle sous-jacente est exactement la même que ci-dessus — **le préfixe mis en cache doit rester identique mot pour mot à chaque tour, et le contenu variable doit être placé après le point de rupture de cache** — sinon vous « écrirez sans jamais lire » (voir « Erreur courante » ci-dessus). ### Dify (via le plugin Aihubmix) Le plugin Dify d'Aihubmix hérite du sucre syntaxique du plugin officiel d'Anthropic. Activez-le en deux étapes : 1. Encadrez le prompt à mettre en cache (le prompt système fixe / le contexte long) avec `…` ; le plugin le convertira automatiquement en un point de rupture `cache_control` à cet endroit ; 2. Dans les paramètres du modèle, réglez le « seuil de mise en cache automatique des messages volumineux » sur un entier positif : le cache n'est réellement écrit qu'une fois que le contenu atteint ce seuil de jetons (toujours soumis à l'exigence de cache minimum décrite dans « Limitations du cache » ci-dessous, soit 4096 jetons pour Opus 4.5/4.6 et Haiku 4.5) ; le régler à 0 ou le laisser vide le désactive. Pour l'installation et la configuration du plugin, voir [Plugin Dify](./Dify-plugin). ### Cherry Studio Lorsque Cherry Studio appelle Claude via Aihubmix, la mise en cache est désactivée par défaut (le « Cache Token Threshold » vaut `0` par défaut) ; vous devez l'activer dans les « API Settings » du fournisseur. 1. Cliquez sur l'engrenage à droite du nom du fournisseur Aihubmix pour ouvrir les « API Settings » : Ouvrir les API Settings du fournisseur Aihubmix 2. Configurez les trois éléments suivants, et le client injectera automatiquement `cache_control` pour Claude en conséquence : * **Cache Token Threshold** : un point de rupture de cache n'est injecté qu'une fois que le contenu dépasse ce nombre de jetons (réglez un nombre positif pour activer, 0 ou vide pour désactiver) ; * **Cache System Message** : une fois activé, un point de rupture de cache est placé sur le message `system` (idéal pour mettre en cache un prompt système long et fixe) ; * **Cache Last N Messages** : place un point de rupture de cache sur les N messages les plus récents (idéal pour une mise en cache glissante dans les conversations multi-tours). Configurer Cache Token Threshold, Cache System Message et Cache Last N Messages dans les API Settings Pour les étapes de configuration, voir [Cherry Studio](../clients/Cherry-Studio). Les seuils ci-dessus déterminent uniquement « **quand le client injecte un point de rupture** » ; ils ne modifient pas l'exigence de cache minimum d'Anthropic : l'écriture effective requiert toujours que le contenu mis en cache atteigne le nombre minimum de jetons de cache (4096 pour Opus 4.5/4.6 et Haiku 4.5). Si vous placez du contenu qui change à chaque tour (comme une instruction tournante) dans le prompt système mis en cache, vous « écrirez sans jamais lire » de la même manière. *** ## Foire aux questions (FAQ) ### Pourquoi le cache est-il écrit (`cache_creation_input_tokens` élevé) mais jamais lu (`cache_read_input_tokens` à 0) ? Parce que le contenu placé avant le point de rupture de cache (`cache_control`) a changé entre deux requêtes. Un hit exige que le point de rupture et tout ce qui le précède soient identiques octet par octet ; dès que vous placez du contenu qui change à chaque tour avant le point de rupture, l'intégralité du préfixe en cache est invalidée et réécrite à chaque tour. Placez le contenu fixe en premier et le contenu variable après le point de rupture, voir « Erreur courante » ci-dessus. ### Combien de jetons faut-il au minimum pour la mise en cache ? Le contenu en dessous de la longueur minimale de cache n'est pas mis en cache, même s'il est marqué avec `cache_control`. Pour Claude Opus 4.5/4.6 et Haiku 4.5, le seuil est de 4096 jetons ; la plupart des autres modèles Claude sont à 1024 jetons, et Haiku 3/3.5 à 2048 jetons. Voir « Limitations du cache » ci-dessus. ### Combien de temps le cache reste-t-il valide ? Peut-on passer à 1 heure ? Par défaut 5 minutes, rafraîchi sans frais à chaque hit. Pour une durée plus longue, réglez `"ttl": "1h"` dans `cache_control`, aucun en-tête supplémentaire n'est requis. L'écriture en cache au palier 1 heure est facturée à 2 fois le prix d'entrée de base. Voir « Durée de cache d'1 heure » ci-dessus. ### Comment activer la mise en cache dans Dify / Cherry Studio ? Ces clients ne permettent pas de renseigner directement `cache_control` : Dify encadre le contenu à mettre en cache avec `…` et règle le « seuil de mise en cache automatique des messages volumineux » ; Cherry Studio configure « Cache Token Threshold / Cache System Message / Cache Last N Messages » dans les « API Settings ». Voir « Activer la mise en cache Claude dans les clients / plateformes » ci-dessus. *** ## Prise en charge selon les différents modèles * La prise en charge de la mise en cache des prompts dépend du modèle lui-même. * Si le modèle prend en charge nativement la mise en cache sans nécessiter de déclarations de paramètres explicites, cela peut être pris en charge via la redirection compatible OpenAI. * OpenAI prend en charge la mise en cache des prompts par défaut, avec application automatique (préfixe ≥1024 jetons). Pour les modèles antérieurs à GPT-5.6, l'écriture en cache est sans facturation supplémentaire et le cache est effacé automatiquement après 5 à 10 minutes d'inactivité ; pour GPT-5.6 et suivants, l'écriture en cache est facturée à 1,25 fois le prix d'entrée, la lecture à 0,1 fois, le cache est conservé au moins 30 minutes et les points de rupture de cache explicites sont pris en charge. Détails sur [Mise en cache des prompts GPT](/fr/api/GPT-Cache). * Claude nécessite la déclaration native `cache_control: { type: "ephemeral" }`. Le taux de mise en cache est 1,25 fois le coût d'entrée standard (5 minutes) ou 2 fois (1 heure), la récupération des jetons en cache coûte 0,1 fois le tarif normal, avec un cycle de vie de 5 minutes ou 1 heure. [Détails](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching#how-to-implement-prompt-caching) * Deepseek V3 et R1 prennent en charge nativement la mise en cache. Le taux de mise en cache est égal au coût d'entrée standard, la récupération des jetons en cache coûte 0,1 fois le tarif normal. [Détails](https://api-docs.deepseek.com/) * Gemini [prise en charge du cache implicite](https://ai.google.dev/gemini-api/docs/caching?lang=python) : * **Mise en cache implicite** : activée par défaut pour tous les modèles Gemini 2.5. Si votre requête atteint le cache, les économies de coûts sont automatiquement appliquées. Cette fonctionnalité est effective depuis le 8 mai 2025. Le nombre minimum de jetons d'entrée pour la mise en cache du contexte est de 1 024 pour Gemini 2.5 Flash et 2 048 pour Gemini 2.5 Pro. * Astuces pour améliorer le taux de succès du cache implicite : * Essayez de placer le contenu volumineux et fréquemment réutilisé au début du prompt. * Essayez d'envoyer des requêtes avec des préfixes similaires dans une courte fenêtre temporelle. * Vous pouvez voir le nombre de jetons en cache hit dans le champ `usage_metadata` de l'objet de réponse. * Les économies de coûts sont calculées sur la base des hits de cache de prefill. Seuls le cache de prefill et le cache de prétraitement vidéo YouTube sont éligibles à la mise en cache implicite. *** Dernière mise à jour : 2026-07-10