Ce que 137 jours de Claude Code disent de mes limites

La fenêtre de 5 heures de Claude Code ne démarre pas à une heure fixe. Elle démarre à votre premier message envoyé après l'expiration de la précédente. C'est la raison pour laquelle votre limite semble tomber un peu plus tard chaque jour, et toujours au milieu de quelque chose.

J'ai voulu comprendre pourquoi ça m'arrivait si souvent. Plutôt que de deviner, j'ai analysé mes propres données. Claude Code conserve l'horodatage de chaque prompt envoyé dans ~/.claude/history.jsonl (%USERPROFILE%\.claude sous Windows), un fichier qui échappe au nettoyage automatique appliqué aux transcripts. Cent trente-sept jours d'activité, 18 393 prompts, de janvier à août 2026. Voilà ce que j'y ai trouvé, y compris une information que l'API renvoie à chaque requête et que personne n'exploite.

Quand la consommation se concentre-t-elle vraiment ?

Première surprise en traçant mes prompts par heure de la journée. La répartition est loin d'être uniforme.

Sept heures de la journée absorbent la moitié de mes prompts, avec un pic net à 16h. L'autre moitié se disperse largement, nuits comprises.

Cette concentration a une conséquence directe. Une session qui court de 15h30 à minuit dure environ neuf heures, donc elle traverse forcément deux fenêtres de cinq heures. La coupure tombe quelque part au milieu, vers 20h30, et il n'y a rien à faire une fois qu'elle est là.

Deuxième surprise, plus utile : l'heure de mon premier prompt varie énormément. Sur ces 137 jours, elle va de minuit à 22h selon les jours. Comme la fenêtre s'accroche à ce premier message, ma grille de réinitialisations était différente chaque jour. Je cherchais un horaire là où il n'y avait qu'une dérive.

Est-ce la limite hebdomadaire ou la fenêtre de 5 heures qui bloque ?

J'étais convaincu que le plafond hebdomadaire était mon problème. Anthropic a introduit ces limites le 28 juillet 2025, avec effet fin août, en estimant qu'elles toucheraient moins de 5 % des abonnés. Vu mon volume, je me voyais volontiers dans ces 5 %.

Les chiffres disent l'inverse. Au moment de mes mesures, mon utilisation hebdomadaire plafonnait à 3 à 8 %, pendant que ma fenêtre de 5 heures montait à 80 % en une seule session. Le frein n'était pas là où je le cherchais.

Ce détail compte pour choisir quoi optimiser. Réduire sa consommation globale, basculer sur un modèle plus léger pour les tâches mécaniques, compacter tôt, tout cela aide sur le quota hebdomadaire. Mais si votre goulot est la fenêtre de 5 heures, le levier est ailleurs : dans le placement des frontières.

À noter qu'Anthropic a doublé les limites de la fenêtre de 5 heures le 6 mai 2026 et supprimé la réduction aux heures de pointe. Si vos souvenirs de saturation datent d'avant cette date, ils ne valent plus.

Quels plans sont concernés ?

La fenêtre de 5 heures s'applique aux abonnements. La documentation d'Anthropic précise que Pro et Max partagent le même pool de limites entre Claude.ai et Claude Code : ce que vous consommez dans le chat ampute ce qu'il vous reste dans le terminal.

Les seuls chiffres officiels par plan datent de l'annonce des limites hebdomadaires, relayée par TechCrunch en juillet 2025.

Méfiez-vous des tableaux en tokens qui circulent sur le sujet. Les valeurs précises par plan n'apparaissent dans aucune documentation officielle accessible, ce sont des estimations communautaires.

Anthropic propose par ailleurs d'acheter du dépassement : une fois la limite atteinte, l'usage supplémentaire est facturé au tarif API standard. C'est désactivé par défaut et cela s'active dans les réglages de facturation. Là encore, l'API vous dit où vous en êtes : le header anthropic-ratelimit-unified-overage-status vaut rejected quand le dépassement est refusé, et overage-disabled-reason en donne la cause, par exemple org_level_disabled quand un administrateur l'a bloqué pour toute l'organisation. C'est la seule soupape prévue à l'intérieur d'un abonnement.

Où Claude Code cache-t-il l'heure exacte du reset ?

C'est la partie intéressante. J'ai cherché où était stockée l'heure de réinitialisation, en supposant qu'elle traînait quelque part sur ma machine. Elle n'y est pas : rien dans l'historique des conversations, rien dans les fichiers de configuration.

En revanche, elle arrive dans chaque réponse de l'API. Quand un serveur répond, il accompagne le contenu de lignes d'en-tête, invisibles à l'usage, qui transportent des informations de service. Anthropic y glisse l'état complet de vos quotas. Une simple requête d'un token vers /v1/messages renvoie ceci :

anthropic-ratelimit-unified-5h-status: allowed
anthropic-ratelimit-unified-5h-reset: 1786732200
anthropic-ratelimit-unified-5h-utilization: 0.34
anthropic-ratelimit-unified-7d-reset: 1787302800
anthropic-ratelimit-unified-7d-utilization: 0.03
anthropic-ratelimit-unified-overage-status: rejected

1786732200 est une date exprimée en secondes écoulées depuis 1970, la convention habituelle. Converti, ce nombre donnait 20h30 précises, et 0.34 disait que j'avais consommé 34 % de la fenêtre en cours. Tout ce que je cherchais était là, à chaque appel, sans rien demander de spécial.

Vous pouvez le vérifier vous-même sans installer quoi que ce soit. Générez un jeton avec claude setup-token, puis :

curl -sS -D - -o /dev/null -X POST https://api.anthropic.com/v1/messages \
  -H "authorization: Bearer $CLAUDE_CODE_OAUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: oauth-2025-04-20" \
  -H "content-type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001","max_tokens":1,"messages":[{"role":"user","content":"hi"}]}' \
  | grep ratelimit-unified

La requête coûte un jeton. Passez le timestamp obtenu à date -d @1786732200 pour lire l'heure en clair.

Ces headers ne sont documentés nulle part. La documentation officielle des rate limits décrit uniquement les familles anthropic-ratelimit-requests-* et anthropic-ratelimit-tokens-*, qui concernent les quotas par minute. Les headers unified-5h-* n'y figurent pas. Ils existent pourtant, et la communauté les connaît : l'issue #55333 du dépôt claude-code, ouverte le 1er mai 2026, demande précisément à Anthropic de les persister dans un fichier local. Elle a été clôturée comme doublon, sans réponse publique.

Pourquoi ccusage et claude-warmup n'exploitent pas ces headers

J'ai regardé ce que font les outils existants avant d'écrire quoi que ce soit. Le constat est net.

ccusage (10 100 étoiles) parse les fichiers JSONL locaux pour reconstituer des blocs de 5 heures. C'est une reconstruction a posteriori, pas une lecture de l'état réel côté serveur.

Claude-Code-Usage-Monitor (8 600 étoiles) fait du monitoring en temps réel avec prédictions. Depuis sa version 4, il consulte les informations de rate limit exposées par la barre d'état que Claude Code affiche dans le terminal, quand elles sont fraîches, avec repli sur une estimation locale. Il n'émet pas de requête pour aller chercher les headers lui-même.

claude-warmup (162 étoiles) attaque le bon problème, celui de l'ancrage, avec une GitHub Action qui envoie un hi à heure fixe. Mais il ne lit aucun header : il tire à l'aveugle et espère que la fenêtre était bien expirée.

Personne, à ma connaissance, n'interroge l'API pour lire l'heure de reset et s'en servir. C'est d'autant plus étonnant que l'information est exacte, immédiate, et coûte une requête d'un token.

Un cron du matin suffit-il à ancrer sa fenêtre ?

C'est l'erreur que j'ai faite, et elle mérite d'être racontée parce qu'elle est intuitive.

Mon raisonnement de départ : si je ping à 7h, j'ouvre une fenêtre 7h-12h, donc la suivante ira de 12h à 17h, puis 17h-22h. Une grille propre, un reset à 22h pile. C'est exactement ce que promettent les scripts de warmup.

C'est faux. La fenêtre suivante ne démarre pas à 12h, elle démarre à votre premier message après 12h. Si vous ne touchez pas au clavier avant 15h30, votre grille devient 15h30, 20h30, 01h30. Le ping de 7h n'a servi qu'à consommer une fenêtre pendant que vous dormiez.

Pour tenir un horaire fixe, il faut relancer une requête à chaque expiration, pas une fois le matin. Quatre requêtes par jour au lieu d'une, chacune déclenchée au moment exact où la précédente meurt. Et pour connaître ce moment exact, il faut justement lire le header de reset.

Quel gain réel sur 137 jours de données ?

Je pourrais m'arrêter là et vous vendre un gain spectaculaire. J'ai préféré le mesurer, en rejouant mes 137 jours selon trois stratégies. Une fenêtre compte comme utile seulement si j'y ai effectivement envoyé au moins un prompt.

L'écart entre les deux dernières lignes chiffre exactement ce que coûte l'approche naïve : relancer à chaque expiration plutôt qu'une fois le matin multiplie le gain par plus de trois.

Le chaînage améliore 62 de mes 137 journées, soit 45 % d'entre elles. Et une fenêtre supplémentaire n'est pas une statistique abstraite : c'est la différence entre une session qui s'arrête net et une session qui va au bout.

Ces chiffres sont reproductibles chez vous. Le script d'analyse est dans le dépôt, il lit vos propres fichiers locaux et ne transmet rien.

Placer ses grosses tâches juste avant le reset

Voilà l'usage qui a changé ma façon de travailler, et il découle uniquement du fait de connaître l'heure exacte.

Quand une refonte lourde tombait n'importe où dans la fenêtre, je me faisais couper au milieu. Impossible de finir, impossible de reprendre avant des heures, avec un travail à moitié fait sur les bras. Le pire moment pour s'arrêter est celui qu'on n'a pas choisi.

Maintenant, je lance ces tâches juste avant la réinitialisation. Le reset tombe pendant l'exécution, le compteur repart de zéro en cours de route, et je dispose d'une fenêtre entière pour aller au bout. La même tâche qui me bloquait me laisse désormais de la marge.

Ça ne fonctionne que si vous savez à la minute près quand la bascule arrive. Avec un reset qui dérive entre 18h et minuit selon l'heure à laquelle vous avez ouvert votre terminal, vous ne pouvez rien planifier. Avec un reset à 22h tous les jours, vous placez votre gros morceau à 21h45 et vous savez ce qui va se passer.

Quand on travaille seul, personne ne prend le relais pendant que la limite se recharge, et tout ce qu'une seule personne porte devient une dette. Cette maîtrise du calendrier compte alors davantage qu'un quota marginal supplémentaire.

claude-window, ancrer sa fenêtre automatiquement

J'ai empaqueté le mécanisme dans claude-window. Un petit programme tourne en arrière-plan, envoie une requête d'un token, lit l'heure de reset dans les en-têtes, dort jusqu'à cet instant plus deux minutes, puis recommence. Entre deux réveils, il ne fait rien du tout et ne consomme aucun quota. Quatre requêtes par jour au total.

Le mien tourne sur un Raspberry Pi Zero 2 W qui héberge déjà Pi-hole, avec 464 Mo de mémoire partagée entre les deux. C'est le bon endroit pour ce genre de tâche : une machine allumée en permanence, qui ne dort jamais et ne dépend pas de votre poste de travail. Si vous voulez le même socle, j'ai publié le guide d'installation headless du Pi Zero 2 W avec IP fixe et Pi-hole que j'ai suivi pour le mien.

L'installation se fait ensuite comme un service classique, via le gestionnaire natif de chaque système : systemd sous Linux, launchd sous macOS, le planificateur de tâches sous Windows.

npm install -g claude-window
claude-window login "$(claude setup-token)"
claude-window install

Deux limites que j'assume dans le dépôt comme ici. L'outil ne peut pas déplacer une fenêtre déjà ouverte, donc l'ancre ne tient que si vous êtes inactif à l'heure choisie. Et les nuits tardives cassent la chaîne : 24 n'étant pas divisible par 5, aucune grille ne boucle proprement sur une journée.

Ce qu'il faut en retenir

Les 21 % de fenêtres gagnées sont agréables, mais ce n'est pas ce qui a changé mon travail. Ce qui l'a changé, c'est de savoir à quelle heure la bascule arrive.

Une limite qui tombe à un moment connu cesse d'être une contrainte subie et devient un paramètre de planification. On place les gros morceaux juste avant, on garde les tâches courtes pour la fin de fenêtre, on arrête de découvrir la coupure en pleine refonte. Le quota, lui, n'a pas bougé d'un token.

C'est la différence entre un outil qui vous impose son rythme et un outil dont vous connaissez le rythme.

Deux mécaniques non documentées à ce jour

Deux choses méritent d'être signalées plutôt que tues.

Le README de claude-warmup indique que depuis avril 2026, la fenêtre démarre à la minute exacte du premier message, alors qu'elle était auparavant arrondie à l'heure inférieure. Mes observations ne collent pas tout à fait : premier message à 15h34, fenêtre annoncée par l'API à 15h30. L'arrondi semble se faire à la demi-heure. Je n'ai qu'une poignée de points de mesure, donc je le donne comme observation, pas comme règle.

Sur la limite hebdomadaire, Martin Monperrus, enseignant-chercheur à KTH, a mesuré les réinitialisations réelles en surveillant l'API d'usage du 9 au 20 juin 2026. Il a observé des intervalles de 71,9 à 72,6 heures, soit environ 72 heures, pendant que le champ resets_at renvoyé par l'API annonce une date sept jours plus loin. Comportement non documenté, qui change complètement la façon de planifier une semaine chargée.

Ces deux points ont la même origine : Anthropic ne documente pas la mécanique de ces fenêtres. Tant que ce sera le cas, les seules réponses fiables viendront de la mesure, pas de la lecture de la documentation.

Questions fréquentes

Quand démarre la fenêtre de 5 heures de Claude Code ?

Elle démarre à votre premier message envoyé après l'expiration de la fenêtre précédente, pas à une heure fixe de la journée. Si vous commencez à travailler à 15h34, votre limite se réinitialise vers 20h30, puis 01h30. Le lendemain, si vous démarrez à 9h12, tout se décale. C'est ce glissement qui donne l'impression que le reset tombe toujours au mauvais moment.

Peut-on cumuler les tokens non utilisés d'une fenêtre Claude Code ?

Non. Le quota d'une fenêtre non consommée est perdu, l'utilisation repart de zéro à chaque réinitialisation. C'est le principe d'un rate limit glissant. La seule marge de manœuvre consiste à aligner les frontières de fenêtres sur vos heures de travail réelles, ce qui ne crée aucun quota mais évite les coupures en milieu de session.

Comment connaître l'heure exacte de son prochain reset Claude Code ?

L'API Messages renvoie le header anthropic-ratelimit-unified-5h-reset, un timestamp Unix, dans la réponse à chaque requête. Le header anthropic-ratelimit-unified-5h-utilization donne la part de quota déjà consommée. Ces deux headers ne sont documentés nulle part chez Anthropic mais sont bien présents dans chaque réponse.

La limite hebdomadaire de Claude Code se réinitialise-t-elle vraiment tous les 7 jours ?

Le chercheur Martin Monperrus a mesuré des intervalles réels de 71,9 à 72,6 heures entre deux réinitialisations en juin 2026, soit environ 72 heures et non 7 jours, alors que le champ resets_at de l'API annonce une date à 7 jours. Ce comportement n'est pas documenté par Anthropic.

Existe-t-il un moyen de supprimer la fenêtre de 5 heures sur Pro ou Max ?

Non. Tant que Claude Code s'authentifie avec un abonnement Pro ou Max, la fenêtre glissante de 5 heures s'applique et le quota non consommé est perdu. La seule soupape prévue dans le forfait est l'achat de dépassement, facturé au tarif API standard et désactivé par défaut. Basculer sur une clé API facturée à l'usage change de régime de facturation, ce n'est pas une optimisation de l'abonnement.

Un cron de warmup permet-il d'ancrer sa fenêtre Claude Code ?

Un seul ping quotidien ne suffit pas. Il ouvre bien une fenêtre à l'heure voulue, mais dès que celle-ci expire pendant que vous êtes loin du clavier, la suivante démarrera à votre prochain message et la grille se décale à nouveau. Pour tenir un horaire fixe, il faut relancer une requête à chaque expiration, pas une seule fois le matin.