Lors de mes récents échanges avec des utilisateurs de Claude Code, un thème revient sans cesse : la fenêtre de contexte d'un million de jetons est une arme à double tranchant.
Elle permet à Claude Code de fonctionner de manière autonome plus longtemps et de gérer les tâches de manière plus fiable, mais elle ouvre aussi la porte à une pollution du contexte si vous ne gérez pas vos sessions avec soin.
La gestion des sessions est plus importante que jamais et semble susciter beaucoup de questions. Gardez-vous une seule session ouverte dans un terminal, ou deux ? Repartez-vous de zéro à chaque requête ? Quand faut-il utiliser compact, rewind ou les sous-agents ? Qu'est-ce qui provoque une mauvaise compaction ?
Il y a une quantité surprenante de détails qui peuvent vraiment façonner votre expérience avec Claude Code, et presque tout cela découle de la gestion de votre fenêtre de contexte.
Une introduction rapide au contexte, à la compaction et à la dégradation du contexte
La fenêtre de contexte est tout ce que le modèle peut « voir » d'un coup lorsqu'il génère sa réponse suivante. Elle inclut votre prompt système, la conversation jusqu'à présent, chaque appel d'outil et son résultat, ainsi que chaque fichier qui a été lu. Claude Code dispose d'une fenêtre de contexte d'un million de jetons.
Malheureusement, l'utilisation du contexte a un léger coût, souvent appelé dégradation du contexte (context rot). La dégradation du contexte est le constat que les performances du modèle se dégradent à mesure que le contexte s'agrandit, car l'attention se répartit sur davantage de jetons et le contenu ancien et non pertinent commence à distraire de la tâche en cours. Pour notre modèle à 1 million de contexte, nous observons un certain niveau de dégradation du contexte autour de ~300 à 400 000 jetons, mais cela dépend fortement de la tâche – ce n'est pas une règle absolue.
Les fenêtres de contexte sont une limite stricte, donc lorsque vous approchez de la fin de la fenêtre de contexte, vous devrez résumer la tâche sur laquelle vous travaillez en une description plus petite et continuer le travail dans une nouvelle fenêtre de contexte – nous appelons cela la compaction. Vous pouvez également déclencher la compaction vous-même.
Chaque tour est un point de bifurcation
Disons que vous venez de demander à Claude de faire quelque chose et qu'il a terminé. Vous avez maintenant des informations dans votre contexte (appels d'outils, résultats d'outils, vos instructions) et vous avez un nombre surprenant d'options pour la suite :
- Continuer — envoyer un autre message dans la même session
- /rewind (esc esc) — revenir à un message précédent et réessayer à partir de là
- /clear — démarrer une nouvelle session, généralement avec un résumé de ce que vous venez d'apprendre
- Compacter — résumer la session jusqu'à présent et continuer à partir de ce résumé
- Sous-agents — déléguer la prochaine partie du travail à un agent avec son propre contexte vierge, et ne récupérer que son résultat
Bien que la chose la plus naturelle soit simplement de continuer, les quatre autres options existent pour vous aider à gérer votre contexte.
Quand démarrer une nouvelle session
La nouvelle fenêtre de contexte d'un million de jetons signifie que vous pouvez désormais effectuer des tâches plus longues de manière plus fiable, par exemple lui faire construire une application full-stack à partir de zéro. Mais ce n'est pas parce que votre modèle n'a pas épuisé son contexte que vous ne devriez pas démarrer une nouvelle session.
Notre règle générale est que lorsque vous commencez une nouvelle tâche, vous devriez également démarrer une nouvelle session.
Une zone grise est lorsque vous souhaitez effectuer des tâches connexes où une partie du contexte est encore nécessaire, mais pas tout.
Par exemple, rédiger la documentation d'une fonctionnalité que vous venez d'implémenter. Bien que vous puissiez démarrer une nouvelle session, Claude devrait relire les fichiers que vous venez d'implémenter, ce qui serait plus lent et plus coûteux. Étant donné que la documentation n'est peut-être pas une tâche très sensible en termes d'intelligence, le contexte supplémentaire vaut probablement le gain d'efficacité de ne pas avoir à relire les fichiers pertinents.
Revenir en arrière plutôt que corriger
Si je devais choisir une habitude qui signale une bonne gestion du contexte, ce serait le retour en arrière (rewind).
Dans Claude Code, appuyer deux fois sur Esc (ou exécuter /rewind) vous permet de revenir à n'importe quel message précédent et de relancer une requête à partir de là. Les messages après ce point sont supprimés du contexte.
Revenir en arrière est souvent une meilleure approche que la correction. Par exemple, Claude lit cinq fichiers, essaie une approche, et cela ne fonctionne pas. Votre instinct pourrait être de taper « ça n'a pas marché, essaie X à la place ». Mais la meilleure décision est de revenir en arrière juste après la lecture des fichiers, et de relancer une requête avec ce que vous avez appris. « N'utilise pas l'approche A, le module foo n'expose pas cela — va directement à B. »
Vous pouvez également utiliser « résumer à partir d'ici » pour que Claude résume ce qu'il a appris et crée un message de transition, un peu comme un message à l'itération précédente de Claude de la part de son futur moi qui a essayé quelque chose et cela n'a pas fonctionné.
Compacter vs. sessions vierges
Lorsqu'une session devient longue, vous avez deux moyens de réduire le poids : /compact ou /clear (et repartir de zéro). Ils semblent similaires mais se comportent très différemment.
Compacter demande au modèle de résumer la conversation jusqu'à présent, puis remplace l'historique par ce résumé. C'est une opération avec perte : vous faites confiance à Claude pour décider ce qui était important, mais vous n'avez rien eu à écrire vous-même et Claude pourrait être plus minutieux en incluant les apprentissages ou fichiers importants. Vous pouvez également l'orienter en passant des instructions (/compact focus on the auth refactor, drop the test debugging).
Avec /clear, vous écrivez ce qui compte (« nous refactorisons le middleware d'authentification, la contrainte est X, les fichiers importants sont A et B, nous avons écarté l'approche Y ») et vous repartez à zéro. C'est plus de travail, mais le contexte résultant est ce que vous avez décidé comme pertinent.
Qu'est-ce qui provoque une mauvaise compaction ?
Si vous exécutez beaucoup de sessions de longue durée, vous avez peut-être remarqué des moments où la compaction peut être particulièrement mauvaise. Dans ce cas, nous avons souvent constaté que les mauvaises compactions peuvent se produire lorsque le modèle ne peut pas prédire la direction dans laquelle votre travail va.
Par exemple, l'auto-compaction se déclenche après une longue session de débogage et résume l'investigation, et votre message suivant est « maintenant corrige cet autre avertissement que nous avons vu dans bar.ts ». Mais comme la session était concentrée sur le débogage, l'autre avertissement a peut-être été omis du résumé.
C'est particulièrement difficile car, en raison de la dégradation du contexte, le modèle est à son point le moins intelligent lors de la compaction. Avec un million de contexte, vous avez plus de temps pour /compacter de manière proactive avec une description de ce que vous voulez faire.
Sous-agents et fenêtres de contexte vierges
Les sous-agents sont une forme de gestion du contexte, utiles lorsque vous savez à l'avance qu'une partie du travail produira beaucoup de résultats intermédiaires dont vous n'aurez plus besoin.
Lorsque Claude génère un sous-agent via l'outil Agent, ce sous-agent reçoit sa propre fenêtre de contexte vierge. Il peut faire autant de travail que nécessaire, puis synthétiser ses résultats de sorte que seul le rapport final revienne au parent.
Le test mental que nous utilisons : aurai-je besoin de ce résultat d'outil à nouveau, ou seulement de la conclusion ?
Bien que Claude Code appelle automatiquement les sous-agents, vous pouvez vouloir lui demander explicitement de le faire. Par exemple, vous pouvez lui dire :
- « Lance un sous-agent pour vérifier le résultat de ce travail en fonction du fichier de spécifications suivant »
- « Détache un sous-agent pour lire cette autre base de code et résumer comment elle a implémenté le flux d'authentification, puis implémente-le toi-même de la même manière »
- « Détache un sous-agent pour rédiger la documentation de cette fonctionnalité en fonction de mes modifications git »
Résumé
En résumé, lorsque Claude a terminé un tour et que vous êtes sur le point d'envoyer un nouveau message, vous avez un point de décision.
Avec le temps, nous espérons que Claude vous aidera à gérer cela lui-même, mais pour l'instant, c'est l'une des façons dont vous pouvez guider la sortie de Claude.
