Fenêtre de contexte Claude Code : quand compresser, effacer ou diviser

La fenêtre de contexte de Claude Code est la mémoire de travail de votre session actuelle. Elle conserve votre conversation, chaque fichier lu, les définitions d'outils MCP, les configurations d'agent personnalisé, les fichiers mémoire et l'historique complet des appels d'outils, comme le décrit la documentation sur la fenêtre de contexte de Claude Code. Quand elle est pleine, vous avez trois leviers : /compact, /clear, ou démarrer une nouvelle session avec un handoff structuré. Lequel vous choisissez change la qualité de tout ce qui suit.

Choisir compresser, effacer ou une nouvelle session

Trois commandes, trois résultats différents. Comprendre la différence est le cœur du jeu.

`/compact ` remplace l'historique de conversation par un résumé condensé et maintient la session active. Le contexte se réduit, la session continue, et Claude conserve une certaine conscience historique. Vous pouvez orienter ce qu'il conserve : /compact focus on the auth bug fix indique au modèle ce qui compte au lieu de le laisser deviner. La référence officielle sur la fenêtre de contexte confirme que vous pouvez transmettre les instructions directement au passage compact.

`/clear ` est une réinitialisation complète. Toute la conversation est supprimée. Pas d'historique, pas de contexte de fichier en mémoire, pas de continuité. Comme le dit l'analyse de la fenêtre de contexte de Damian Galarza, utiliser /clear sans d'abord persister votre plan signifie que vous repartez de zéro. C'est correct, parfois intentionnel.

Démarrer une nouvelle session avec un document handoff vous donne un départ propre plus la continuité. Plus de détails sur la structuration de ce handoff ci-dessous.

L'arbre de décision approximatif :

1. Même tâche, plus d'espace nécessaire : utilisez /compact avec une instruction de focus.
2. Passage à un travail non lié : utilisez /clear.
3. Tâche trop importante pour une session ou qualité déjà en dégradation : créez un handoff et recommencez.

Une chose à signaler : /autocompact s'exécute automatiquement à l'approche de la limite. Vous pouvez configurer le degré de remplissage de la fenêtre avant qu'elle se déclenche, par exemple /autocompact 500k, mais le passage automatique prend ses propres décisions sur ce qu'il faut conserver. C'est correct pour les sessions courtes. Pour tout ce qui est architectural, vous voulez exécuter /compact manuellement avant que le passage automatique prenne le contrôle.

Voir ce qui consomme du contexte

Avant de gérer le contexte, vous devez le voir. Exécutez /context et vous obtenez une ventilation : taille totale du contexte, les catégories consommant le plus de jetons, et une barre visuelle montrant la répartition. Claude Code 101 de l'académie officielle vous guide dans cette sortie. Les catégories principales sont l'historique de conversation, les contenus de fichiers chargés dans la session, l'historique des appels d'outils, et tous les fichiers mémoire ou de configuration d'agent.

La plupart des développeurs sont surpris par l'historique des appels d'outils. Les longues sessions de débogage aller-retour s'accumulent rapidement. Une douzaine de lectures de fichiers, chacune avec une sortie complète, se compose rapidement. C'est généralement la première chose à cibler.

Ce qui persiste lors d'une compression compacte

Selon la documentation officielle, le contenu de démarrage se recharge automatiquement après une compression. Ce que vous devez surveiller, c'est la nuance de la conversation elle-même : les décisions architecturales spécifiques, les raisons derrière une refonte, pourquoi vous avez rejeté une approche particulière. Celles-ci survivent à une compression ciblée. Elles ne survivent souvent pas à la passe automatique, qui ne sait pas ce qui vous importe.

Délimitez les lectures du référentiel et la sortie des outils

La façon dont vous lisez les fichiers dans la session compte autant que le moment où vous compressez. Lire des répertoires entiers ou des fichiers volumineux quand vous n'avez besoin que d'une ou deux fonctions est l'un des moyens les plus rapides de consommer du contexte.

Quelques habitudes qui aident :

• Demandez à Claude de lire uniquement le fichier spécifique et la plage de lignes dont vous avez besoin, pas le module entier.
• Quand vous devez explorer une grande zone de codebase, déléguez à un sous-agent. Le contenu des fichiers reste dans le contexte du sous-agent, pas dans le vôtre. Vous n'obtenez que le résultat. La documentation officielle de la fenêtre de contexte l'indique explicitement : « Déléguez les lectures volumineuses : envoyez la recherche à un sous-agent afin que le contenu des fichiers reste dans sa fenêtre de contexte, pas dans la vôtre. »
• Évitez de relire les fichiers que vous avez déjà discutés sauf si quelque chose a changé. Claude a déjà ce contenu dans la conversation.
• Soyez précis avec les appels grep et les outils de recherche. Les recherches larges retournent des résultats larges.

Pour tous ceux qui construisent des workflows multi-agents sur Claude Code, le guide des sous-agents Claude Code explique comment structurer ces délégations. Et si vous travaillez au niveau du SDK, le guide Claude Agent SDK approfondit les limites de contexte entre les agents.

Si vous consacrez plus de temps à combattre le contexte qu'à écrire du code, cela vaut peut-être la peine de parler à quelqu'un qui le fait à temps plein. L'équipe Claude Code de Seahawk peut vous aider à mettre en place la bonne structure de projet dès le départ.

Préservez les décisions lors de la compression

C'est l'étape que la plupart des développeurs omettent. Juste avant de compresser ou d'effacer, demandez à Claude un résumé :

« Avant de compresser, donnez-moi une liste à puces des décisions clés que nous avons prises, tout ce que nous avons explicitement rejeté et pourquoi, et l'état actuel du travail. »

Copiez cela dans votre CLAUDE.md ou une note de brouillon. Quand vous reprenez, collez-le en tant que contexte initial. Le guide de MindStudio sur la commande `/compact ` décrit cela comme la différence entre une compression contrôlée et une compression chaotique : quand vous exécutez /compact manuellement, vous choisissez ce qui est préservé ; quand la passe automatique se déclenche, le modèle décide, et il garde souvent la sortie banale plutôt que le raisonnement architectural.

L'autre levier est CLAUDE.md lui-même. Les décisions architecturales, les relations de composants non évidentes, les choses que Claude ne devrait jamais faire dans cette codebase : celles-ci y appartiennent de façon permanente, pas seulement dans la conversation. Chaque nouvelle session charge automatiquement CLAUDE.md, donc c'est le seul endroit où le contexte persiste véritablement entre les sessions.

Quand ne pas compresser

• Au milieu du débogage, quand les messages d'erreur spécifiques et les traces de pile sont encore pertinents.
• Pendant une refonte où le détail au niveau du fichier est activement utilisé.
• Juste avant le travail d'intégration qui dépend du contexte du composant que vous venez de construire.

Le guide de gestion de contexte de Claudefast le résume bien : compactez aux points de rupture naturels entre les phases de travail, jamais au milieu d'une phase.

Diviser les grandes tâches sans perdre la transmission

Certaines tâches sont simplement trop volumineuses pour une seule session. Ce n'est pas un échec, c'est juste comme fonctionnent les grandes bases de code. La réponse est un document de transmission structuré créé avant la fin de la session, pas après que la qualité ait déjà baissé.

Un document de transmission utile couvre :

1. Ce qui a été terminé (avec références de commit ou chemins de fichiers).
2. Ce qui est en cours et quel est son état.
3. Les décisions prises et pourquoi (surtout tout ce qui n'est pas évident).
4. Ce qui vient ensuite, avec suffisamment de détails pour qu'une nouvelle session puisse la reprendre sans tout relire.
5. Toute question ouverte ou blocage.

Un praticien sur LinkedIn a décrit cela comme le cœur d'un système de transmission de session : à un niveau d'utilisation de contexte défini, la session crée un document de transmission avec ce qui a été fait, les références de commit et l'état actuel. La nouvelle session s'ouvre avec ce document comme premier message. Le post LinkedIn de JD Fiscus sur compact vs clear décrit une boucle TASK > COMMIT > CLEAR > RECAP > RESCAN pour garder les tâches ciblées, ce qui fonctionne bien pour le travail itératif de fonctionnalités.

Le flux de travail, concrètement :

1. Terminez une unité logique de travail et commitez.
2. Demandez à Claude de produire un résumé de transmission couvrant les cinq points ci-dessus.
3. Copiez le résumé dans un fichier de votre repo ou dans CLAUDE.md.
4. Exécutez /clear ou démarrez une nouvelle session.
5. Ouvrez la nouvelle session avec le document de transmission comme contexte.

De cette façon, vous ne partez jamais de zéro et vous ne traînez jamais un historique de session encombré dans un travail qui a besoin d'une tête claire.

Limites spécifiques aux modèles et dépannage

Les tailles de fenêtre de contexte varient selon le modèle. Le post de Damian Galarza note que Claude Sonnet 4.5 a une fenêtre de contexte d'environ 200 000 tokens comme point de référence. D'autres modèles Claude ont leurs propres limites ; consultez la documentation officielle du modèle pour les chiffres actuels plutôt que de vous fier à des chiffres communautaires qui peuvent être obsolètes.

À surveiller :

• Répétition. Claude commence à poser des questions auxquelles vous avez déjà répondu, ou contredit une décision antérieure. C'est un signal que le contexte pertinent a été repoussé ou résumé de façon inadéquate.
• Instructions ignorées. Si Claude cesse de suivre les conventions du projet qu'il respectait correctement plus tôt, le contenu CLAUDE.md peut avoir été écarté. Exécutez /context pour vérifier.
• Réponses lentes et coûteuses. Un contexte volumineux consomme des jetons à chaque message. Si les coûts augmentent, /context vous montrera pourquoi.

Une chose à noter : les affirmations concernant des seuils de compaction universels (un pourcentage spécifique de remplissage auquel la qualité baisse toujours) ne sont pas soutenues par la documentation officielle. Le moment opportun de compacter dépend de la tâche. L'heuristique approximative de plusieurs praticiens est d'agir à une limite de phase naturelle, avant de constater une dégradation, pas après. Mais votre expérience variera selon le type de tâche, le modèle, et la proportion de votre contexte constituée de code dense par rapport à la conversation.

FAQ

Est-ce que `/compact` consomme des jetons ?

Oui. Le passage de compaction lui-même est un appel au modèle et consomme des jetons. L'exécuter manuellement à une limite de phase coûte généralement moins que de laisser le passage automatique se déclencher à un niveau d'utilisation élevé, car le résumé qu'il produit est plus propre et vous dépensez moins de jetons sur les messages qui suivent.

Est-ce que `/clear` affectera mon `CLAUDE.md` ?

Non. CLAUDE.md est un fichier sur disque. /clear supprime uniquement la conversation et la mémoire de la session. Votre CLAUDE.md se recharge automatiquement la prochaine fois que Claude Code lit votre répertoire de projet.

Puis-je compacter juste une partie de la conversation ?

Oui. Exécutez /rewind, sélectionnez un message, et choisissez « Résumer à partir d'ici » ou « Résumer jusqu'à ici ». La documentation officielle de la fenêtre contextuelle décrit ce que chaque option conserve. Cela est utile quand un fil de débogage spécifique encombre le contexte mais la conversation antérieure reste importante.

Les worktrees du même référentiel partagent-ils le contexte ?

Ils partagent la mémoire automatique locale à la machine, selon la documentation officielle de la mémoire. Ils ne partagent pas le contexte de session. Chaque session de worktree dispose de sa propre fenêtre contextuelle.

Qu'advient-il des définitions d'outils MCP après une compaction ?

La documentation officielle indique que le contenu de démarrage, y compris les définitions d'outils MCP, se recharge automatiquement après un passage de compaction. Vous ne devriez pas avoir besoin de réenregistrer les outils manuellement, mais il vaut la peine d'exécuter /context après une compaction sur une session complexe pour confirmer que la répartition semble correcte.

La mise en garde la plus importante dans tout cela : au moment où vous remarquez une dégradation de la qualité, votre résumé de compaction inclut probablement des résultats confus aux côtés des bons. Compactez à la fin d'une phase propre, pas au début d'une phase désordonnée.