Claude Code et le cache de prompts : comment éviter de brûler vos quotas trop vite

Le problème : un cache réduit de 1h à 5 minutes

Anthropic a discrètement modifié le TTL (time to live) du cache de prompts de Claude Code : celui-ci est passé de 1 heure à 5 minutes pour de nombreuses requêtes, aux alentours du 7 mars 2026. Ce changement, rapporté initialement par le développeur Sean Swanson via un bug report, a provoqué une vague de plaintes d'utilisateurs constatant que leurs quotas s'épuisaient bien plus rapidement qu'auparavant.

Anthropic maintient que cette modification ne devrait pas augmenter les coûts. Pourtant, pour les sessions longues et à contexte élevé — précisément le cas d'usage typique de Claude Code — un TTL de 5 minutes est particulièrement pénalisant. Chaque rotation de cache force le modèle à retraiter un contexte potentiellement volumineux (code existant, instructions système, historique de la session), ce qui consomme davantage de tokens.

Ce type d'incident rappelle une réalité souvent sous-estimée : la gestion du cache et de la fenêtre de contexte est un levier critique pour maîtriser coûts et quotas lors de l'utilisation d'assistants IA dans un workflow de développement.

Comprendre le prompt caching et son impact

Le prompt caching permet d'éviter de retraiter des portions de prompts déjà envoyés — contexte de code, instructions système, background d'un projet. Sans cache efficace, chaque requête dans une longue session refacture l'intégralité du contexte en tokens d'entrée.

Concrètement, imaginez une session Claude Code avec 10 000 tokens de contexte (code source, README, conventions du projet). Avec un cache de 1h, ce contexte n'est facturé qu'une fois par heure. Avec un TTL de 5 minutes et des échanges toutes les 2-3 minutes, le contexte peut être refacturé plusieurs fois en une heure, multipliant la consommation de tokens par un facteur significatif.

Pour les utilisateurs sous quota (abonnement Pro ou API avec limites de tokens), l'effet est immédiat : des sessions interrompues prématurément, des workflows d'agents IA tronqués.

4 stratégies pratiques pour maîtriser vos coûts et quotas

1. 🗂️ Checkpointing d'état et découpage des sessions

Ne travaillez pas en une seule session de plusieurs heures. Découpez vos tâches en sessions courtes et ciblées, chacune avec un contexte minimal et précis.

• Sauvegardez régulièrement l'état de votre conversation (résumé des décisions prises, code généré, prochaines étapes) dans un fichier texte ou un ticket.
• Au redémarrage d'une session, injectez uniquement ce résumé plutôt que l'intégralité de l'historique.
• Cette approche réduit la taille du contexte réinjecté et s'adapte naturellement à un TTL court.

2. 🧹 Compression de contexte et embeddings

Plus votre contexte est volumineux, plus l'impact d'un cache manqué est coûteux. Quelques pratiques pour l'alléger :

• Ne passez que le code pertinent pour la tâche en cours, pas l'intégralité du projet.
• Utilisez des résumés générés (par une requête LLM peu coûteuse) plutôt que des fichiers bruts complets.
• Pour les grandes bases de code, envisagez une approche RAG (Retrieval-Augmented Generation) : indexez votre code avec des embeddings et ne récupérez que les fragments réellement utiles à chaque requête. Des outils comme pgvector (PostgreSQL) ou Chroma s'intègrent bien dans un écosystème PHP/Symfony.

3. 📊 Instrumentation token-level : mesurez avant d'optimiser

Vous ne pouvez pas optimiser ce que vous ne mesurez pas. La plupart des SDK Anthropic renvoient les métriques d'usage dans chaque réponse API :

{
  "usage": {
    "input_tokens": 8500,
    "cache_read_input_tokens": 7200,
    "cache_creation_input_tokens": 0,
    "output_tokens": 312
  }
}

Loguez systématiquement ces valeurs. Un ratio cache_read_input_tokens / input_tokens qui chute est le signe que votre cache expire trop souvent. Vous pouvez construire un dashboard simple (même en Symfony avec des logs structurés vers Grafana ou un simple fichier CSV) pour visualiser votre consommation au fil du temps.

4. ⏱️ Adapter votre cadence aux contraintes du TTL

Avec un TTL de 5 minutes, adaptez simplement votre rythme de travail :

• Groupez vos échanges avec Claude Code en rafales courtes et intenses plutôt qu'en sessions étalées avec de longues pauses.
• Si vous travaillez sur une tâche longue, préférez des allers-retours fréquents (toutes les 2-3 minutes) pour maintenir le cache actif plutôt que de laisser une session inactive expirer.
• Configurez des rappels ou timers si vous utilisez Claude Code dans un workflow automatisé (n8n, scripts CI/CD) pour éviter les gaps qui invalident le cache.

Conclusion : la transparence des coûts, un enjeu de production

L'incident Claude Code est révélateur d'une problématique plus large : les changements silencieux de comportement des LLM en production peuvent avoir des conséquences directes sur vos budgets et vos SLA. Une réduction de TTL de cache, aussi technique qu'elle paraisse, se traduit immédiatement en euros supplémentaires ou en sessions interrompues pour vos utilisateurs.

Que vous utilisiez Claude Code, l'API Anthropic directement, ou tout autre fournisseur LLM dans vos projets Symfony/PHP, l'observabilité token-level n'est plus optionnelle dès que vous passez en production. Traitez vos appels LLM comme n'importe quelle ressource coûteuse : mesurez, alertez, optimisez.

Source : The Register — Claude Code cache chaos creates quota complaints, Tim Anderson, 13 avril 2026.