La context window 1M de Claude Code est live. Voilà ce qui a vraiment changé.

La context window de 1 million de tokens pour Claude Code est passée en general availability le 13 mars. Sans surcoût, disponible immédiatement sur Opus 4.6 et Sonnet 4.6. La limite précédente était 200K tokens. Cinq fois plus grand, même prix.

Je fais tourner des sessions sur une codebase en production depuis. Voilà ce qui a changé dans le travail quotidien. Et la partie que l'annonce passe sous silence.

Ce qui s'est vraiment amélioré en sessions réelles

Le changement le plus concret, c'est la fréquence de compaction.

Dans les longues sessions Claude Code, quand l'agent tape son plafond de context, il compacte. Il résume ce avec quoi il travaillait. Un peu de précision se perd. Tu te retrouves à re-feed du context que tu avais passé vingt minutes à construire plus tôt dans la session. Pas un crash. Juste une dérive lente en dehors des specifics.

Depuis la GA 1M, j'ai vu à peu près 15 % d'events de compaction en moins dans les sessions qui dépassaient auparavant 200K tokens. Les sessions en dessous de 150K se sentent identiques. Les sessions qui grandissaient régulièrement au-delà de 180K : refactors multi-fichiers, longues séquences de debug sur des features qui touchent plusieurs modules. La friction baisse nettement.

L'autre changement pratique : les workarounds que j'avais construits sur des mois sont moins critiques. Des fichiers .claudeignore soigneux. Des flags --include ciblés au départ de la session. Du pruning manuel de context avant de lancer des tasks complexes. Ils aident toujours pour la précision. Ils ne sont plus nécessaires pour garder les sessions fonctionnelles.

Moins de friction au plafond. Pas une transformation de la façon dont les sessions Claude Code fonctionnent. Une soupape de décompression qui tire moins souvent.

La différence de pricing qui compte à grande échelle

GPT-5.4 d'OpenAI ship aussi avec une context window de 1M tokens. La capacité est globalement comparable. Le modèle de coût, non.

La window 1M d'Anthropic est flat-rate. Un seul prix du token 1 au token 1 000 000. Pas de surcharge, pas de tier, pas de repricing rétroactif au-delà d'un seuil.

GPT-5.4 facture double au-delà de 272K tokens. Ce repricing s'applique à la requête entière, pas seulement à la portion au-dessus du seuil. Une session de 400K tokens coûte 2x le taux de base pour les 400K tokens, pas pour les 128K tokens au-dessus de 272K.

Pour les sessions Claude Code interactives, ça n'a pas d'importance. Tu paies un abonnement flat. Mais si tu évalues des outils pour une team, si tu fais tourner des pipelines d'agents en CI, ou si tu fais une recommandation de tooling à un CTO, le modèle de coût est une vraie considération. Un pipeline qui tourne 50 sessions par jour à 400K tokens en moyenne est une conversation de budget très différente sur chaque plateforme.

Context rot : ce que l'annonce ne dit pas

Des recherches de Chroma et Epsilla sur le comportement des modèles long-context montrent que la qualité du raisonnement se dégrade de façon non-linéaire à mesure que le context grandit. Pas proportionnellement.

Une session à 800K tokens ne performe pas 20 % moins bien qu'une session à 200K tokens. Sur des tasks qui demandent du raisonnement multi-fichiers soutenu ou la capacité de porter une contrainte d'architecture à travers une longue session, la dégradation atteint 40 à 60 %. Les données de Chroma montrent que la baisse n'est pas linéaire. Il y a une falaise plus raide au-delà de certains seuils. Le modèle ne lit pas les tokens uniformément ; l'attention se dégrade plus le token est loin en arrière.

La window 1M n'a pas changé ça. Elle a changé le plafond, pas la courbe de dégradation.

En pratique : tu peux loader une grosse codebase dans une seule session. Que l'agent raisonne bien dessus dépend de la façon dont le context est structuré, pas seulement du nombre de tokens qu'il contient. Un dump brut de fichiers performe moins bien qu'un summary architectural structuré. L'inclusion large performe moins bien que le loading ciblé.

Sur un projet React Native en production, j'ai systématiquement obtenu de meilleurs résultats avec des sessions qui loadent le module pertinent, les conventions pertinentes depuis CLAUDE.md, et les fichiers spécifiques dans le scope, qu'avec des sessions qui loadent le repository complet. Le context full-repo marche pour les queries rapides de style search. Pour le raisonnement multi-step sur une feature complexe, le context tight est plus rapide et plus précis.

La window 1M, c'est de la marge. Utilise-la quand tu tapes le plafond. Ne l'utilise pas comme substitut à réfléchir à ce dont l'agent a réellement besoin.

Je creuse le design de context et la structure de session dans le cours d'agentic coding.

Le travail de structure compte toujours

Il y a une tentation qui vient avec une plus grande window : arrêter de réfléchir au context et tout loader. J'ai fait tourner des sessions comme ça depuis le 13 mars. C'est pratique. Ça produit un output moins bon sur tout ce qui est architecturalement complexe.

Les sessions qui marchent bien en production restent les sessions structurées.

Un CLAUDE.md qui explique l'architecture de la codebase et les conventions, pas juste l'arbre des fichiers. Des Skills qui loadent du domain knowledge ciblé pour des types de task spécifiques. Un scope clair au départ de la session, pour que l'agent ne raisonne pas sur tous les composants quand tu travailles sur un subsystem.

Une session focus de 80K tokens avec un CLAUDE.md bien construit surperformera une session non-focus de 900K tokens sur la plupart des tasks d'engineering réelles. La window 1M est un plafond, pas un floor que tu dois remplir.

Ce que je guette vraiment

La window 1M, c'est l'histoire d'infrastructure du mois. Deux autres développements sont plus intéressants structurellement.

Computer use a atterri dans Claude Code le 23 mars pour les users Pro et Max. Un agent peut désormais ouvrir un browser, naviguer vers un environnement de staging, et vérifier le comportement UI sans test harness. Je teste ça pour la vérification de feature sur une app en production. Ce n'est pas un remplacement pour les tests scriptés, et ça fail de façon prévisible sur tout ce qui est répétitif. Pour les checks exploratoires : est-ce que cette modal apparaît après un cold launch, est-ce que l'état de navigation persiste correctement. Ça couvre du terrain qu'une suite Playwright ne couvre pas.

Le plus gros shift, c'est les multi-agent teams, actuellement en research preview. Un agent lead, plusieurs agents spécialistes, chacun avec sa propre context window et son propre Git worktree. Le problème de compaction se dissout en grande partie quand les agents ne partagent pas de context. Chaque spécialiste démarre focus sur son slice. Les premières expériences montrent un meilleur output sur le travail multi-composant complexe qu'une seule longue session, parce que le context de chaque agent reste tight.

La window 1M étend la durée de vie utile du modèle actuel : un agent, un context qui grandit. Les multi-agent teams rendent ce modèle optionnel. C'est ça, le shift qui vaut la peine d'être guetté.

Si tu vois de la compaction régulière dans des sessions au-delà de 180K tokens, la GA 1M aide immédiatement. Si tu design des systèmes d'agents from scratch, vise des agents plus petits avec des contexts focus. Un gros agent avec tout loaded est le mauvais modèle pour le travail complexe, quelle que soit la taille de la window.

Je couvre le design de context, la structure de session, et l'orchestration multi-agent dans le cours d'agentic coding.