Les agents de codage et les assistants multi-tours renvoient souvent le même prompt système, les mêmes définitions d’outils et le même préfixe de conversation. Le caching peut réduire le coût de ces tokens d’entrée répétés, mais uniquement lorsque le modèle, le endpoint et la structure de la requête le prennent en charge. Il ne réduit pas le coût de la sortie générée, et la répétition d’un texte similaire ne suffit pas si la clé de cache change. Ce guide distingue le chemin automatique de type OpenAI du comportement explicite par points de rupture de Claude.
Qu’est-ce qui change sur la facture ?
Une lecture depuis le cache est facturée au tarif des entrées mises en cache plutôt qu’au tarif ordinaire des entrées. Le catalogue des modèles GetVibe publie la prise en charge du cache et les tarifs associés parallèlement aux tarifs des modèles. Dans l’instantané du catalogue consulté le 3 octobre 2026, on trouve notamment $0.0055 entrée · $0.0274 sortie par million de tokens pour GPT-6 Luna et $0.168 entrée · $0.84 sortie par million de tokens pour Claude Sonnet 5.5. Ces valeurs tarifaires sont générées à partir des pages de modèles en temps réel. Consultez également les détails du cache à cet endroit ; ne supposez pas que tous les modèles utilisent le même multiplicateur ou la même politique d’écriture.
Pour un préfixe répété, une estimation simple consiste à comparer le nombre de tokens d’entrée répétés multiplié par le tarif normal des entrées au nombre de tokens d’entrée répétés multiplié par le tarif des lectures depuis le cache. La différence correspond à l’économie potentielle sur les entrées. Soustrayez tout coût d’écriture dans le cache si ce modèle en facture un. L’utilisation observée de la requête est nécessaire pour transformer cette estimation en résultat mesuré.
Modèles compatibles OpenAI : gardez le préfixe stable
Pour les routes prises en charge de la famille OpenAI, le caching est automatique. Il n’y a aucun champ de contrôle du cache à ajouter dans une requête Chat Completions standard. Le début répété doit rester identique. Placez les instructions système, les exemples stables et les définitions d’outils avant les valeurs spécifiques à l’utilisateur. Évitez de placer des horodatages, des identifiants aléatoires ou des indicateurs de fonctionnalité propres à chaque requête au début. Conservez un ordre déterministe pour les outils.
Ne réécrivez pas les tours de conversation précédents lorsque vous poursuivez une session d’agent si vous souhaitez que le même préfixe corresponde. Ajoutez les nouveaux tours à la suite. Changer de modèle démarre un cache de modèle différent. Une requête peut être valide tout en indiquant zéro token mis en cache, parce que le préfixe est inférieur au seuil de mise en cache du modèle ou que le cache a expiré.
Claude : points de rupture et endpoint Messages
Le caching de Claude utilise des points de rupture contrôlés par le cache. L’intégration GetVibe peut insérer un point de rupture lorsqu’il en manque un dans les requêtes Claude prises en charge ; si vous gérez vous-même les points de rupture, consultez la documentation actuelle sur le caching et conservez le marqueur sur une section stable. Claude Code utilise l’endpoint Anthropic Messages ; le guide d’intégration de Claude Code présente son URL de base et ses identifiants.
curl https://getvibeapi.com/v1/messages \
-H "x-api-key: $GETVIBE_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-sonnet-5.5",
"max_tokens": 300,
"system": [{"type":"text","text":"Stable instructions shared by every request."}],
"messages": [{"role":"user","content":"A request-specific question."}]
}'Cet exemple présente une section système stable et un message utilisateur variable. Consultez la documentation actuelle pour connaître le champ de point de rupture exact pris en charge par votre client et votre modèle.
Vérifiez qu’un accès au cache a eu lieu au lieu de le supposer
Envoyez deux fois le même long préfixe en ne modifiant qu’un court suffixe. Inspectez l’utilisation indiquée dans la réponse. Les réponses au format OpenAI indiquent les entrées mises en cache dans prompt_tokens_details.cached_tokens ; les réponses au format Anthropic exposent les champs de lecture et de création du cache. La page d’utilisation du compte peut également afficher des informations sur le caching. Si ces compteurs restent à zéro, vérifiez l’égalité du préfixe, la longueur minimale pouvant être mise en cache, la prise en charge par le modèle et l’éventuel changement de route sélectionnée.
Utilisez un échantillon suffisamment grand pour dépasser le seuil de mise en cache du modèle. Un prompt système d’une seule phrase peut ne produire aucune différence visible. Comparez plusieurs appels répétés, car la durée de vie du cache et la planification des requêtes déterminent si un préfixe est toujours présent en cache.
Un test pratique des économies
- Choisissez un prompt réel avec un préfixe réutilisable suffisamment conséquent.
- Notez son utilisation ordinaire des entrées et les tarifs actuels indiqués sur la page du modèle.
- Répétez-le en ne modifiant que le suffixe utilisateur.
- Vérifiez que la réponse indique des entrées mises en cache.
- Comparez le coût inscrit dans le registre pour les requêtes répétées.
Conservez une longueur de sortie similaire pendant l’expérience afin que les dépenses de sortie ne masquent pas la variation des entrées. Ne revendiquez pas d’économies à partir du seul multiplicateur du cache ; vérifiez le nombre d’accès au cache et l’utilisation facturée.
Causes courantes d’échec du cache
- Un horodatage ou un identifiant de requête apparaît avant les instructions stables.
- Les définitions d’outils sont sérialisées dans un ordre différent à chaque requête.
- L’application modifie les espaces ou tronque l’historique différemment.
- Le modèle change d’un tour à l’autre.
- Le préfixe est trop court ou la fenêtre du cache a expiré.
Lorsque le caching fonctionne, il peut rendre les longues conversations avec un agent plus économiques, mais ce n’est pas une raison pour envoyer du contexte de dépôt inutile. Gardez des prompts ciblés et évaluez le coût total de la tâche. Pour plus de détails sur les endpoints, consultez le guide d’implémentation du caching et la page tarifaire actuelle du modèle.
Placez les points de rupture là où ils peuvent être réutilisés
Pour un prompt au format Messages, conservez les instructions stables et les documents de référence dans le bloc système, puis placez la question variable dans le message utilisateur. Un point de rupture du cache doit se trouver à la fin de la partie stable, et non après un horodatage propre à la requête. Si le contexte comprend plusieurs documents volumineux, placez les points de rupture dans les parties réutilisées entre les appels et vérifiez le nombre de points de rupture pris en charge par le modèle.
Soyez prudent avec les agents qui résument leur propre historique. Si chaque tour réécrit la conversation précédente, le préfixe change et un accès au cache peut disparaître même si la conversation globale semble similaire pour une personne. Lorsque vous recherchez la cause d’un échec, comparez le corps de la requête sérialisé, tout en excluant les contenus privés des journaux.
Tenez compte des écritures dans le cache et des longueurs minimales
Certains modèles exigent une longueur minimale de préfixe avant que la mise en cache ne s’applique, et une première écriture peut être facturée différemment d’une lecture ultérieure. Un prompt court peut donc ne générer aucune économie. Vérifiez les tarifs actuels de lecture et d’écriture du cache du modèle ainsi que le seuil de tokens pouvant être mis en cache. Comparez ensuite séparément la première requête et les requêtes suivantes au lieu de les regrouper en un seul chiffre inexpliqué.
La disponibilité du cache dépend du temps. Un préfixe peut expirer après une période d’inactivité, et le cache n’est pas un stockage durable pour les données de l’application. Ne comptez jamais sur lui pour conserver l’état d’une conversation ; continuez à envoyer le contexte nécessaire pour obtenir une réponse correcte.
Distinguez les économies du cache de l’optimisation du prompt
Réduire le contexte dupliqué et mettre en cache le contexte répété sont deux améliorations différentes. Commencez par supprimer les instructions sans rapport, les exemples obsolètes et les journaux copiés. Mettez ensuite en cache les éléments stables restants. Le prompt reste ainsi plus court même en cas d’échec du cache, et vous évitez de payer de manière répétée pour du contexte inutilisé.
Lorsque vous évaluez une modification du prompt, gardez les exemples de tâche identiques. Un préfixe plus court peut réduire le coût, mais aussi supprimer des informations dont le modèle a besoin. Mesurez la qualité des sorties conjointement à l’utilisation mise en cache et non mise en cache afin que l’optimisation ne compromette pas invisiblement l’exactitude.