Tokens Claude:
pourquoi il est si difficile de savoir combien il vous en reste

Vous avez déjà vécu ça : une longue session de travail avec Claude, et soudain il semble « oublier » des éléments discutés bien plus tôt. Ou pire ; il continue de répondre normalement alors qu’il approc

Dans cet article, je détaille concrètement comment aborder ce sujet en 2026, avec mes retours terrain sur des projets réels et les leçons apprises au quotidien.

Vous avez déjà vécu ça : une longue session de travail avec Claude, et soudain il semble « oublier » des éléments discutés bien plus tôt. Ou pire ; il continue de répondre normalement alors qu’il approche visiblement de sa limite, sans vous prévenir clairement. Ce phénomène touche à une question fondamentale : est-ce que Claude sait vraiment combien

Qu’est-ce qu’un token, exactement ?

Avant d’aller plus loin, un rappel utile. Un token n’est pas un mot. C’est une unité de traitement d’environ 4 caractères en anglais ; un peu plus en français, car les accents et certaines constructions linguistiques prennent plus de place. Un mot courant représente en moyenne 1 à 2 tokens. Une phrase de 20 mots représente environ 25 à 35 tokens selon sa complexité.

La fenêtre de contexte de Claude, c’est la quantité totale de tokens que le modèle peut « lire » en une seule fois : votre message actuel, l’historique complet de la conversation, les fichiers que vous avez uploadés, les instructions de profil, les documents de référence du Project. Tout ça ensemble. Sur Claude Sonnet 4.6, cette fenêtre est de 200 000 tokens ; soit environ 150 000 mots, ou l’équivalent d’un roman entier. Sur Claude Opus 4.6 et Sonnet 4.6 dans Claude Code, elle atteint désormais 1 million de tokens depuis mars 2026.

Le problème central : l’awareness de sa propre limite

Voici où les choses deviennent intéressantes. Claude peut calculer techniquement le nombre de tokens consommés dans une session. Mais sa capacité à anticiper et communiquer proactivement l’approche de cette limite est imparfaite ; et pour des raisons qui tiennent à l’architecture même des LLM.

Les modèles de langage traitent le texte comme une séquence de tokens à prédire, pas comme un système avec un compteur intégré qui surveille sa propre mémoire. Claude n’a pas un « indicateur de carburant » qui clignote quand il arrive à 80 % de sa fenêtre. Il dispose techniquement d’informations sur la longueur du contexte, mais les intégrer systématiquement dans ses réponses (en vous disant « attention, je suis à 70 % de ma fenêtre ») n’est pas un comportement qui a été entraîné de façon aussi fiable qu’on pourrait le souhaiter.

Le résultat concret : Claude peut continuer à répondre de façon apparemment normale alors qu’il approche des limites, sans vous prévenir. Et quand la limite est atteinte, la session se coupe ; parfois au milieu d’une tâche, parfois après une longue conversation où vous n’aviez pas anticipé le problème.

Le phénomène « lost in the middle »

Il y a une deuxième dimension au problème, plus subtile et plus importante en pratique. Les LLM ont tendance à mieux retenir et traiter les informations situées au début et à la fin de leur contexte que celles situées au milieu. Les chercheurs appellent ça le « lost in the middle problem ».

Ce phénomène vient de la façon dont les Transformers encodent les positions dans leur mécanisme d’attention : les positions centrales dans une longue séquence reçoivent mécaniquement moins d' »attention » que les positions initiales et finales. En pratique, si vous uploadez 10 documents dans une session et que les documents 4, 5 et 6 contiennent des informations cruciales, Claude risque de les traiter moins bien que les documents 1, 2, 9 et 10 ; même si tous tiennent dans la fenêtre.

Une astuce concrète qui découle de cette réalité : quand vous fournissez plusieurs documents ou sections importantes, mettez les plus critiques en premier et en dernier. Placez le contenu secondaire au milieu. Claude 4.6 a amélioré ce point par rapport aux versions précédentes ; son score MRCR v2 (un benchmark qui mesure précisément la capacité à retrouver des informations dispersées dans un long contexte) est de 78,3 % sur 1 million de tokens, ce qui est significativement meilleur que ses concurrents directs. Mais le phénomène n’a pas disparu.

Ce que ça change concrètement pour vos sessions

Ces réalités techniques ont des implications pratiques directes sur la façon de travailler avec Claude.

Structurer ses sessions pour éviter la limite

La première recommandation est de ne pas laisser une seule conversation porter l’ensemble d’un projet complexe. Après une quarantaine d’échanges substantiels, ou quand vous avez uploadé plusieurs documents longs, il est judicieux de résumer les décisions prises et les informations importantes dans un nouveau message, d’ouvrir une nouvelle session, et de coller ce résumé en contexte de départ. Ça remet le compteur à zéro et garantit que les éléments importants sont bien positionnés au début du contexte ; là où l’attention de Claude est la plus forte.

La compaction automatique dans Claude Code

Pour les utilisateurs de Claude Code, Anthropic a introduit la compaction automatique de contexte. Quand une session devient longue, Claude génère automatiquement un résumé structuré des échanges précédents et le substitue à l’historique complet ; réduisant la consommation de tokens tout en préservant les informations importantes. La commande /compact permet de déclencher cette compaction manuellement. Vous pouvez aussi utiliser /memory pour consulter les notes que Claude a accumulées sur votre projet. Ces mécanismes fonctionnent bien, mais ils ne sont pas parfaits ; une compaction peut parfois lisser des nuances importantes dans les échanges précédents.

Gérer activement la consommation de tokens

Plusieurs comportements consomment des tokens de façon inefficace. Les corrections empilées (« non, pas ça, plutôt comme ça, et ajoute aussi, et supprime ça ») ajoutent chaque fois un bloc d’échange que Claude doit relire intégralement à chaque tour. Modifier un prompt initial plutôt qu’envoyer un message de correction peut réduire la consommation de 80 à 90 % sur un échange. Les connecteurs et outils actifs (recherche web, MCP) consomment aussi des tokens supplémentaires ; désactivez-les quand vous ne les utilisez pas.

Les instructions de Project et les préférences de profil s’ajoutent également à chaque session. Un profil de 2 000 mots consomme autant de contexte que vos propres messages sur une conversation courte. La bonne pratique est de garder les instructions sous 500 mots en supprimant tout ce qui ne change pas réellement le comportement de Claude.

Le futur : vers une meilleure awareness

La limite de 1 million de tokens disponible depuis mars 2026 sur Claude Opus 4.6 et Sonnet 4.6 (dans Claude Code) réduit significativement les cas où la fenêtre est atteinte en usage courant. Une codebase entière, des logs volumineux, une documentation dense ; tout ça tient désormais dans une seule session. Le coût n’a plus de surcoût pour les contextes longs : une requête de 900 000 tokens est facturée au même tarif par token qu’une requête de 9 000.

Mais l’awareness de la limite reste un défi non résolu. La question « combien de tokens me reste-t-il ? » n’est pas anodine ; c’est une question sur la capacité d’un LLM à modéliser son propre état interne, ce qui reste structurellement difficile pour des architectures Transformer standard. Les avancées sur ce point passeront probablement par des mécanismes d’interface (indicateurs visuels, alertes proactives) plutôt que par des changements de fond dans le modèle lui-même.

En attendant, la meilleure stratégie reste celle des utilisateurs expérimentés : gérer activement la longueur de ses sessions, structurer ses contextes intelligemment, et ne pas supposer que Claude sait exactement où il en est dans sa propre mémoire.