Opus 4.6 dispose maintenant d'un contexte de 1M de tokens : mes tests concrets

Opus 4.6 dispose maintenant d'un contexte de 1M de tokens : mes tests concrets

J'en étais à 47 messages dans une session Claude Code mardi dernier — en train de refactorer un monolithe Laravel tentaculaire en services de domaine — quand le modèle a commencé à halluciner des noms de fonctions qui n'existaient pas. Pas des noms aléatoires. Des noms qui correspondaient presque à de vraies fonctions de fichiers que je lui avais fournis vingt minutes plus tôt. Le contexte s'était dégradé. Le modèle se noyait dans sa propre mémoire, confondant le fichier A avec le fichier B, inventant des méthodes au nom plausible qui n'existaient nulle part dans ma base de code.

J'ai vidé le contexte, réinjecté les fichiers critiques et recommencé. Encore. Pour la troisième fois de la journée.

Si vous avez utilisé un grand modèle de langage pour du vrai travail de développement, vous connaissez exactement cette douleur. On atteint un mur aux alentours de 100K-120K tokens où le modèle cesse d'être un collaborateur et devient un handicap. Chaque utilisateur avancé de Claude Code que je connais a développé le même réflexe : surveiller le compteur de tokens, nettoyer tôt, réamorcer souvent. Ça marche. Mais c'est épuisant. Et ça signifie qu'on ne peut jamais vraiment donner au modèle une base de code massive et dire "comprends tout ça".

Ça a changé le 13 mars 2026. Anthropic a discrètement déployé des fenêtres de contexte de 1 million de tokens pour Opus 4.6 et Sonnet 4.6 — un bond de 5x par rapport au plafond précédent de 200K. Et après avoir passé trois jours à pousser ça dans ses limites, je peux vous dire : ce n'est pas une amélioration incrémentale. C'est la plus grande avancée pratique de Claude depuis que j'ai commencé à l'utiliser quotidiennement.

Mais le chiffre brut n'est même pas la partie intéressante. Ce qui est intéressant, c'est à quel point le modèle se dégrade peu sur cet immense contexte. Et c'est là que l'histoire mérite d'être racontée.

Qu'est-ce que la dégradation de contexte — et pourquoi 1M de tokens seul ne suffit pas

Voici le secret que la plupart des entreprises d'IA ne veulent pas aborder ouvertement : une fenêtre de contexte plus grande ne signifie rien si le modèle ne peut pas réellement utiliser l'information qui se trouve aux confins de celle-ci.

Ce problème a un nom. La dégradation de contexte (context rot). C'est le phénomène où les performances du modèle se dégradent — parfois de façon catastrophique — à mesure que le contexte d'entrée dépasse un certain seuil. Imaginez lire un roman de 500 pages d'une traite versus une nouvelle de 50 pages. À la page 400, votre souvenir d'un détail spécifique de la page 12 est... flou au mieux.

Les modèles précédents souffraient énormément de ce problème. Donnez à Opus 4.5 plus d'environ 100K tokens, et sa capacité à se rappeler des détails spécifiques dispersés dans l'entrée chutait brutalement. Le modèle acceptait techniquement 128K tokens. Mais accepter des tokens et raisonner dessus sont deux choses très différentes.

Google a fait le même pari avec Gemini — des fenêtres de contexte massives qui sonnaient bien dans les supports marketing mais performaient de façon inconsistante quand on avait réellement besoin que le modèle trouve une configuration spécifique enfouie dans une entrée volumineuse. J'ai testé Gemini 3.1 Pro sur exactement ce type de tâche. Les résultats n'inspiraient pas confiance.

Alors quand Anthropic a annoncé 1M de tokens, ma première question n'était pas "quelle taille ?" C'était "combien oublie-t-il ?"

La réponse m'a surpris. Et elle est appuyée par un benchmark spécifique que je pense que tout développeur devrait comprendre.

Le test des huit aiguilles : pourquoi ce benchmark compte

Anthropic utilise un test appelé l'évaluation des "huit aiguilles". Le concept est simple mais impitoyable : disperser huit informations spécifiques et distinctes à travers un contexte d'entrée massif. Puis demander au modèle de se rappeler des huit.

C'est comme cacher huit phrases spécifiques dans un document de 3 000 pages et demander à quelqu'un de toutes les retrouver sans en manquer aucune. Pas approximativement. Pas "j'en ai trouvé six sur huit". Les huit, avec des détails précis.

Ce test compte parce qu'il mesure quelque chose que la plupart des benchmarks ignorent — la capacité à maintenir un rappel granulaire sur l'ensemble de la fenêtre de contexte, pas seulement le début et la fin. Les modèles qui obtiennent de bons scores aux huit aiguilles sont des modèles auxquels vous pouvez réellement faire confiance avec de grandes bases de code, l'analyse de longs documents et des sessions de refactoring multi-fichiers.

Voici les chiffres. Regardez-les attentivement :

Relisez ça. Opus 4.5 a obtenu 27,1 avec environ 128K tokens. Opus 4.6 a obtenu 78,3 avec un million de tokens. Ce n'est pas juste une fenêtre plus grande — c'est presque le triple d'efficacité de rappel à presque huit fois la longueur de contexte. Le modèle n'accepte pas seulement plus de tokens. Il raisonne réellement dessus d'une manière que la génération précédente ne pouvait pas atteindre.

Et oui — GPT 5.4 atteint à peu près le même score aux huit aiguilles. Crédit là où il est dû. Mais GPT 5.4 n'a pas publié de fenêtre de contexte maximale claire, et dans mes tests, ses performances pratiques sur de très longues sessions de codage n'égalent pas tout à fait les chiffres des benchmarks synthétiques. Plus de détails quand j'arriverai aux résultats concrets.

Les chiffres de Gemini 3.1 Pro méritent aussi d'être notés. Le modèle de Google a obtenu 26,0 — essentiellement à égalité avec la génération précédente Opus 4.5, malgré le fait que Google présente la fenêtre de contexte de Gemini comme un différenciateur clé. Grandes fenêtres, rappel médiocre. C'est le schéma qu'Anthropic vient de briser.

Voici la traduction pratique : sur 1 million de tokens, Opus 4.6 ne montre qu'environ 14% de baisse d'efficacité par rapport à ses performances à 256 tokens. Réfléchissez-y. Vous pouvez lui fournir près de mille pages de code, de documentation et d'historique de conversation, et il conserve 86% de sa capacité en contexte court. Ce n'est pas parfait. Mais c'est utilisable d'une manière qu'aucun modèle précédent n'a été.

La règle des 2% : une heuristique pratique pour la gestion des tokens

Après avoir mené mes propres tests parallèlement aux benchmarks publiés, j'ai abouti à une heuristique approximative suffisamment précise pour planifier : attendez-vous à environ 2% de baisse d'efficacité pour chaque tranche supplémentaire de 100K tokens de contexte.

À 100K tokens : ~2% de dégradation. À peine perceptible. À 200K tokens : ~4% de dégradation. Encore extrêmement solide. À 500K tokens : ~10% de dégradation. Vous remarquerez occasionnellement un rappel légèrement moins précis. À 1M de tokens : ~14% de dégradation. Le modèle travaille plus dur, mais reste fonctionnel.

C'est une ligne directrice, pas une loi. La dégradation réelle dépend de ce qui se trouve dans votre contexte — du code homogène dans un seul langage se dégrade différemment d'un mélange de documentation, code, configs et historique de conversation. Mais comme outil de planification, la règle des 2% a bien tenu lors de mes trois jours de tests.

Ce que ça signifie concrètement : l'ancien conseil de "vider votre contexte à 100K-120K tokens" n'est plus une règle absolue. Vous pouvez aller bien au-delà maintenant. Devriez-vous pousser jusqu'à 1M systématiquement ? Probablement pas — et j'expliquerai pourquoi dans la section implémentation. Mais le plafond opérationnel s'est déplacé considérablement vers le haut.

La meilleure pratique précédente était ancrée dans une douleur réelle. Au-delà de 120K tokens sur Opus 4.5, on commençait à voir le modèle confondre des noms de variables similaires, fusionner des détails de fichiers différents, ou "oublier" des contraintes définies en début de conversation. Ces problèmes ne disparaissent pas à 1M de tokens — mais ils ont été repoussés si loin que la plupart des sessions réelles ne les atteindront jamais.

Ce changement transforme la façon dont je structure l'ensemble de mon workflow. Et il devrait probablement transformer le vôtre aussi.

Comment j'utilise concrètement ça dans Claude Code au quotidien

La théorie c'est bien. Que donnent 1M de tokens quand on livre du code ?

Je passe entre quatre et dix heures par jour dans Claude Code. C'est mon environnement de développement principal — pas un assistant que je consulte occasionnellement. Je l'utilise pour tout, de l'écriture de nouvelles fonctionnalités au débogage de problèmes en production en passant par le refactoring de structures de modules entiers. Avant la mise à jour à 1M de contexte, mon workflow ressemblait à ça :

1. Je démarre une session avec le prompt système et les fichiers clés (~15K tokens)
2. Je travaille sur les tâches, fournissant des fichiers et recevant des résultats
3. Je surveille le compteur de tokens nerveusement
4. Autour de 100K-120K tokens, je remarque les premiers signes de dérive — suggestions répétées, noms de variables légèrement incorrects, contraintes oubliées
5. Je vide le contexte, réinjecte les fichiers critiques, perds le fil de conversation
6. Je répète les étapes 2-5 deux ou trois fois par tâche majeure

Maintenant ? Je démarre une session et je... travaille. Pendant des heures. Sans la charge mentale constante de la gestion du contexte. La réduction de charge cognitive est difficile à surestimer. C'est comme la différence entre conduire avec une jauge d'essence toujours proche du vide versus avoir un plein. On arrête de s'inquiéter de la ressource et on se concentre sur la route.

Voici un exemple concret de cette semaine. Je migrais une application SaaS multi-tenant d'une architecture à base de données partagée vers un modèle de base de données par tenant. Ça impliquait de toucher 23 fichiers : modèles, migrations, middleware, fichiers de config, suites de tests et scripts de déploiement. Avec l'ancienne fenêtre de contexte, j'aurais eu besoin d'au moins trois sessions séparées, à chaque fois en rétablissant quels fichiers avaient été modifiés et quelle était la stratégie de migration globale.

Avec la fenêtre de contexte de 1M, j'ai chargé les 23 fichiers d'entrée (~85K tokens), plus la documentation de migration existante (~12K tokens), plus mes notes d'architecture (~8K tokens). Ça fait environ 105K tokens juste pour le contexte initial — déjà au-delà de l'ancienne "zone de danger". Puis j'ai travaillé la migration fichier par fichier, le modèle maintenant une conscience parfaite de chaque changement que nous avions fait tout au long de la session. La session a atteint environ 340K tokens avant que je termine.

Pas une seule fois je n'ai eu besoin de vider. Pas une seule fois le modèle n'a confondu une requête avec portée tenant avec une globale. Pas une seule fois je n'ai dû dire "rappelle-toi, on a déjà changé le middleware à l'étape 4".

Cette session m'aurait pris une journée entière avec les anciennes limites de contexte, entre le réamorçage et les ré-explications et la correction d'erreurs causées par la perte de contexte. Elle a pris quatre heures.

Une note sur le buffer d'autocompactage de Claude Code

Un point qui m'a troublé au début : Claude Code utilise toujours un buffer d'autocompactage de 33K tokens. C'est la fenêtre glissante de conversation récente que le modèle garde en mémoire de travail active, séparée du contexte plus large.

La fenêtre de contexte de 1M ne change pas la taille de ce buffer. Ce qu'elle change, c'est le contexte total que le modèle peut référencer — vos fichiers, votre prompt système, l'historique complet de conversation et le buffer d'autocompactage combinés. Le buffer reste à 33K tokens de mémoire "chaude", mais désormais la mémoire "tiède" s'étend à 1M de tokens au lieu de 200K.

En pratique, ça signifie que le modèle est toujours le plus performant sur vos échanges les plus récents (le buffer) mais peut maintenant remonter beaucoup plus loin dans l'historique de conversation et les fichiers chargés sans perdre le fil. La combinaison fonctionne bien. Je n'ai pas ressenti le besoin d'un buffer plus grand — la fenêtre active de 33K gère le va-et-vient immédiat, et le contexte élargi gère tout le reste.

Et le coût ? Anthropic a fait un choix intelligent

Voici quelque chose qui a failli passer inaperçu dans l'annonce mais qui compte énormément pour quiconque fait tourner des sessions sérieuses de Claude Code : Anthropic a supprimé le multiplicateur de coût pour le contexte au-delà de 200K tokens.

Auparavant, utiliser du contexte au-delà de la fenêtre standard venait avec une pénalité tarifaire. Le multiplicateur exact variait, mais ça signifiait qu'une session de 400K tokens coûtait sensiblement plus cher par token qu'une session de 100K tokens. Ça créait une incitation perverse — vous étiez financièrement pénalisé pour utiliser la pleine capacité du modèle.

Maintenant ? Tarification forfaitaire. Que votre session utilise 9K tokens ou 900K tokens, le coût par token est le même. Vous payez pour ce que vous consommez, sans prime pour en consommer beaucoup.

C'est disponible sur le plan Max de Claude Code, Teams et Enterprise. Si vous êtes sur l'un de ces plans — et si vous lisez ce blog, vous devriez probablement l'être — la fenêtre de contexte de 1M est déjà active. Pas de feature flag. Pas de liste d'attente. C'est juste là.

Le changement tarifaire compte parce qu'il supprime la dernière barrière pratique à l'utilisation effective du contexte élargi. Avant, je vidais parfois le contexte tôt non pas parce que le modèle se dégradait, mais parce que je surveillais ma facture API grimper. Ce calcul a disparu. Je peux maintenant prendre des décisions de gestion de contexte basées uniquement sur la qualité, pas sur le coût.

Si vous préférez que quelqu'un configure et optimise les workflows Claude Code pour les besoins spécifiques de votre équipe, j'accepte exactement ce type de mission. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

Ma stratégie de contexte recommandée pour mars 2026

Bien, vous avez 1M de tokens disponibles. Devriez-vous les utiliser tous, tout le temps ? Non. Voici la stratégie que j'ai adoptée après trois jours de tests délibérés.

Étape 1 : Chargez votre contexte critique d'entrée de jeu

Au début de chaque session, chargez les fichiers et la documentation qui comptent le plus. Ne les distillez pas — donnez au modèle l'image complète dès le départ. Ça exploite la zone de rappel la plus forte du modèle (le début du contexte) pour vos informations les plus importantes.

Pour une session de codage typique, ma charge initiale ressemble à ça :

- System prompt and project conventions (~5K tokens)
- Architecture documentation (~8-15K tokens)
- All files I expect to modify (~40-100K tokens)
- Related test files (~20-40K tokens)
- Recent git diff for context on what's changed (~5-10K tokens)

C'est entre 80K et 170K tokens avant le premier message. Avec l'ancien modèle, ça m'aurait laissé presque plus de place pour travailler. Maintenant c'est moins de 20% de mon contexte disponible.

Étape 2 : Définissez votre seuil personnel de dégradation

En vous basant sur l'heuristique de 2% par 100K, décidez de combien de dégradation vous êtes à l'aise :

• Conservateur (minimiser la dégradation) : Videz ou compactez autour de 200K tokens. Vous connaîtrez ~4% de dégradation — essentiellement imperceptible dans le travail quotidien. C'est ce que je recommanderais pour du refactoring critique en production où la précision n'est pas négociable.

• Équilibré (mon choix par défaut) : Travaillez jusqu'à 400K-500K tokens avant d'envisager un nettoyage. À ~10% de dégradation, le modèle est toujours très performant, et vous évitez la perte de productivité du réamorçage. C'est là que j'opère pour la plupart de mes sessions de codage.

• Étendu (continuité maximale) : Poussez vers 700K-1M de tokens pour les sessions où maintenir le fil complet de la conversation compte plus que le rappel maximal — comme les discussions exploratoires d'architecture ou les longues sessions de débogage où chaque tentative précédente est un contexte pertinent.

Étape 3 : Surveillez les signaux spécifiques de dégradation

Même avec la gestion de contexte améliorée, la dégradation finit par apparaître. Voici ce qu'il faut guetter :

• Confusion de noms de variables : Le modèle commence à mélanger des variables aux noms similaires provenant de fichiers différents. C'est généralement le premier signe.
• Dérive des contraintes : Les instructions du début de session commencent à être partiellement ignorées. Vous remarquez que le modèle ne suit pas une règle de formatage ou saute une étape que vous aviez spécifiée.
• Fabrication assurée : Le modèle affirme quelque chose sur votre code avec assurance, mais c'est subtilement faux — une signature de fonction avec le mauvais ordre de paramètres, ou une méthode qui existe sur une classe différente de celle indiquée.
• Suggestions répétitives : Vous demandez une nouvelle approche et recevez quelque chose de très similaire à ce qu'il a déjà tenté. Le modèle perd le fil de ce qui a été essayé.

Quand vous repérez deux ou plus de ces signaux en succession rapide, c'est votre signal. N'attendez pas que ça empire. Videz le contexte, réamorcez avec vos fichiers critiques et continuez.

Étape 4 : Utilisez des signets intentionnels

C'est une technique que j'ai développée spécifiquement pour les longues sessions. Tous les 150K-200K tokens, je dépose un message "signet" :

Quick checkpoint: we've completed [X, Y, Z]. Current state:
- File A: modified (added tenant scoping)
- File B: not yet touched
- File C: needs migration update
Next: work on File B's query layer.

Ça sert deux objectifs. Premièrement, ça me force à organiser ma propre réflexion sur l'état de la session. Deuxièmement, ça donne au modèle un résumé propre et récent de l'état du projet qui tombe dans son buffer d'autocompactage. Même si le rappel des détails du début de session s'est légèrement dégradé, le signet fournit un nouveau point d'ancrage.

J'ai constaté que cette seule technique vaut plus que n'importe quelle quantité de comptage de tokens. Un signet bien placé à 300K tokens maintient le modèle plus affûté que pas de signet à 200K tokens.

Pourquoi je pense que ça compte plus que Loops ou Beat

Je veux mettre ça en perspective. Au cours des six derniers mois, Anthropic a livré beaucoup de fonctionnalités pour Claude Code. Loops (la capacité du modèle à exécuter et tester du code de façon itérative). Beat (la capacité à gérer des tâches en arrière-plan). Améliorations du raisonnement étendu. Raffinements de l'utilisation d'outils. Du bon travail. Des choses que j'utilise quotidiennement.

Mais la fenêtre de contexte de 1M est différente en nature, pas seulement en degré. Voici pourquoi.

Chaque autre fonctionnalité améliore ce que le modèle peut faire au sein d'une seule interaction. Loops le rend meilleur pour itérer. Beat le rend meilleur pour le multitâche. Thinking le rend meilleur pour raisonner. Tout ça concerne la capacité à un instant donné.

L'expansion de la fenêtre de contexte améliore ce que le modèle peut savoir pendant une session. C'est une question de mémoire, pas de compétence. Et la mémoire s'avère être le goulot d'étranglement qui limitait silencieusement tout le reste.

Un modèle avec une capacité de codage parfaite mais une amnésie après 100K tokens est un modèle qui ne peut travailler que sur des petits problèmes — ou travailler sur de gros problèmes en petits morceaux déconnectés. Un modèle avec la même capacité de codage et 1M de tokens de mémoire fiable peut s'attaquer à des projets qui étaient auparavant hors de portée du développement assisté par IA.

Je parle de refactoring d'applications complètes. De changements d'architecture multi-services. De migrations de patterns à l'échelle de toute la base de code. D'audits de sécurité qui doivent croiser chaque endpoint d'authentification avec chaque vérification d'autorisation. Ce sont les tâches sur lesquelles des développeurs humains passent des semaines et manquent encore des choses. Ce sont aussi les tâches où une IA avec suffisamment de contexte pourrait trouver des patterns et des incohérences qu'aucun humain ne repérerait.

On n'y est pas encore complètement. La dégradation de 14% à 1M de tokens signifie qu'il faut encore être réfléchi sur la façon d'utiliser le contexte. Mais on est suffisamment proches pour que j'aie commencé à aborder avec Claude Code des tâches que j'aurais considérées impossibles trois mois plus tôt.

Le paysage concurrentiel rend ça encore plus intéressant. GPT 5.4 est au coude à coude sur le benchmark des huit aiguilles avec ~78 contre 78,3 pour Opus 4.6 — une différence statistiquement insignifiante. Mais le modèle de tarification forfaitaire d'Anthropic et l'intégration Claude Code lui donnent un avantage pratique pour les développeurs qui vivent dans le terminal. J'ai utilisé les deux extensivement. Sur le rappel brut, ils sont à égalité. Sur l'intégration workflow pour les tâches de codage, l'implémentation de Claude Code est plus fluide.

Gemini 3.1 Pro, malgré l'investissement massif de Google dans la recherche sur le contexte long, est une génération complète en retard sur la qualité de rappel. Un score de 26,0 au test des huit aiguilles — presque identique à la génération précédente Opus 4.5 — suggère que Google a résolu le problème de la taille de fenêtre de contexte sans résoudre le problème de la qualité de contexte. Grande fenêtre, mémoire qui fuit. Ce n'est pas une combinaison à laquelle je ferais confiance pour une session de refactoring de 20 fichiers.

Les limitations honnêtes — ce que ça ne résout pas

Je mentirais si je disais que la fenêtre de contexte de 1M n'a que des avantages. Il y a de vrais compromis et limitations que vous devriez connaître avant de changer votre workflow.

La latence augmente avec la taille du contexte. Plus de tokens signifie plus à traiter à chaque tour. J'ai remarqué que les temps de réponse doublent approximativement entre 100K et 500K tokens de contexte. À 800K+, il y a un délai perceptible avant que le modèle commence à générer. Ce n'est pas terrible — on parle de secondes, pas de minutes — mais si vous êtes habitué à des réponses quasi instantanées sur des contextes courts, le décalage est perceptible.

Toute dégradation n'est pas égale. La dégradation moyenne de 14% masque une variance significative selon ce que vous demandez au modèle de se rappeler. Des valeurs numériques spécifiques (comme des numéros de port ou des chaînes de version) enfouies profondément dans le contexte se dégradent plus vite que des patterns structurels (comme "ce module gère l'authentification"). Si votre travail dépend d'un rappel précis de détails du contexte initial, la dégradation effective pour votre cas d'usage pourrait être supérieure à 14%.

Le buffer d'autocompactage reste à 33K. Cela signifie que la mémoire de travail active du modèle n'a pas changé. Si vous faites un va-et-vient rapide sur un problème spécifique, le buffer de 33K est votre vraie contrainte, pas la fenêtre de contexte de 1M. Le contexte élargi aide avec le rappel "froid" — remonter à quelque chose de plus tôt dans la session — mais ne rend pas le modèle meilleur pour jongler avec plusieurs fils actifs dans la conversation immédiate.

Vous pouvez encore le dépasser. J'ai réussi à genuinement confondre le modèle pendant une session où je modifiais simultanément des fichiers interdépendants à travers trois microservices. Autour de 600K tokens, il a commencé à suggérer des changements au Service A qui étaient en conflit avec des changements que nous avions déjà faits au Service B vingt minutes plus tôt. La technique des signets a aidé, mais n'a pas entièrement éliminé le problème.

Ce ne sont pas des obstacles rédhibitoires. Ce sont le genre de limitations qu'on apprend à contourner une fois qu'on les comprend. Mais je préfère que vous les entendiez de moi plutôt que de les découvrir pendant un déploiement critique.

Ce que ça signifie pour les six prochains mois

Je construis avec des outils de codage IA depuis que GPT-3.5 les a rendus viables. Tout au long de cet arc, un schéma a été constant : les plus grands bonds en avant viennent toujours de l'expansion de ce que le modèle peut tenir en contexte, pas de le rendre marginalement plus intelligent sur une tâche unique.

Le saut de 4K à 32K tokens a rendu le codage assisté par IA possible. Le saut de 32K à 128K l'a rendu pratique pour de vrais projets. Le saut de 200K à 1M le rend viable pour des bases de code entières.

On s'approche d'un seuil où un modèle peut contenir toute votre application — chaque fichier, chaque test, chaque config — dans une seule fenêtre de contexte. Pour une application typique de taille moyenne (200-500 fichiers), on y est déjà. Pour les grandes bases de code d'entreprise, on est peut-être à une génération de distance.

Quand ça arrivera, le changement de workflow sera fondamental. On arrête de penser "quels fichiers l'IA doit-elle voir ?" pour commencer à penser "que devrais-je demander à l'IA de faire sur toute ma base de code ?" C'est un type qualitativement différent d'assistance au développement. C'est la différence entre une IA qui vous aide à éditer un fichier et une IA qui comprend votre système.

Je pense qu'on regardera mars 2026 comme le mois où cette transition a véritablement commencé. Pas parce que 1M de tokens est le chiffre final — ce n'est pas le cas. Mais parce que c'est la première fois que le contexte était suffisamment grand et le rappel suffisamment fiable pour que l'assistance IA à l'échelle de toute la base de code fonctionne réellement.

Pour la première fois dans mon expérience, la fenêtre de contexte n'est pas le goulot d'étranglement. Et ça signifie que le goulot d'étranglement est maintenant... nous. Notre capacité à poser les bonnes questions, structurer les bons prompts et concevoir des workflows qui tirent parti de ce qui est soudainement possible.

J'accepte ce compromis. À chaque fois.

Foire aux questions

Comment activer la fenêtre de contexte de 1M pour Claude Opus 4.6 ?

Aucune configuration requise. La fenêtre de contexte de 1M est automatiquement disponible sur le plan Max de Claude Code, Teams et Enterprise depuis mars 2026. Si vous êtes sur l'un de ces plans, elle est déjà active.

Dois-je vider le contexte à 200K tokens ou pousser jusqu'à 1M ?

Pour du travail critique de précision comme du refactoring de production, videz autour de 200K tokens. Pour des sessions exploratoires ou du long débogage, poussez confortablement à 400K-500K. L'heuristique de 2% de dégradation par 100K tokens vous aide à décider. Pour une analyse plus détaillée, consultez Ma Stratégie de Contexte Recommandée ci-dessus.

La fenêtre de contexte de 1M coûte-t-elle plus cher que le standard de 200K ?

Non. Anthropic a supprimé le multiplicateur de coût pour le contexte au-delà de 200K tokens. La tarification est forfaitaire que votre session utilise 9K ou 900K tokens. Consultez Et le Coût ? ci-dessus pour les détails.

Comment Opus 4.6 se compare-t-il à GPT 5.4 sur les tâches de contexte long ?

Les deux modèles obtiennent environ 78 au benchmark des huit aiguilles — statistiquement à égalité sur le rappel brut. Opus 4.6 a un léger avantage dans l'intégration au workflow Claude Code et la tarification forfaitaire. Consultez le tableau comparatif des benchmarks dans la section Le Test des Huit Aiguilles.

Qu'est-ce que le buffer d'autocompactage de Claude Code et est-ce que 1M le change ?

Le buffer d'autocompactage de Claude Code reste à 33K tokens — c'est la mémoire de travail "chaude" pour le va-et-vient immédiat. L'expansion à 1M augmente le contexte total référençable, pas le buffer actif. Consultez Une Note sur le Buffer d'Autocompactage de Claude Code pour comprendre comment les deux interagissent.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io