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)

[kimjoin2]

En termes de qualité, il n’y a rien pour le remplacer.
J’aimerais qu’on puisse l’utiliser davantage, ne serait-ce qu’avec un simple correctif.

[GN⁺]

Réactions sur Hacker News

• Boris de l’équipe Claude Code ici. Après enquête sur les problèmes signalés récemment, les deux causes principales semblent être les suivantes

  1. Les ratés du cache de prompt sont coûteux lors de l’utilisation de la fenêtre de contexte de 1M de tokens. Le TTL du cache est actuellement d’1 heure, donc si vous vous absentez plus d’une heure, la session expire et il faut recharger l’intégralité du cache. Nous avons déployé des améliorations UX pour corriger cela et envisageons une option abaissant la valeur par défaut à 400k. Pour le tester dès maintenant, utilisez la commande CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude
  2. Exécuter trop de plugins ou d’agents en même temps gaspille des tokens. Pour y remédier, nous travaillons sur des améliorations UX ainsi que sur le nettoyage automatique et l’ordonnancement des tâches non essentielles
     Si vous rencontrez le problème, envoyez un retour via la commande /feedback, cela nous aide pour le débogage
  • Boris, les retours d’expérience utilisateurs qui remontent dans la communauté ne sont pas de simples exceptions. Comme le disait Jeff Bezos, il arrive que les anecdotes disent la vérité plutôt que les données. Il faut sérieusement envisager que les métriques soient fausses
  • Je me demandais pourquoi ce problème était apparu soudainement, puis j’ai découvert que la cause était la réduction du TTL du cache de prompt d’1 heure à 5 minutes. Même en redémarrant la session, il faut de toute façon tout reconstruire, ce qui est inefficace. Une architecture où il faut surveiller l’expiration du cache va à l’encontre de la philosophie de CC
  • Dans mon cas, la régression la plus grave venait du fait que le prompt système essayait à chaque fois de scanner les fichiers à la recherche de malware. Ça consommait les tokens à toute vitesse, avec des réponses répétées du type « not a malware ». C’est une très mauvaise décision de conception. J’ai fini par abandonner le projet et passer à Qwen, et ça se passe plutôt bien
  • La notification /clear n’est pas une solution. Vider le cache oblige de toute façon à le reconstruire, donc le coût reste identique. Pousser les utilisateurs via l’UX à adopter un petit contexte revient à dégrader la qualité du service. Si le problème est le coût, il faut revoir le prix ou l’architecture
  • OpenAI réinitialisait les limites d’usage quand il y avait un problème, alors qu’Anthropic ne fait rien de tel. Cette fois, ça donne l’impression que c’est intentionnel

• Ces derniers temps, Claude était visiblement plus lent et plus inefficace. Même en lui indiquant les fichiers, il partait dans des boucles d’exploration de plus de 5 minutes, puis atteignait vite la limite de session. Trois utilisations par jour suffisent à faire disparaître 25 % du quota hebdomadaire. Je suis donc passé au forfait Codex à 100 $, qui est bien meilleur en termes de précision et de générosité. En revanche, le ton de Codex m’agace, donc j’ai ajouté des consignes spécifiques dans Agents.md. L’ergonomie de l’ancien Claude Code me plaisait davantage, mais pour le débogage backend et la résolution de problèmes complexes, Codex est devant. Pour l’instant, je recommande de comparer Codex et l’offre Cursor à 20 $

  • J’ai eu une expérience similaire. Il y a quelques jours, Claude semblait bloqué dans ses pensées, puis le lendemain il fonctionnait normalement
  • J’utilise l’offre Codex Business (30 euros) et j’ai l’impression que le quota a récemment diminué. Malgré tout, les conditions restent bien meilleures que pour Claude Code
  • Je compare en ce moment le fonctionnement du confidence score sur les modèles Opus, Haiku et Sonnet. Opus est le plus efficace sur les tâches de difficulté intermédiaire
  • J’ai testé CC, Gemini-cli et Codex, et CC reste malgré tout le meilleur. Je me demande si une combinaison Cursor ou Aider serait encore supérieure
  • Le code assisté par IA gaspille énormément de contexte, donc limiter le périmètre avec un sandbox personnalisé améliore l’efficacité

• En parcourant les issues, je comprends pourquoi Anthropic les ferme si vite. La plupart ressemblent à du bruit généré par IA. Voici la solution que j’ai adoptée

  1. Activer max thinking dans toutes les sessions pour réduire l’exploration de chemins inutiles
  2. Garder la session active en permanence. Si le cache expire au bout de 5 minutes, il faut reconstruire les tokens
  3. Lancer compact dès qu’on dépasse 200k tokens
     Ce qui m’agace le plus, c’est qu’Anthropic ait imposé de force le modèle 1M
  • J’ai vu cette issue et ça m’a fait rire. On dirait le résultat de quelqu’un qui a demandé à Claude Code « enquête sur les raisons pour lesquelles tous les tokens ont été consommés »
  • Certains disent d’activer thinking, d’autres de le désactiver. C’est ironique que les deux soient présentés comme des moyens d’économiser des tokens
  • Le cœur du problème, c’est un bug où le cache est invalidé aléatoirement. Le client API semble interrompre prématurément le cache des abonnés. En plus, ils ont discrètement augmenté le coût des tokens en entrée
  • Je confirme aussi. max effort aide. L’important est de garder le contexte sous les 25 %. Je me demande s’il existe un moyen de voir l’état d’expiration du cache
  • Les commandes /model opus ou /model sonnet permettent de désactiver le modèle 1M

• On dirait que la fin de l’ère des subventions approche. Dans la communauté Google Gemini aussi, les plaintes explosent récemment à cause de la réduction des quotas (lien vers l’issue). J’ai fini par passer à une combinaison Kiro IDE + Codex CLI, et j’en suis satisfait

  • Ce genre d’évolution était prévisible. La bonne stratégie était de constituer à l’avance les bibliothèques nécessaires pendant l’époque des tokens gratuits
  • Anthropic est désormais en train de se recentrer sur les clients entreprise, et OpenAI suit une trajectoire similaire. Sur Reddit et Discord, on voit des gens chercher des modèles ouverts ou des alternatives chinoises, mais il n’existe pas encore de substitut complet
  • antigravity consomme vite le quota pro, mais le mode flash est bien plus généreux. Sur un projet STM32, j’ai obtenu une productivité 3 fois supérieure
  • À la fin de cette tendance, on finira peut-être avec de la publicité dans les sorties
  • Ça me rappelle les trajets Uber à 3 $

• Le fait que l’issue identifiant la cause racine du problème ait été fermée avec le statut « Not planned » est inquiétant

  • La réponse a l’air artificielle, comme écrite par une IA. L’argument selon lequel « un TTL d’1 heure coûte plus cher » semble bizarre aussi. Et invoquer le coût pour ne pas proposer un simple interrupteur est difficile à accepter
  • Pas besoin d’en avoir peur. Si la qualité baisse, il suffit d’arrêter de l’utiliser
  • J’ai l’impression qu’Anthropic vend des tokens comme un casino, sans se soucier que les utilisateurs y perdent de l’argent. Si ce modèle ne vous plaît pas, mieux vaut passer à un LLM local

• En revenant à la version 2.1.34, la plupart des problèmes de quota et de cache ont disparu.
  J’ai ajouté "effortLevel": "high", "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1, etc. dans ~/.claude/settings.json, puis supprimé les autres versions.
  Adaptive thinking reste encore imparfait, mais pourrait devenir utile à l’avenir si ça s’améliore. Malgré tout, j’envisage quand même de passer à Codex

  • J’ai aussi configuré dans ~/.bashrc des variables comme CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000 et DISABLE_AUTOUPDATER=1

• J’ai rencontré des problèmes similaires sur les modèles inférieurs aussi. Je pense qu’une relation commerciale équitable commence par des mesures transparentes. Je vais annuler mon abonnement ce mois-ci

  • Il arrivait que des sessions démarrent alors que l’ordinateur était en veille, consommant des tokens. Même une question simple comme « quelle heure est-il ? » pouvait manger 10 %

• Cette année, j’ai testé un agent IA pour ma déclaration d’impôts. J’ai utilisé Opus 4.6, Codex 5.4 et Antigravity 3.1 avec des forfaits à 20 $ chacun.
  Codex a tout géré parfaitement en 12 minutes, Antigravity a omis une page mais l’a corrigée rapidement. Claude Code, lui, s’est arrêté pour dépassement de limite d’usage, puis présentait encore des erreurs après nouvelle tentative. Très décevant

  • J’ai fait une expérience similaire, mais dans mon cas Claude a été aussi précis qu’un comptable. C’est fascinant de voir à quel point les résultats changent d’une session à l’autre pour une même tâche. Le support client à l’ère des logiciels non déterministes est vraiment une expérience étrange

• Depuis l’annonce de mise à jour publiée sur Reddit, Claude a changé au point de devenir inutilisable pour du code au quotidien. Les crédits d’un compte Pro sont épuisés en une heure, donc je suis retourné vers Gemini et ChatGPT

• Au final, on dirait que la structure tarifaire par tokens d’Anthropic est conçue au détriment des utilisateurs ordinaires. Dès qu’on l’utilise réellement, on sent immédiatement à quel point ils veulent gagner de l’argent