La context window de 1M est sortie, donc la question évidente : est-ce qu'une fenêtre cinq fois plus grande ne résout pas le problème de contexte ? Ce chapitre se clôt sur la claim opposée, à savoir que la context window est l'unique contrainte autour de laquelle tout le reste de l'agentic coding s'articule. Avant que cette leçon n'arrive, le réflexe mérite d'être traité. La fenêtre vient de devenir cinq fois plus grande. La contrainte est-elle même encore réelle ?
Réponse courte : la capacité a changé, le principe non. La fenêtre 1M est de la marge, pas un remplacement pour le contexte structuré. Cette leçon est le pont entre les quick wins que vous venez de voir et la leçon sur la contrainte qui clôt le chapitre. Elle est là pour tuer le réflexe « 1M résout tout » avant que le reste du cours ne bâtisse sur l'hypothèse opposée.
Ce qui s'est réellement amélioré
Une chose s'est améliorée, et ça vaut le coup de la nommer précisément : la compaction se déclenche moins souvent. Dans les sessions qui poussaient au-delà de l'ancien plafond de 200K (refactors multi-fichiers, longues sessions de debugging à travers plusieurs modules), l'agent tape le mur plus tard, donc il résume (et perd de la précision) moins souvent. Les sessions qui ne dépassaient jamais ~150K semblent identiques ; rien n'a changé pour elles. Les workarounds que les gens ont bâtis sur des mois, les fichiers .claudeignore agressifs et le pruning manuel avant une tâche dure, aident toujours pour la précision, mais ils ne sont plus nécessaires juste pour garder une session fonctionnelle.
C'est la vraie victoire : une soupape de décompression qui se déclenche moins souvent. Pas une transformation de comment les sessions fonctionnent.
Context rot : la partie que le headline skip
Voici la partie que l'annonce passe sous silence. La qualité de raisonnement se dégrade non-linéairement à mesure que le contexte grossit, pas proportionnellement. Une session à 800K tokens ne performe pas 20% moins bien qu'une à 200K. Sur les tâches qui nécessitent du raisonnement multi-fichiers soutenu ou de tenir une contrainte architecturale à travers une longue session, la dégradation va de 40 à 60%, et la chute n'est pas lisse : il y a une falaise au-delà de certains seuils. Le modèle ne lit pas les tokens uniformément ; l'attention se dégrade plus un token est loin en arrière.
Le chiffre qui recadre tout
Une session focusée de 80K tokens avec un CLAUDE.md bien bâti surpasse une session non focusée de 900K tokens sur la plupart des tâches d'ingénierie réelles. La fenêtre est un plafond, pas un sol que vous devez remplir.
Sur le raisonnement multi-étapes, un contexte structuré et serré bat un dump full-repo, et la plus grande fenêtre ne change rien à ça
Pricing à l'échelle (le seul endroit où la taille de la fenêtre se voit sur la facture)
Pour une session interactive vous payez un abonnement forfaitaire, donc la taille de la fenêtre est invisible pour votre portefeuille. Elle arrête de l'être au moment où vous passez à l'échelle des pipelines. La fenêtre 1M d'Anthropic est à tarif forfaitaire : un seul prix du token 1 au token 1 000 000, pas de surcharge au-delà d'un seuil. Certains concurrents repricer la requête entière au-delà d'un cutoff (ex. 2x au-delà de ~272K tokens, appliqué à tous les tokens, pas juste le dépassement). Pour un pipeline CI qui fait tourner des dizaines de larges sessions par jour, c'est une conversation budget très différente, et ça connecte directement au math de billing headless que vous verrez au Chapitre 4.
Où ça pointe : des agents plus petits, pas des fenêtres plus grandes
La fenêtre 1M étend la durée de vie utile du modèle à contexte unique qui grandit : un agent, une fenêtre, qui grossit. La réponse structurelle plus intéressante va dans l'autre sens. Les setups multi-agent (un lead, plusieurs spécialistes, chacun avec sa propre fenêtre et son propre worktree) font que le problème de compaction se dissout largement, parce que les agents ne partagent pas de contexte. Chaque spécialiste démarre focusé sur sa tranche. C'est la même logique derrière les subagents (Chapitre 4) et les worktrees parallèles (Chapitre 6).
Donc la conclusion met en place le reste du cours plutôt qu'elle ne vous en excuse : si vous voyez de la compaction régulière au-delà de ~180K tokens, la plus grande fenêtre vous aide aujourd'hui. Si vous designez un système de zéro, allez vers des agents plus petits avec des contextes focusés. Un seul gros agent avec tout chargé est le mauvais modèle pour le travail complexe, peu importe la taille de la fenêtre.
La prochaine leçon est la contrainte elle-même, énoncée en entier. Lisez-la en sachant que la fenêtre a grossi et que la contrainte est restée.