J'ai regardé l'erreur à 6 000 $ se dérouler ligne par ligne

Un script qui tournait pendant son sommeil

Imaginez la scène : il est tard, vous venez de construire quelque chose d'intelligent. Claude Code, configuré pour vérifier les mises à jour logicielles toutes les 30 minutes, tourne en autonomie. Vous allez vous coucher avec le sentiment d'avoir bien travaillé. Vous vous réveillez avec une facture de 6 000 $. C'est exactement ce qui est arrivé à un développeur qui en a parlé sur Reddit. Pas un processus fou. Pas une typo dans un palier de facturation. Le script a fait exactement ce qu'on lui demandait — se réveiller, vérifier les mises à jour, se rendormir. La catastrophe est née de deux choses qui se sont heurtées silencieusement dans l'obscurité. Je construis des outils d'optimisation de tokens pour gagner ma vie. Quand j'ai lu cette histoire pour la première fois, je n'ai pas pensé « quel développeur négligent ». J'ai pensé : je connais ce sentiment de faire confiance à une boucle censée faire gagner du temps.

Comment le contexte devient un incendie monétaire

Claude Code ne remet pas sa mémoire à zéro entre les itérations de boucle quand on garde une session ouverte. Chaque appel d'outil, chaque réponse, chaque étape de raisonnement intermédiaire s'accumule dans un context window qui grossit comme du sédiment. En début de session, c'est gérable — quelques centaines de tokens. Des heures plus tard, c'est une autre bête. Au moment où la boucle de ce développeur avait tourné toute la nuit, elle avait constitué un historique de conversation de 800 000 tokens. Cet historique s'attachait à chaque requête. Normalement, c'est là que le prompt caching fait son travail. On paie le prix plein d'entrée une seule fois pour écrire le cache, puis chaque appel suivant lit depuis ce cache à une fraction du coût. Pour Claude Sonnet 4.x : Source : documentation tarifaire Anthropic Sur 800 000 tokens, l'écart entre ces deux chemins est brutal :

• Cache hit : 800k × 0,30 $/MTok = 0,24 $ par cycle
• Cache miss (reconstruction complète) : 800k × 3,75 $/MTok = 3,00 $ par cycle

Un multiplicateur de 12,5×. Par cycle. Avant de compter le moindre token de sortie.

La fenêtre de cinq minutes qui a coûté 6 000 $

Voilà la partie qui rend cette histoire véritablement injuste. À un moment courant mars 2026, Anthropic a silencieusement abaissé le TTL par défaut du prompt cache de Claude Code de 1 heure à 5 minutes. Pas d'annonce. Pas d'entrée dans le changelog. Rien dans les notes de version. Le changement n'a été confirmé que des semaines plus tard quand un développeur du nom de seanGSISG a ouvert l'issue GitHub #46829 le 12 avril 2026, après avoir fait ce que j'aurais fait : regarder les données. Il a analysé 119 866 appels API sur deux machines et trouvé une transition nette — des cache writes à 1h jusqu'aux alentours des 6–8 mars, puis des cache writes à 5m à partir de là, sans rien entre les deux. Voici donc le calcul qui a détruit la nuit de ce développeur :

• Intervalle de la boucle : 30 minutes
• TTL du cache (désormais) : 5 minutes
• Écart entre intervalle et TTL : 25 minutes de cache froid garanti

Chaque réveil trouvait un cache déjà expiré. L'historique de 800 000 tokens a été reconstruit de zéro 48 fois avant le matin. Quarante-huit cache writes complets à 3,75 $/MTok au lieu de 48 cache reads à 0,30 $/MTok. Il n'y avait aucun compteur en temps réel à surveiller. Le tableau de bord d'utilisation d'Anthropic se met à jour avec un délai de plusieurs jours. Le premier avertissement du développeur a été un e-mail — à ce moment-là, l'argent avait déjà disparu.

Ce que le cache donne, le TTL le reprend

L'analyse de l'issue GitHub a mis en lumière autre chose : ce n'était pas seulement un problème pour les développeurs qui font tourner des boucles nocturnes. Même les abonnés ordinaires de Claude Code qui n'avaient jamais atteint leurs limites ont constaté une augmentation de 20 à 32 % des coûts de création de cache après le changement de TTL. L'histoire de la boucle est extrême, mais le mécanisme sous-jacent — une régression silencieuse du TTL forçant des reconstructions complètes inutiles — a touché tout le monde. XDA Developers a documenté le schéma : chaque cache bust sur un grand context window est une reconstruction totale. Dans les sessions d'agentic coding, où le contexte atteint couramment des centaines de milliers de tokens, ce n'est pas un cas limite de niche. C'est la condition de fonctionnement normale pour tout agent qui tourne suffisamment longtemps. Le développeur a perdu 6 000 $ en une seule nuit. Ce chiffre n'est pas approximatif — il vient directement du rapport MakeUseOf de l'incident Reddit.

Ce que la compression aurait changé (une estimation honnête)

Il s'agit d'une estimation. Je veux être précis sur ce que la compression adresse réellement ici. Le levier principal, c'est l'historique de 800 000 tokens reconstruit 48 fois. Un proxy d'optimisation de tokens comme Tokenade intercepte chaque réponse d'outil avant qu'elle n'entre dans le modèle — supprimant les scaffoldings verbeux, compressant les outputs, résumant les tours précédents avant qu'ils s'accumulent — ce qui est l'idée centrale derrière la réduction de l'usage de tokens des agents de codage IA. Une compression conservatrice à 50 % de cet historique réduirait le contexte de chaque cycle à ≈400k tokens. En supposant les 48 mêmes cycles à cache froid (pire cas : le mismatch TTL est toujours présent) :

• Non compressé par cycle (cache write) : 800k × 3,75 $/MTok = 3,00 $
• Compressé par cycle (cache write) : 400k × 3,75 $/MTok = 1,50 $
• Économie nocturne estimée sur les cache writes seuls : ≈48 × 1,50 $ = ≈72 $

Je serai honnête : 72 $ face à une facture de 6 000 $, ça paraît décevant. Mais les tokens de sortie et les scaffoldings supplémentaires représentent une part importante de la facture aussi, et ce n'est pas ce que la compression cible. Ce que la compression cible, c'est la partie qui s'accumule : l'historique qui a grossi toute la nuit et multiplié chaque cache write suivant. La vraie question n'est pas de savoir si 72 $ ou 600 $ auraient été économisés. C'est de savoir si le contexte atteint un jour 800 000 tokens, si chaque réponse d'outil est compactée à l'entrée — avant de se sédimenter dans l'historique qui sera reconstruit de zéro, 48 fois, entre minuit et 6h du matin. Le tier gratuit de Tokenade couvre jusqu'à 20 millions de tokens compressés par mois. Pour une boucle comme celle-ci, la compression ne coûte rien. Le tier payant à 9,90 €/mois couvre des sessions bien au-delà de ce que ce script aurait généré.

Trois lignes de code qui valent plus que les regrets

En lisant cette histoire, trois garde-fous s'imposent — aucun ne nécessite de nouvel outil :

1. Un budget de tokens strict sur la boucle. Claude Code supporte les flags --max-tokens. Plafonner le contexte force une synthèse et un élagage plutôt qu'une accumulation indéfinie.
2. Des alertes de dépenses configurées à l'avance. Le délai du tableau de bord Anthropic rend la surveillance réactive inutile. La seule alerte qui arrive à temps est celle qu'on configure avant d'aller dormir.
3. Une compression des inputs à chaque cycle, pour que l'historique de conversation grandissant ne se cumule pas dans le coût des cache writes.

Tokenade intervient au niveau 3. Il intercepte chaque réponse d'outil et chaque bloc de contexte avant qu'il n'atteigne le modèle, le compresse, et permet de conserver la même logique de boucle sans le footprint qui s'emballe. Si vous faites tourner un agent automatisé ou nocturne : commencez gratuitement sur tokenade.net — aucune carte bancaire requise, aucune mauvaise surprise de quota le premier jour.

---

Sources : MakeUseOf — Someone left Claude Code running overnight, and it cost $6,000 · XDA Developers — Anthropic quietly nerfed Claude Code's 1-hour cache · GitHub issue #46829 — Cache TTL silently regressed from 1h to 5m · Documentation tarifaire Anthropic