Votre Quota Claude Code Fond 20x Plus Vite Que Prévu

Votre Quota Claude Code Fond 20x Plus Vite Que Prévu

Vous êtes en plein refactoring, Claude Code tourne bien, et là : rate limit. Encore. Après à peine une heure.

Vous n'hallucinez pas. Une enquête communautaire vient de sortir des chiffres concrets : les "thinking tokens" invisibles sont le coût dominant dans votre quota Claude Code. Vous ne pouvez ni les voir ni les contrôler.

Les chiffres du proxy

Un développeur a construit cc-relay, un proxy de monitoring transparent qui intercepte les appels API de Claude Code via la variable d'environnement standard ANTHROPIC_BASE_URL. Il enregistre chaque requête et réponse sans modifier le comportement.

17 610 requêtes loguées en une semaine. Voilà ce qui en sort :

• Votre fenêtre de quota de 5 heures vous donne environ 30 à 50 tâches de code moyennes. C'est tout.
• L'output visible représente 1% du quota : 9K-16K tokens. Le reste, ce sont des thinking tokens que vous ne voyez jamais.
• Les taux de cache hit sont tombés à 36,1% sur certaines versions alors qu'ils devraient dépasser 90%.
• Le rollback de v2.1.89 vers v2.1.68 a restauré les performances cache à 97,6%.

Le système de quota utilise deux fenêtres glissantes : un compteur de 5 heures et un compteur de 7 jours. Sur 100% des requêtes capturées, c'est la fenêtre de 5 heures qui sature. Peu importe l'heure.

Six bugs confirmés, deux toujours pas corrigés

L'enquête a mis au jour six bugs côté client sur quatre couches.

Corrigés dans v2.1.91

Bug Sentinel. Le binaire standalone cassait le préfixe de cache. Résultat : efficacité du cache entre 4 et 17%, coûts multipliés par 20.

Bug Resume. Le flag --resume rejouait le contexte complet sans utiliser le cache — des cache misses totaux sur des conversations de 500K tokens.

Toujours pas corrigés

Budget Cap. Les résultats d'outils ont une limite agrégée de 200K caractères. Après environ 15-20 lectures de fichiers, les anciens résultats sont tronqués à 1-41 caractères. Ça s'est produit dans 72 839 événements mesurés avec un taux de troncation de 100%. Vous payez pour un contexte de 1M tokens. Vous ne l'obtenez pas pour les résultats d'outils.

Faux Rate Limiter. Le client génère de faux messages "Rate limit reached". Sur 65 sessions, 151 erreurs synthétiques se sont produites alors qu'aucun appel API réel n'avait été tenté.

Microcompact. Le serveur supprime silencieusement les anciens résultats d'outils du contexte : 3 782 événements de nettoyage ont supprimé 15 998 éléments au total.

Inflation JSONL. Le thinking étendu duplique les entrées dans les logs locaux. Inflation moyenne de 2,37x sur 532 fichiers.

Les mécanismes de budget cap et microcompact sont contrôlés par des flags A/B testing côté serveur. Anthropic peut modifier le comportement sans publier de mise à jour client. Aucune variable d'environnement ne permet de les désactiver.

Vérification par d'autres chercheurs

Deux analyses séparées arrivent aux mêmes conclusions :

• Une analyse forensique de 18 jours montre une chute de consommation de 3,2 milliards à 88 millions de tokens entre les périodes illimitée et limitée, à 90% d'utilisation. Les comptages de tokens visibles n'expliquent pas cette réduction.
• Une autre analyse documente une réduction de capacité de 34-143x et confirme que les corrections liées au cache améliorent l'efficacité. Mais la chute de capacité semble indépendante des bugs côté client.

Le problème pour les agents en production

Ce type d'opacité rend l'exécution d'agents en production imprévisible. Quand vos outils brûlent du quota via une consommation de tokens invisible, impossible de planifier la capacité. Impossible de débuguer les pics de coûts. Et impossible de faire confiance à vos rate limits.

L'observabilité de l'infrastructure, ça n'est pas une feature nice-to-have. Quand les agents tournent sur des desktops complets avec des appels système transparents et pas d'état caché, vous pouvez instrumenter ce qui compte et détecter les problèmes avant qu'ils ne crament votre budget.

Ce que vous pouvez faire maintenant

1. Mettez à jour vers v2.1.91 pour corriger la régression de cache
2. Arrêtez d'utiliser --resume et --continue — démarrez des sessions fraîches à la place
3. Relancez une session régulièrement pour réinitialiser le budget cap de 200K
4. Un seul terminal — plusieurs terminaux ne partagent pas le cache

Analyse complète avec données brutes, proxy et outils communautaires : github.com/ArkNill/claude-code-hidden-problem-analysis

Travail collaboratif de 17 personnes. Les crédits individuels sont dans le writeup complet.