# Quand le prompt caching réduit-il réellement le coût d’un agent de code ? > Le prompt caching réduit les coûts lorsque de nombreuses requêtes réutilisent un préfixe volumineux et stable au niveau des octets, et que l’économie des lectures dépasse la complexité et les échecs. Mesurez l’entrée mise en cache dans les relevés réels au lieu de supposer une remise sur toute instruction répétée. Le prompt caching est utile lorsque l’agent renvoie souvent le même long début, pas seulement lorsque les prompts se ressemblent pour un humain. Un horodatage, une liste d’outils réordonnée, un résumé variable ou un ID généré près du début peut supprimer la réutilisation de tout ce qui suit. Avant de modifier les prompts, inspectez les métadonnées d’usage réelles. Déterminez combien de tokens sont éligibles, combien sont signalés comme lectures, à quelle fréquence le préfixe change et si le modèle et le protocole offrent un avantage. ## Modélisez la base sans cache Commencez par le coût d’entrée, car le cache ne réduit ni la sortie ni l’exécution des outils. ```text uncached_input_cost = requests * input_tokens_per_request * input_rate ``` Gardez des unités cohérentes, généralement par million de tokens. N’utilisez pas une remise mémorisée : consultez le tarif actuel et les champs d’usage du modèle exact. | Composant | Stable entre requêtes ? | Position probable | |---|---|---| | Politique système | Généralement | Première | | Schémas d’outils | Généralement | Au début | | Conventions du dépôt | Souvent | Au début | | Point de contrôle | Parfois | Au milieu | | Requête utilisateur | Rarement | Vers la fin | | Sortie d’outil | Non | Dernière | ## Calculez le seuil avec des symboles Soit `P` le nombre de tokens du préfixe, `R` le nombre de requêtes, `W` le tarif d’écriture, `H` celui de lecture et `U` le tarif ordinaire : ```text uncached = R * P * U cached = P * W + (R - 1) * P * H savings = uncached - cached ``` Ce cas idéal suppose que toutes les requêtes suivantes réussissent. Pour une fraction mesurée `h`, remplacez le terme suivant par une combinaison pondérée de `H` et `U`. Ajoutez les tokens hors préfixe au tarif ordinaire des deux côtés. Le cache n’est rentable que si l’économie reste positive après les échecs et l’effort d’ingénierie. ## Placez le contenu stable en premier Construisez du plus stable au plus volatil : * Instructions système et sécurité. * Définitions d’outils dans un ordre déterministe. * Conventions et références durables. * Point de contrôle compact. * Requête actuelle. * Dernière sortie d’outil. Sérialisez les schémas de façon déterministe. Évitez l’ordre aléatoire, les changements d’espaces, les dates et commentaires spécifiques. Versionnez les blocs stables afin qu’une vraie modification produise un échec explicable. ## Gardez le préfixe utile, pas seulement long Un préfixe gonflé peut augmenter les lectures tout en consommant davantage de tokens et d’attention. Supprimez les outils obsolètes, politiques dupliquées et références sans rapport. Mesurez le coût par résultat accepté, pas seulement le taux de réussite. Un prompt court sans cache qui résout la tâche en moins de tours peut être préférable à un préfixe long et bruyant. ## Instrumentez les requêtes et les résultats Enregistrez modèle, protocole, version du préfixe, tokens totaux, tokens mis en cache s’ils existent, sortie, latence, appels, tentatives et résultat. Marquez les champs absents comme indisponibles, pas comme zéro. | Mesure | Utilité | |---|---| | Part mise en cache | Confirme la réutilisation réelle | | Motif de l’échec | Détecte les changements accidentels | | Requêtes par tâche | Révèle les boucles annulant l’économie | | Coût par modification acceptée | Relie les tokens au travail utile | | Taux de tentative | Montre les coûts de fiabilité externes | Une semaine de tâches représentatives vaut mieux que cent répétitions d’un prompt synthétique. ## Surveillez les routes et les limites de session Le cache peut dépendre du modèle, fournisseur, de la région, de la rétention et du routage. Une gateway ou un fallback peut envoyer la requête vers une route sans le même préfixe chaud. Traitez les performances comme une propriété observée de la route choisie. Atlas Cloud propose plusieurs formats LLM via une API, mais son guide public ne promet pas de remise universelle. Consultez le modèle et la console avant d’affirmer une économie. Utilisez les [protocoles LLM](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) pour choisir le format et le [catalogue](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) pour les modèles actuels. ## Évitez les fausses économies Une entrée moins chère peut masquer des tours supplémentaires, des outils en échec ou des reconstructions répétées. Distinguez aussi lecture de cache et stockage ou récupération applicative : ils résolvent des problèmes différents. N’incluez pas de secrets parce que le contenu peut être mis en cache. Respectez les contrôles de données et de rétention ; le cache ne remplace pas le contrôle d’accès. ## Utilisez une porte d’adoption pratique Adoptez cette technique lorsque : * Le préfixe stable est utile et souvent réutilisé. * L’usage réel signale des lectures de cache. * L’économie résiste au taux d’échec observé. * Le versionnage est simple et déterministe. * La qualité et le nombre de tours ne se dégradent pas. Sinon, réduisez d’abord le prompt, ne récupérez que les fichiers pertinents et raccourcissez la boucle. ## Conclusion Le prompt caching réduit les coûts lorsqu’un préfixe long, utile et stable est assez réutilisé sur une route facturant moins l’entrée stockée. Placez le stable en premier, calculez le seuil avec les tarifs actuels, instrumentez les tâches réelles et mesurez le coût par modification acceptée. Un taux élevé ne suffit pas si le prompt est trop grand ou exige davantage de tours. ## FAQ ### Quel contenu convient le mieux au prompt caching ? Les instructions système stables, schémas d’outils, conventions du dépôt et références peu changeantes conviennent mieux que les logs en direct ou le dernier message utilisateur. ### Pourquoi placer le contenu variable après le préfixe stable ? Les caches de préfixe exigent généralement un début identique. Un horodatage, un ID ou un contexte variable placé tôt peut invalider tout le contenu stable suivant. ### Le prompt caching réduit-il toujours la latence ? Non. L’effet dépend de l’implémentation, de l’état du cache, de la route, du modèle, de la taille et de la charge. Mesurez la latence séparément du coût. ### Comment calculer le seuil de rentabilité ? Comparez le coût d’entrée normal aux coûts d’écriture et de lecture du cache pour la réutilisation prévue, puis ajoutez le coût d’ingénierie et le taux d’échec. ### Les définitions d’outils peuvent-elles être mises en cache ? Elles peuvent faire partie d’un préfixe répété si le fournisseur et le protocole les incluent. Vérifiez les métadonnées d’usage au lieu de le supposer. ### Faut-il mettre en cache toute la conversation de code ? Généralement non. Elle change à chaque tour. Placez d’abord les instructions et schémas stables, puis un point de contrôle compact et la requête actuelle.