AIDiveIntro : la semaine est devenue plus courte
La limite hebdomadaire de Claude Code a baissé de 17 % à la mi-septembre 2026, quand la promotion d'été s'est terminée. Les utilisateurs des plus gros forfaits racontent qu'ils ont vidé leur semaine dès le mercredi. L'annonce d'Anthropic dit que les limites ont été relevées de façon permanente de 25 %, et le post qui suit appelle ce même changement une baisse de 17 %.
Toutes les listes de conseils pour étirer la limite arrivent sans un seul chiffre. Cet article en donne un, mesuré, à chaque correctif, puis les classe. Deux résultats ressortent : presque la moitié d'un mois de tokens est partie dans les subagents, et une seule longue pause oblige le message suivant à réécrire l'essentiel de la session.
Ce qui a changé, et comment compter
Les mesures présentées ici viennent d'un mois de logs Claude Code d'un seul développeur : 455 sessions et 63 398 requêtes, du 3 septembre au 3 octobre.
La promotion a couru de mai au 13 septembre et a rendu la limite hebdomadaire 50 % plus haute. La limite de chaque fenêtre de cinq heures, elle, n'a jamais bougé. Fin août, le compte développeur d'Anthropic a annoncé une hausse permanente de 25 %, et un post plus loin, le même fil explique que cela revient à une baisse de 17 %. Les deux affirmations sont vraies :
| Période | Limite hebdomadaire (ancienne limite = 100) |
|---|---|
| Avant la promotion | 100 |
| Pendant la promotion (de mai au 13 septembre) | 150 |
| Niveau permanent depuis le 14 septembre | 125 |
De 150 à 125, c'est la baisse de 17 % que les gens ressentent. Un utilisateur avec deux des plus gros forfaits a écrit qu'être à 100 % un mercredi ne lui était jamais arrivé. Un autre, sur le même forfait, était à 86 % un mardi matin. La baisse n'est pas la seule cause : un modèle plus gourmand est sorti début septembre, donc toutes les semaines vides ne viennent pas de ce changement.
De votre côté, vous voyez un pourcentage. L'écran /usage répartit l'usage récent entre les skills, les subagents, les plugins et chaque serveur MCP connecté, et il signale les cache miss. Une touche permet de passer du dernier jour aux sept derniers. Ce que vous ne voyez pas, c'est la taille de la limite en tokens : Anthropic publie des pourcentages et des multiplicateurs, jamais un nombre de tokens. Tout ce qui est mesuré ci-dessous est donc en tokens, pour une seule charge de travail, et non une part de votre semaine.
Compter les tokens depuis les logs cache un piège. Le log écrit la même réponse plusieurs fois, si bien qu'en additionnant chaque ligne on obtient 18,6 milliards de tokens. Comptés une seule fois, on en trouve 9,3 milliards. Un comptage naïf double presque tout.
Subagents : presque la moitié de la facture
Un subagent est un autre Claude que votre session lance pour une tâche annexe et qui rend compte quand il a fini. Sur le mois mesuré, les subagents ont pris 48,1 % de tous les tokens sur 2 631 exécutions.
| Mesure | Part des subagents |
|---|---|
| Tous les tokens | 48,1 % |
| Tokens de sortie | 63,9 % |
| Pondéré comme la grille tarifaire publique pondère la sortie et les écritures de cache | 55,3 % |
Chaque subagent paie aussi un ticket d'entrée. Avant de faire quoi que ce soit, sa requête d'ouverture porte déjà une médiane de 47 117 tokens : les instructions, la liste des outils et la liste des skills, tout renvoyé. Quelqu'un d'autre l'a mesuré sur une autre machine et a trouvé 16 000 à 21 000 tokens par lancement pour des agents dont le prompt propre est minuscule. Comme le dit cet article, le fichier de l'agent est une erreur d'arrondi à côté du coût de son propre lancement.
Le modèle est l'autre moitié du problème. Par défaut, un subagent hérite du modèle de la conversation principale : passer la session sur le plus gros modèle y met donc aussi tous les assistants. Dans les logs mesurés, le plus petit modèle a traité moins de 1 % des requêtes de subagents. Le correctif tient en une ligne dans le fichier de l'agent : un champ model réglé sur un modèle plus petit pour des tâches comme lancer des tests ou chercher des fichiers.
Cela donne deux habitudes. Évitez le subagent pour une petite tâche que vous pouvez faire sur place, et fixez un petit modèle sur ceux que vous gardez.
La limite de ce résultat : personne n'a mesuré ce que ce réglage fait économiser en part de la semaine, et un petit modèle qui a besoin de plus de tours peut coûter plus cher. Les 48 % viennent d'un travail qui se ramifie beaucoup. Votre propre part est dans l'écran /usage.
Le cache de cinq minutes que personne ne cite
Claude Code garde votre conversation dans un cache de prompt côté serveur, et la relire coûte une fraction de ce que coûte un nouvel envoi. Pour la session principale, ce cache vit une heure. Pour un subagent, il vit cinq minutes.
La documentation le dit clairement : les subagents ont cinq minutes, même avec un abonnement, tant que vous n'en choisissez pas plus. Il en va de même pour tout ce qui sort de la conversation principale, y compris le travail en arrière-plan et la compaction. Les logs mesurés concordent : chaque écriture de cache d'un subagent est tombée sur le palier de cinq minutes, et chacune d'une session principale sur celui d'une heure.
Un développeur sur Reddit a remarqué ce que cela provoque : l'un de ses subagents réécrivait tout son contexte huit fois en une seule journée. Le correctif tient en une ligne dans le fichier de réglages, "subagentPromptCacheTtl": "1h".
| Sa mesure | Avant | Après |
|---|---|---|
| Écritures de cache | 12,2 millions de tokens | 3,0 millions de tokens |
| Fenêtre de cinq heures avec quatre subagents | de 2 % à 100 % | de 0 % à 22 % |
C'est un utilisateur qui compare deux journées différentes, pas un test contrôlé. Dans les logs mesurés ici, cela compte à peine : seules 95 des 41 790 requêtes de suite d'un subagent (environ deux sur mille) sont arrivées après une attente de plus de cinq minutes, même si chacune a réécrit environ 75 000 tokens.
Cela dépend donc de la façon dont travaillent vos subagents. S'ils attendent un long build, une revue ou vous, activez-le. S'ils travaillent par courtes rafales, laissez tel quel, car un cache qui dure une heure coûte plus cher à écrire.
La pause qui réécrit toute la session
Le cache de la session principale dure une heure. Après une pause plus longue, il a disparu, et le message suivant ne peut rien relire. La documentation l'écrit noir sur blanc : le message que vous envoyez après la pause rate le cache et retraite tout votre contexte.
| Pause avant le message | Requêtes | Cache réécrit (médiane) |
|---|---|---|
| Moins de 5 minutes | 18 029 | 1 176 tokens |
| De 5 à 60 minutes | 414 | 1 327 tokens |
| Plus de 60 minutes | 79 | 130 332 tokens |
La session typique contenait à ce moment-là 175 523 tokens, donc l'essentiel a été réécrit. Le compteur ne traite pas non plus une écriture comme une lecture. Un développeur a placé un proxy de journalisation devant Claude Code et surveillé sa fenêtre de cinq heures : d'après ses ratios, un token écrit dans le cache pèse environ quarante fois un token lu depuis celui-ci.
Claude Code le sait. Quand vous reprenez une grosse session après une longue pause, il propose de reprendre depuis un résumé. Acceptez.
L'habitude la moins chère vient plus tôt. Quand une tâche est finie, faites un clear de la session tant que le cache est encore chaud. Le clear ne coûte rien et la tâche suivante repart petite. Compacter marche aussi, mais compacter une énorme session est lui-même une énorme requête.
Une pause n'est pas la seule façon de perdre le cache. Changer de modèle en pleine session le vide, car chaque modèle garde le sien. Sur les modèles les plus récents, changer l'effort ne le vide pas. Claude Code vous demande de confirmer un changement de modèle tant que le cache est chaud, et cette question est l'avertissement.
Les limites : 79 retours à froid, c'est un petit échantillon, et certains suivent une compaction. Un résumé perd aussi du détail, donc ce correctif coûte un peu de continuité.
Effort : le correctif qui peut coûter de la qualité
L'effort, c'est le temps que le modèle a le droit de réfléchir avant de répondre. Il y a cinq niveaux, de low à max, et la réflexion est facturée comme de la sortie. Le défaut est high sur la plupart des modèles et medium sur les deux plus récents.
La documentation indique que le budget de réflexion peut atteindre des dizaines de milliers de tokens par requête et que le niveau le plus haut a tendance à trop réfléchir. Sur les modèles les plus récents, la réflexion ne peut pas être désactivée du tout, donc le niveau est le seul réglage.
Un développeur a lancé les mêmes 29 vraies tâches aux cinq niveaux :
| Niveau d'effort | Coût moyen par tâche | Tâches réussies (sur 29) |
|---|---|---|
| low | 2,50 $ | 23 |
| medium | 3,15 $ | 28 |
| high | 5,01 $ | 26 |
| xhigh | 6,51 $ | 25 |
| max | 8,84 $ | 27 |
La qualité n'a pas suivi le coût. Medium a réussi plus de tâches que tous les niveaux au-dessus, et par dollar dépensé, c'est aussi lui qui a donné le plus de réussites. Selon ses mots, la courbe semble culminer à medium. L'équipe Claude Code fonctionne de la même façon : l'un de ses ingénieurs construit en low ou medium, relit, et ne lance la vérification qu'en high.
Le piège explique pourquoi ce correctif peut coûter de la qualité. Sur les problèmes difficiles qu'il avait choisis, low a réussi zéro fois sur cinq et high cinq fois sur cinq. Une tentative en low a pris deux minutes, une en high trente-trois.
Adaptez donc l'effort à l'étape : medium pour construire, high quand une erreur coûte cher (un bug dans du vieux code, une migration, une vérification finale), max presque jamais. Les logs de session enregistrent l'effort de chaque requête, vous pouvez donc vérifier ce que vous avez vraiment utilisé.
Ces coûts sont en dollars sur un modèle plus ancien, pas en part de la semaine : personne ne l'a publié. Et une tentative bon marché qui échoue et qu'on relance coûte plus cher qu'une qui marche.
Les conseils qui pèsent moins qu'annoncé
Certains correctifs figurent sur toutes les listes et font à peine bouger les choses. Les essayer ne coûte rien. Ils ne sont simplement pas là où la semaine est partie.
Ce qui se charge au démarrage est le vrai sujet de ce groupe. Un article a mesuré la requête d'ouverture depuis un dossier vide à 29 061 tokens, et à presque 39 000 dans un vrai projet. Dans les logs mesurés ici, la requête d'ouverture médiane est de 55 989 tokens, de 15 764 à 105 020 selon le projet. La commande /context montre ce qu'elle contient (fichiers mémoire, skills, listes d'outils) et nomme chaque fichier mémoire chargé. Élaguez ce que vous n'utilisez jamais. Le gain est modeste, car ce bloc est écrit une fois puis relu depuis le cache à chaque tour suivant. Il fait mal au démarrage à froid et à chaque lancement de subagent.
| Conseil populaire | Mesuré |
|---|---|
| Retirer des serveurs MCP | 1 350 tokens pour 51 outils sur trois serveurs ; 18 tokens pour un serveur avec un seul outil |
| Désactiver les suggestions de prompt | 3 à 4 % pour un utilisateur ; l'affirmation « jusqu'à 10 % » venait d'un compte aux contextes énormes |
| Filtrer la sortie du shell | environ 0,1 % du volume total, mesuré par un contributeur de l'un de ces filtres |
Les définitions d'outils sont différées par défaut aujourd'hui, ce qui explique que les serveurs MCP pèsent si peu. La documentation qualifie de faible le coût des suggestions de prompt. Les trois grossissent avec la taille de votre contexte, et les serveurs coûtent plus cher sur les anciens modèles où le report est désactivé. Désactivez-les si vous voulez, mais n'espérez pas récupérer votre semaine.
Le tableau classé
Classé selon ce qui a été mesuré :
| Rang | Correctif | Mesuré | Piège |
|---|---|---|---|
| 1 | Moins de subagents, moins chers | 48,1 % des tokens ; 47 117 par lancement | Moins de parallélisme |
| 2 | Ne pas reprendre une session à froid | 130 332 tokens réécrits contre 1 176 | Un résumé perd du détail |
| 3 | Effort : medium pour construire | 3,15 $ contre 5,01 $ par tâche ; 28 sur 29 réussies | Low échoue sur les problèmes difficiles |
| 4 | Cache des subagents à une heure | De 12,2 à 3,0 millions de tokens écrits dans le cache | Ne rapporte que si les subagents attendent |
| 5 | Élaguer ce qui se charge au démarrage | +9 744 tokens sur une base de 29 061 | Payé une fois par session |
Les trois conseils populaires (serveurs MCP, suggestions de prompt, sortie du shell) ne sont pas là où la semaine est partie.
Les limites, sans détour : ce classement est en tokens, à partir d'un mois de travail d'une seule personne, plus les mesures d'autres. Anthropic ne publie pas la taille de la limite en tokens, donc personne de l'extérieur ne peut les convertir en part de votre semaine. Votre ordre peut différer, et l'écran /usage vous le dira.
Les deux plus gros correctifs sont des habitudes, pas des réglages, et ils sont gratuits : lancer moins de subagents, et ne jamais reprendre en entier une session à froid.
