La Fenêtre de Contexte 1M dans Claude Code
Anthropic a activé la fenêtre de contexte 1M tokens pour Opus 4.6 et Sonnet 4.6 dans Claude Code. Sans header beta, sans surcharge, tarification fixe, et moins de compactions.
Arrêtez de configurer. Commencez à construire.
Templates SaaS avec orchestration IA.
Les limites de contexte ont été la frustration récurrente dans Claude Code depuis le lancement. Cette douleur vient de réduire. Anthropic a activé la fenêtre 1M tokens pour Opus 4.6 et Sonnet 4.6, sans flag beta, sans surcharge, et sans liste d'attente. Les plans Max, Team et Enterprise l'ont déjà activée.
Pense à ça moins comme une montée de version et plus comme 5x la mémoire de travail que ton agent porte. Cette mémoire contient ton codebase, l'historique de tes appels d'outils, et la chaîne de raisonnement sur les longues exécutions. La tarification reste fixe aussi. Une requête de 900 000 tokens coûte le même prix par token qu'une requête de 9 000.
Cette page explique ce que la fenêtre 1M a changé au niveau du produit et des workflows. Si ta vraie question est quand la compaction se déclenche et comment le buffer réservé se comporte, lis le guide Claude Code Context Buffer. Si ta question est de savoir s'il faut continuer, compacter, rewind, ou redémarrer une session, lis le guide Context Management.
200K vs 1M en Un Coup d'Oeil
| Métrique | Avant (200K) | Après (1M) |
|---|---|---|
| Tokens utilisables | ~167K | ~830K |
| Fréquence de compaction | Toutes les 20-30 min sur les tâches complexes | 15% de moins |
| Fichiers chargeables | Petit projet | Monorepo entier |
| Éléments media par requête | 100 | 600 |
| Tarification long-contexte | Premium ($10/$37,50 pour Opus) | Même tarif que les requêtes courtes |
| Header beta requis | Oui (au-dessus de 200K) | Non |
Ce qui a Vraiment Changé en GA
La grande fenêtre était en beta depuis des mois. Le GA, c'est supprimer les frictions qui rendaient la beta pénible.
Tarification fixe sur toute la fenêtre. Le long contexte ne porte plus de premium. Opus 4.6 est à $5/$25 par million de tokens (entrée/sortie). Sonnet 4.6 est à $3/$15. Ta requête de 10K et ta requête de 950K sont facturées au même tarif par token.
Limites de débit complètes partout. Les requêtes plus longues étaient davantage throttlées pendant la beta. Ce plafond a disparu. Un appel de 1M tokens tire le même débit qu'un appel court.
600 éléments media en une seule requête. Les images et pages PDF étaient plafonnées à 100. Le nouveau plafond est 6x plus élevé à 600. Pour le travail sur les design systems, la revue de docs, ou les piles de contrats, c'est un vrai gain.
Plus de toggle de header. Les requêtes au-dessus de 200K nécessitaient un header anthropic-beta. Tous les headers existants sont maintenant simplement ignorés. L'API gère ça.
Live sur multi-cloud. Tu obtiens la fenêtre 1M sur Claude Platform, Microsoft Azure Foundry, et Google Cloud Vertex AI.
Pourquoi Claude Code Se Ressent Différemment Maintenant
Les utilisateurs API obtiennent un gain de tarification et de commodité ici. Les utilisateurs Claude Code obtiennent quelque chose de structurel.
La Compaction Se Déclenche Moins Souvent
Quiconque a poussé Claude Code sur du vrai travail connaît la taxe de compaction. Tu charges des fichiers, enchaînes les appels d'outils, construis le raisonnement, et puis la compaction automatique se déclenche. Claude compresse la conversation pour libérer de l'espace. Les nuances se perdent. Les cas limites disparaissent. Les tâches multi-étapes perdent le fil à mi-chemin.
Jon Bell, CPO d'Anthropic, a mis un chiffre dessus : les événements de compaction ont chuté de 15% depuis le lancement de la grande fenêtre. Pas un benchmark de labo. C'est mesuré sur le vrai trafic Claude Code. Les agents gardent leur contexte et avancent pendant des heures de travail sans oublier ce qu'ils ont chargé au début.
Curieux de la mécanique de quand la compaction se déclenche ? Voir le guide de gestion du buffer de contexte. En bref : Claude Code retient un buffer d'environ 33K tokens, puis compacte quand l'usage atteint environ 83,5%. Un plafond de 1M signifie que tu as environ 5x la marge avant d'atteindre cette limite.
Des Codebases Entiers en Une Seule Passe
À 200K, tu avais environ 150K tokens d'espace de travail une fois le buffer réservé. Bien pour un petit dépôt. Pénible sur tout ce qui est plus grand, parce que tu choisissais constamment quels fichiers charger.
Monte ça à 1M et ta marge utilisable est ~830K. C'est des milliers de fichiers sources. Un monorepo entier. La doc complète à côté du code qu'elle décrit. Claude peut tenir la couche API et le frontend qui l'appelle, la migration et le schéma qu'elle modifie, le fichier de test et le code sous test. Tout en même temps. Tu arrêtes de choisir à la main quels fichiers charger.
Des Traces d'Agent qui Vont Vraiment au Bout
C'est le gain pour les équipes d'agents et les exécutions d'orchestration complexes. Chaque appel d'outil, chaque étape de raisonnement, chaque lecture de fichier s'empile dans le contexte. À 200K, une session multi-agents sur du vrai travail épuisait le budget en 20 à 30 minutes.
Anton Biryukov, ingénieur logiciel chez Ramp, a décrit l'ancien pattern : "Claude Code peut brûler 100K+ tokens en cherchant dans Datadog, Braintrust, des bases de données, et le code source. Puis la compaction se déclenche." À 1M, il cherche, cherche encore, collecte les cas limites, et livre des correctifs. Tout dans une seule session. Rien n'est perdu en chemin.
Le Modèle Peut-il Vraiment Utiliser 1M Tokens ?
Un contexte énorme ne vaut rien si le modèle ne peut pas vraiment rappeler et raisonner sur ce qui s'y trouve. Anthropic a fait tourner deux benchmarks conçus pour tester exactement ça à la marque 1M.
Opus 4.6 obtient 78,3% sur MRCR v2 à 1M tokens. MRCR (Multi-Round Coreference Resolution) vérifie si un modèle peut suivre des entités et les liens entre elles sur un prompt énorme. Presque 80% de précision sur un million de tokens signifie que le modèle ne stocke pas juste les mots. Il sait encore comment des pièces distantes se connectent.
Sonnet 4.6 obtient 68,4% sur GraphWalks BFS à 1M tokens. Ce test mesure à quel point le modèle navigue des structures de graphe plantées dans des entrées longues. Peut-il tracer des chaînes de références sur des centaines de milliers de tokens ? Les deux scores sont présentés comme les meilleures marques pour les modèles frontier à ces longueurs de contexte.
En pratique, ça signifie que Claude peut encore localiser la fonction helper que tu as définie 500K tokens plus tôt et voir comment elle s'accroche au composant que tu édites maintenant.
Comment l'Utiliser dans ton Workflow
Change Tes Habitudes
Arrête de gérer manuellement l'inclusion de fichiers. Chaque appel @file était un compromis à 200K. À 1M, charge simplement ce dont tu as besoin et avance. Charge le fichier de test avec l'implémentation. Charge les types avec le composant. Donne à Claude l'image complète.
Fais tourner les sessions plus longtemps. L'habitude de redémarrer toutes les 30 minutes venait de la survie, pas de la préférence. Avec 5x le plafond, une session peut tourner pendant des heures sur des tâches difficiles. Redémarre quand tu changes vraiment de focus, pas parce que tu es nerveux sur le buffer. Pour les règles sur quand compacter et quand continuer, voir le guide de gestion du contexte.
Mise sur les agents multi-étapes. Le vrai gain n'est pas l'édition rapide. C'est le type de travail où Claude doit rechercher, planifier, implémenter, et vérifier sur beaucoup de fichiers. Cette chaîne se cassait quand la compaction se déclenchait en pleine tâche. Elle tient maintenant dans une seule fenêtre sans drama.
Repense ton playbook d'ingénierie de contexte. Tes stratégies de chargement et de préservation comptent toujours. Elles ont juste plus d'oxygène. Les fondamentaux de notre guide de gestion du contexte tiennent toujours. La pression passe de "rester en vie sous 200K" à "bien utiliser 1M."
Où la Fenêtre 1M Change Vraiment les Résultats
La meilleure façon de penser à la fenêtre 1M n'est pas "Claude peut lire plus." C'est "des classes entières de tâches arrêtent de sembler fragiles."
1. Chasses aux bugs cross-couches
Ancien pattern à 200K :
- charge le frontend
- remarque que le problème est peut-être dans l'API
- décharge des fichiers
- charge l'API
- réalise que le bug dépend aussi du schéma ou d'une migration
- compacte à mi-chemin et perd les premiers indices
À 1M, tu peux souvent garder le composant de page, le handler API, le schéma, la migration, et le test échouant dans une seule session. C'est pas juste pratique. Ça change la qualité de l'analyse de la cause racine.
2. Revue de sécurité sur une vraie limite système
Les revues de sécurité sont avides de contexte parce que le problème ne vit rarement dans un seul fichier.
Une revue sérieuse peut nécessiter :
- le middleware d'auth
- la gestion de session
- le flux de reset-password
- la logique de rate-limit
- les logs d'audit
- les handlers de routes qui exposent la surface
À 200K, tu choisissais quelle couche omettre. À 1M, tu peux revoir le flux complet et poser de meilleures questions sur les risques de takeover, de replay, et les erreurs de limite de privilège.
3. Changements monorepo sans sélectionner chaque fichier manuellement
À 200K, le travail sur de grands dépôts se transformait souvent en gestion de contexte. Tu passais la moitié de la session à décider ce que Claude avait le droit de voir.
À 1M, une migration sur :
- des types partagés
- des contrats API
- des appelants frontend
- des tests d'intégration
s'inscrit bien plus naturellement. Tu as encore besoin de discipline dans le scope. Tu arrêtes juste de faire du triage de tokens toutes les dix minutes.
4. Revue longue de documents et de design
La plus grande fenêtre importe aussi en dehors du code. Les specs produit, les docs de design, les notes d'architecture, les PDFs, les captures d'écran, et les fichiers d'implémentation connexes peuvent tous rester dans la même requête. Ça rend le travail "spec-to-implementation" et "design-to-code" bien plus stable.
Comment Savoir si tu as Vraiment Besoin de 1M
Tu bénéficies probablement de la plus grande fenêtre si tes sessions impliquent régulièrement un ou plusieurs de ces signaux :
| Signal | Pourquoi ça pointe vers 1M |
|---|---|
| Tu continues à choisir à la main quels fichiers Claude peut charger | Le working set est plus grand que l'ancienne fenêtre le tolèrait confortablement |
| La compaction interrompt du vrai travail, pas juste du blabla | Le goulot d'étranglement est du contexte utile, pas du prompting bâclé |
| Ta tâche couvre du code + des docs + des tests + des configs | Les tâches cross-surface consomment rapidement 200K |
| Tu fais tourner de longues traces d'agents ou des workflows lourds en sous-agents | L'historique des outils s'accumule vite |
| Tu reviews des PDFs, des captures d'écran, ou de grands ensembles de référence | Les plafonds media comptent aussi |
Si ton travail est principalement de petites éditions, de petits dépôts, ou des sessions courtes et ciblées, 1M est sympa mais pas transformateur. Le gain apparaît sur les tâches plus larges où le contexte était la principale contrainte.
Ce qui ne Change Pas
L'hygiène de contexte compte toujours. Un plafond de 1M n'est pas un signal pour tout charger et espérer que Claude s'y retrouve. Les fichiers non pertinents brûlent des tokens et diluent le signal que Claude utilise pour se concentrer.
CLAUDE.md, le chargement skills-first, et une gestion propre des sessions sont toujours les meilleures pratiques. Elles ont juste plus de marge de manoeuvre. Si tu suis déjà les patterns d'optimisation d'usage, la grande fenêtre te rend encore plus.
Qui Obtient la Fenêtre 1M
Sur les plans Claude Code, Max, Team et Enterprise, la fenêtre 1M est activée automatiquement avec Opus 4.6. Rien à configurer. L'allocation d'usage supplémentaire que les requêtes long-contexte nécessitaient avant a disparu.
Les utilisateurs API l'obtiennent aux tarifs standard par token. Opus 4.6 à $5/$25 par million de tokens. Sonnet 4.6 à $3/$15. Pas de niveau premium pour le long contexte.
La fenêtre 200K est toujours là comme valeur par défaut pour les requêtes API standard et les plans de niveau inférieur. L'option 1M est liée spécifiquement à Opus 4.6 et Sonnet 4.6.
Ce que Ça Signale
Anthropic ne fait pas que agrandir les fenêtres de contexte. Ils suppriment les compromis qui rendaient les grandes fenêtres pénibles à utiliser. La tarification fixe signifie que tu ne budgètes pas les requêtes longues différemment. Les limites de débit complètes signifient que tu ne perds pas de débit. Supprimer le header beta signifie que le code existant tourne juste.
La direction est claire. La gestion du contexte passe d'une tâche utilisateur à une tâche d'infrastructure. Les modèles s'améliorent de plus en plus dans l'utilisation du long contexte. La tarification garde la porte ouverte. L'outillage se règle tout seul.
Pour les utilisateurs de Claude Code, la conclusion est simple. Tes agents pensent plus longtemps et se souviennent de plus. Construis tes workflows sur cette base, et les tâches qui nécessitaient auparavant une gestion soigneuse des sessions et du contexte choisi à la main commencent à juste marcher. De bout en bout. Dans une seule fenêtre.
Ressources Connexes
- Context Buffer Management -- Comment fonctionne la compaction automatique et le buffer de 33K tokens
- Context Engineering -- Le framework des six piliers pour charger le contexte de façon stratégique
- Context Management -- Stratégies pour garder le contexte critique intact entre les sessions
- Guide de Sélection de Modèle -- Choisir entre Opus 4.6 et Sonnet 4.6 pour différentes tâches
Arrêtez de configurer. Commencez à construire.
Templates SaaS avec orchestration IA.
Référence des paramètres de Claude Code
Chaque clé dans settings.json, la liste complète des variables d'environnement, et la chaîne de priorité à cinq niveaux qui décide quelle config gagne quand managed et user s'affrontent.
Ingénierie contextuelle
L'ingénierie contextuelle décide ce que Claude Code voit, quand il le voit et ce qui reste en dehors. Flux d'informations échelonné, chargement différé et contextes proprement délimités.