Pro Max 5x de Claude Code : le quota s’épuise en 1,5 heure même avec un usage modéré

• Avec l’abonnement Pro Max 5x (contexte 1M), un niveau modéré de Q&A et de travail de développement suffit à provoquer un dépassement de la limite de tokens en 1,5 heure
• Une erreur où les tokens cache_read sont comptabilisés au taux plein (1.0x) est pointée du doigt, ce qui annule l’effet du cache et entraîne une consommation brutale
• Les appels automatiques de sessions en arrière-plan, la compression automatique (auto-compact) et les entrées de grand contexte accélèrent ensemble la vitesse de consommation
• La communauté analyse surtout le raccourcissement du TTL du cache (1 heure → 5 minutes) et le phénomène de cache invalidation (cache busting) comme causes principales
• Anthropic travaille sur une réduction du contexte par défaut (400k), des améliorations UX et une optimisation des appels inactifs, tout en recueillant les retours des utilisateurs

---

Problème d’épuisement rapide du quota sur l’abonnement Pro Max 5x

• Sur l’abonnement Pro Max 5x (claude-opus-4-6, contexte 1M), des cas d’épuisement du quota en 1,5 heure malgré un usage intermédiaire en Q&A et en développement léger ont été signalés
  • Lors d’une session précédente de 5 heures de développement intensif, la consommation était normale, mais après réinitialisation, l’épuisement s’est brusquement accéléré
  • L’environnement concerné était Claude Code CLI sur WSL2, dans une session unique (avec 2 compressions automatiques)
• L’erreur de calcul des tokens cache_read au taux plein (1.0x) est désignée comme cause principale
  • Normalement, cache_read devrait être comptabilisé au ratio de 1/10 ; sinon, l’effet du cache disparaît
  • L’usage des tokens a été analysé à partir de l’objet usage dans les logs de session (~/.claude/projects/.../*.jsonl)
• Les appels automatiques des sessions en arrière-plan, le coût élevé du traitement auto-compact et les gros envois liés à la fenêtre de contexte 1M se combinent pour accélérer la consommation
• D’après l’analyse de la communauté, certains utilisateurs désignent surtout le TTL du cache raccourci (1 heure → 5 minutes) et le phénomène de cache invalidation (cache busting) comme causes majeures
• L’équipe Anthropic travaille sur une réduction du contexte par défaut (400k), des améliorations UX et une optimisation des appels inactifs, et demande davantage de données via les retours utilisateurs

Consommation de tokens mesurée

• Fenêtre 1 (15:00–20:00, 5 heures, développement intensif)

  • 2 715 appels API, Cache read 1 044M, Cache create 16.8M, sortie 1.15M tokens
  • Entrée effective (avec ratio 1/10 appliqué) : 121.8M tokens
  • Réalisation d’un serveur Express + app iOS, d’un pipeline graphify et d’une coordination multi-agent basée sur SPEC

• Fenêtre 2 (20:00–21:30, 1,5 heure, usage intermédiaire)

  • Session principale (vibehq) : 222 appels API, Cache read 23.2M, Cache create 1.4M, sortie 91k
  • Sessions en arrière-plan (dont token-analysis, career-ops) : 691 appels au total, Cache read 103.9M, sortie 387k
  • Total de 13.1M tokens effectifs (avec ratio 1/10) → normalement, aucun dépassement de quota
  • En pratique : 105.7M tokens (avec calcul en 1.0x) → soit 70.5M par heure, cohérent avec l’épuisement du quota

Résumé des principaux problèmes

• 1. Erreur de calcul de la limite de facturation pour les tokens Cache read

  • Attendu : cache_read compté avec un ratio de 1/10
  • Réel : compté au taux plein, ce qui annule l’effet du cache
  • Dans un environnement à contexte 1M, 100 à 960k tokens sont envoyés par appel, ce qui peut vider le quota en quelques minutes au-delà de 200 appels

• 2. Consommation du quota partagé par les sessions en arrière-plan

  • Même les sessions inactives (token-analysis, career-ops, etc.) continuent de consommer le quota partagé via la compression automatique et les appels de post-traitement

• 3. Appels coûteux de la compression automatique (auto-compact)

  • Avant compression, l’intégralité du contexte (~966k tokens) est envoyée comme cache_creation, ce qui déclenche automatiquement l’appel le plus coûteux

• 4. Effets de bord de la fenêtre de contexte 1M

  • Un grand contexte augmente fortement le nombre de tokens par appel et accélère la vitesse d’épuisement du quota

Procédure de reproduction

1. Lancer Claude Code avec le modèle Opus sur l’abonnement Pro Max 5x
2. Inclure environ 30 fichiers de règles dans ~/.claude/rules/ (surcoût d’environ 19k tokens)
3. Effectuer des tâches centrées sur les outils, comme lecture de fichiers, build et tests
4. Vérifier l’augmentation du contexte avec la commande /context
5. Constater la chute rapide du quota après 200 à 300 appels
6. Garder 2 à 3 sessions ouvertes dans d’autres terminaux
7. Constater que le quota s’épuise à nouveau rapidement même après réinitialisation

Comparaison entre comportement attendu et comportement réel

• Attendu :

  • cache_read est compté avec un ratio de 1/10
  • Les sessions inactives ne consomment qu’un minimum
  • La compression automatique ne provoque pas de surconsommation excessive
  • Un usage intermédiaire devrait permettre de tenir 2 à 3 heures

• Réel :

  • Quota épuisé en 1,5 heure
  • Les sessions en arrière-plan représentent 78 % de la consommation
  • Un total de 105.7M tokens transmis laisse supposer que cache_read est compté au taux plein

Propositions d’amélioration

1. Clarifier le mode de calcul de cache_read — indiquer explicitement dans la documentation le ratio réellement utilisé pour la limite de facturation
2. Limiter selon les tokens effectifs — corriger le calcul pour que cache_read soit compté avec un ratio de 1/10
3. Détection des sessions inactives — empêcher les appels automatiques des sessions inactives ou afficher un avertissement
4. Visualisation en temps réel de la consommation de tokens — afficher l’usage séparé de cache_read, cache_create, des entrées et des sorties
5. Prévision du coût selon le contexte — afficher le coût estimé en tokens avant l’exécution d’une tâche

Analyse et discussion de la communauté

• cnighswonger

  • A collecté pendant 24 heures des données sur 1 500 appels avec l’intercepteur claude-code-cache-fix
  • En testant trois hypothèses (cache_read à 0.0x, 0.1x, 1.0x), seul le modèle 0.0x a produit des résultats cohérents sur une fenêtre de 5 heures (CV 34.4 %)
  • Conclusion : cache_read a en pratique très peu d’impact sur le quota, le cache fonctionnerait normalement
  • Mais des vérifications supplémentaires sont nécessaires, car les données proviennent d’un seul compte

• henu-wang

  • Depuis une régression réduisant le TTL du cache de 1 heure à 5 minutes, chaque reprise de session déclenche cache_create, ce qui multiplie le coût par 12,5
  • Plus le contexte s’allonge, plus le coût augmente de manière non linéaire
  • Comme solution temporaire, il recommande de garder des sessions courtes, utiliser activement la commande /compact et précharger le contexte essentiel dans CLAUDE.md

• bcherny (équipe Anthropic)

  • Reconnaît que les ratés du prompt cache sont coûteux avec une fenêtre de contexte de 1M
  • Expérimente des améliorations UX (inciter à utiliser /clear lors de la reprise de longues sessions) et une réduction du contexte par défaut à 400k
  • A confirmé des cas où des tâches inactives consomment trop de tokens avec des agents multiples ou des plugins, et travaille à améliorer le nettoyage automatique et l’ordonnancement

• wadabum

  • Signale un bug où le cache ne fait aucun hit dans une nouvelle session (#47098, #47107)
  • Le prompt système basé sur git status et les blocs CLAUDE.md changent à chaque session, provoquant une cache invalidation (cache busting)
  • cnighswonger répond que l’intercepteur stabilise partiellement l’ordre des éléments, mais que le problème git-status nécessite une correction distincte

Résumé des propositions de la communauté

• RockyMM : quand une session atteint sa limite, proposer une reprise après résumé automatique et réduire le TTL à 10 minutes
• mikebutash : rapporte qu’avec l’abonnement Pro, il ne pouvait envoyer que 2 prompts par tranche de 5 heures ; il constate une amélioration de 3 à 4x après retour à la version v2.1.81 et installation de cache-fix
• wutlu : atténue le problème en réinitialisant les sessions selon les tâches
• dprkh : aide à identifier la cause en partageant des skills de mode debug (Skill.md)

Conclusion

• Le problème d’épuisement rapide du quota sur Pro Max 5x résulte d’une combinaison de comportement du cache, de régression du TTL, d’expansion du contexte et d’appels en arrière-plan
• La communauté estime que la cause principale n’est pas une erreur de calcul de cache_read, mais plutôt la cache invalidation et la réduction du TTL
• L’équipe Anthropic travaille sur une réduction du contexte par défaut, une amélioration de l’UX du cache et une optimisation des appels inactifs, et demande des données supplémentaires via les retours utilisateurs (/feedback)