Votre agent de code affiche un million de tokens de contexte. C'est faux.
Ce n'est pas un rapport de bug, et personne ne vous ment vraiment. Mais trois chiffres différents se cachent derrière ce badge « 1M » dans la barre d'état de votre éditeur, et l'écart entre le plus grand et le plus petit explique une bonne partie des comportements déroutants des agents. Si vous avez déjà vu un agent oublier une décision prise vingt minutes plus tôt, ou constaté une facture qui explose sur une session qui semblait courte, c'est généralement pour cette raison.
Mettons des chiffres concrets là-dessus.
Trois chiffres, pas un seul
Chaque outil de code IA possède une fenêtre de contexte qui existe à trois niveaux :
- La fenêtre annoncée — ce que le modèle supporte via l'API. C'est le chiffre marketing.
- Le plafond du harnais — ce que la CLI ou l'IDE vous laisse réellement remplir avant d'intervenir.
- La fenêtre effective — la quantité de contexte sur laquelle le modèle raisonne encore de manière fiable.
Ces chiffres sont très loin les uns des autres.
Codex
GPT-5.5 annonce une fenêtre de 1 050 000 tokens. Codex plafonne ses propres sessions à 400 000. Sur ce total, 272 000 sont alloués à l'entrée et 128 000 réservés à la sortie. La CLI conserve ensuite environ 5 % de marge, ce qui vous laisse à peu près 258 400 tokens d'entrée exploitables.
Soit environ un quart du chiffre annoncé, avant même d'avoir tapé quoi que ce soit.
Claude Code
Claude Opus supporte une fenêtre d'un million de tokens via l'API. L'auto-compaction de Claude Code se déclenche vers 420 000 tokens — environ 42 % de la fenêtre — et ce seuil n'est pas configurable par défaut, ce qui alimente une plainte récurrente sur le tracker d'issues. Sonnet 5 se comporte différemment et compacte plutôt vers 967 000.
Les deux outils paient également un surcoût fixe avant même le début de votre tâche. Le prompt système, un fichier CLAUDE.md ou AGENTS.md, et un seul serveur MCP connecté peuvent consommer ensemble environ 42 000 tokens. Chaque outil MCP renvoie son schéma à chaque tour. Les fichiers AGENTS.md sont lus de la racine aux feuilles au démarrage de la session, plafonnés à 32 Kio. Sur une fenêtre de 200K, le tampon réservé représente à lui seul environ 33 000 tokens.
Antigravity
L'Antigravity de Google affiche 1M dans son interface, mais les développeurs rapportent une compaction qui se déclenche en pratique autour de 256K. Le modèle supporte bel et bien 1M — c'est le harnais qui contraint.
Le schéma est constant : le chiffre du harnais n'est qu'une fraction de celui du modèle, et aucun des deux ne détermine la qualité des réponses de votre agent.
La dégradation du contexte : le chiffre qui compte vraiment
Voici la partie inconfortable. Même le plafond du harnais est optimiste, car la précision du modèle se dégrade bien avant que la fenêtre ne soit pleine.
Le benchmark NoLiMa le démontre avec précision. Les tests classiques de type « aiguille dans une botte de foin » permettent aux modèles de tricher en faisant correspondre littéralement des mots-clés entre la question et l'information enfouie. NoLiMa supprime ce raccourci : l'aiguille et la question partagent un recouvrement lexical minimal, obligeant le modèle à inférer l'association plutôt qu'à reconnaître un motif.
Les résultats sont sévères. À seulement 32K tokens, dix des modèles testés sont tombés sous 50 % de leur propre référence en contexte court. GPT-4o, pourtant parmi les meilleurs, est passé de 99,3 % à 69,7 %.
Trente-deux mille tokens. Pas un million.
Les recherches de Chroma sur 18 modèles de pointe aboutissent au même constat sous un autre angle : des prompts ciblés d'environ 300 tokens battent des prompts complets de ~113 000 tokens sur LongMemEval. Plus de contexte a produit de moins bonnes réponses, pas de meilleures.
Des tests indépendants sur Llama 4 Scout — annoncé à 10M de tokens — montrent un rappel qui se dégrade nettement au-delà d'un million.
L'hypothèse d'ingénierie prudente qui en découle : considérez comme non fiable tout ce qui dépasse environ 50 % de la limite annoncée, et concevez pour bien moins que cela lorsque la précision compte.
Ce que cela vous coûte
Le contexte n'est pas seulement un problème de précision, c'est aussi un problème de facturation, et les deux se cumulent.
Sur Codex, les prompts dépassant 272 000 tokens d'entrée basculent vers une tarification premium : 2x sur l'entrée et 1,5x sur la sortie, contre une base de 5 $ par million de tokens d'entrée et 30 $ par million en sortie. Autrement dit, les tokens les plus susceptibles de dégrader la qualité de votre réponse sont aussi les plus chers que vous achèterez.
Un agent qui remplit sa fenêtre de lectures de fichiers spéculatives paie double pour un contexte qui réduit mesurablement sa précision. C'est le pire quadrant possible, et c'est le comportement par défaut d'un agent laissé sans surveillance sur un dépôt volumineux.
Gestion pratique du budget
Cessez de traiter la fenêtre de contexte comme un espace de stockage. Traitez-la comme un ensemble de travail doté d'un budget de précision strict.
Mesurez d'abord votre surcoût fixe. Avant d'optimiser quoi que ce soit, identifiez ce que vous dépensez avant même le début de la tâche : prompt système, fichiers d'instructions projet, schémas MCP, définitions d'outils. Si un seul serveur MCP vous coûte 42K tokens par tour, ce serveur doit justifier sa présence.
Élaguez les serveurs MCP sans pitié. Les schémas d'outils sont renvoyés à chaque tour. Trois serveurs connectés que vous utilisez rarement constituent une taxe permanente sur chaque requête de la session. Déconnectez ce qui ne sert pas à cette tâche précise.
Gardez les fichiers d'instructions compacts. Un AGENTS.md ou CLAUDE.md qui a enflé jusqu'à plusieurs milliers de lignes est chargé intégralement au démarrage. Déplacez les consignes rarement nécessaires vers des skills ou de la documentation que l'agent charge à la demande, plutôt que de les porter dans chaque session.
Cadrez la tâche, pas le dépôt. « Lis src/auth et résume le fonctionnement des sessions, ne modifie rien » est une bien meilleure ouverture que de pointer l'agent vers l'arborescence entière. Des lectures ciblées gardent l'ensemble de travail réduit et les réponses nettes.
Redémarrez plutôt que de compacter. La compaction est une synthèse avec perte. Si vous approchez du seuil et que la tâche courante est terminée, une session neuve avec une courte note de passation surpasse généralement une session compactée qui traîne des résumés dégradés d'un travail dont vous n'avez plus besoin.
Externalisez la mémoire. Le travail au long cours appartient aux fichiers, pas à la fenêtre. Faites écrire les décisions et l'état sur disque par l'agent, puis relisez-les à la demande. C'est l'idée centrale derrière l'ingénierie du contexte comme discipline — et la raison pour laquelle les architectures RAG restent pertinentes même à l'ère des modèles à un million de tokens.
Vérifiez à des points de contrôle. Comme la dégradation est progressive et silencieuse, l'agent ne vous préviendra pas qu'il commence à perdre le fil. Lancez la suite de tests. Relisez le diff. Demandez à l'agent de reformuler le plan. Détecter la dérive tôt coûte moins cher que de démêler un diff de quarante fichiers bâti sur une spécification à moitié oubliée.
À retenir
La fenêtre d'un million de tokens est réelle au sens où l'API accepte un million de tokens. Elle ne l'est pas au sens où la plupart des développeurs le supposent — à savoir que le modèle raisonnera sur l'ensemble avec la même fidélité que sur un prompt court.
Entre la fenêtre annoncée et la fenêtre effective, vous perdez le plafond du harnais, le surcoût fixe, puis une courbe de précision abrupte qui mord bien avant 32K sur les tâches de récupération difficiles. Concevez sur des limites effectives mesurées plutôt que sur le chiffre inscrit sur la boîte, et la plupart des comportements mystérieux de vos agents cessent d'être mystérieux.
Les équipes qui livrent des workflows d'agents fiables en 2026 ne sont pas celles qui disposent des plus grandes fenêtres de contexte. Ce sont celles qui gardent délibérément leur ensemble de travail réduit.
À lire également :