Les modèles open source de 2026 annoncent 1 million de tokens de contexte, mais ne lisent que par échantillonnage

Les fiches des modèles ouverts récents de 2026 affichent « 1 million de tokens de contexte ». En interne, le tableau est différent : à chaque étape, GLM-5.3 sélectionne 2048 tokens dans l'historique, DeepSeek-V4-Pro travaille avec 1024 blocs compressés, et chez Qwen3.8 et Kimi K3, seule une couche sur quatre voit l'historique en entier. Vladimir Loushine, qui développe des agents IA et des outils pour le code chez Sber, a analysé sur Habr ce que cela implique concrètement. Sa conclusion pour tous ceux qui construisent des agents : la taille de fenêtre annoncée indique combien de tokens peuvent y tenir, pas combien le modèle prend réellement en compte.

Trois schémas de sélection au lieu d'une lecture intégrale

Loushine range les modèles open source récents en trois familles. Il a lu une partie des configurations directement dans le config.json sur Hugging Face et a tiré le reste des fiches et des rapports techniques. Ses conclusions sur ce que le modèle « lit » viennent de son propre examen de l'architecture : les développeurs des modèles n'ont rien affirmé de tel.

• Top-k clairsemé : GLM-5.x, DeepSeek-V4, MiniMax M3. À chaque étape, le modèle ne sélectionne qu'une partie de l'historique : 2048 tokens pour GLM-5.3, 1024 blocs compressés pour DeepSeek-V4-Pro.
• Hybrides « 3 couches linéaires + 1 complète » : Qwen3.5–3.8, Kimi K3, GLM-5.3-Flash. L'attention complète sur tout l'historique n'existe qu'une couche sur quatre.
• Fenêtre glissante plus couches globales : Gemma 4.

Ces trois schémas ont un point commun. Seuls les derniers centaines de tokens sont lus avec certitude et précision. Le reste doit soit passer la sélection par pertinence, soit survivre sous forme compressée. Chez la plupart des modèles, la qualité s'effondre quelque part entre 128 et 256 k tokens. Kimi K3 avec compactage à 300 k tokens fait mieux qu'elle-même avec la fenêtre complète de 1 million. Pour l'économie de l'inférence, la différence est notable : un contexte court et bien empaqueté donne un meilleur résultat et traîne beaucoup moins de tokens.

Pourquoi la règle d'AGENTS.md disparaît vers le centième appel

À chaque étape de génération, chaque couche décide de nouveau sur quels tokens passés regarder, et avec quel poids. Imaginons qu'au début de la session, on ait dit à l'agent de ne pas toucher à un fichier précis. 300 k tokens plus tard, il s'apprête à exécuter une commande qui va affecter ce fichier. Pour que l'interdiction opère, une partie au moins des couches doit atteindre la ligne du début et lui donner un poids sensible. Y parvenir ou non relève de la probabilité, pas du simple fait que le texte se trouve formellement dans la fenêtre.

L'auteur l'illustre avec un caniche. Au début de la séance, le dresseur a dit « non, ne ramasse rien par terre », puis a enchaîné des dizaines de commandes, et dans la tête du chien, il reste surtout le dernier « va jouer ! ». Quand un morceau de saucisse traîne au sol, l'issue est prévisible. La règle d'AGENTS.md joue le rôle de cette première commande, et le carnet du dresseur, « ce qu'on a déjà travaillé », correspond au compactage et au fichier de progression.

Le harnais : où placer le texte et ce qu'il faut verrouiller par des hooks

La thèse centrale de l'article : pour le harnais, l'endroit où l'on place le texte compte plus que ce qu'on y écrit. Cinq techniques fonctionnent le mieux :

• nettoyer les anciennes sorties d'outils pour qu'elles n'encombrent pas la fenêtre ;
• chercher à la demande plutôt que « tout déverser » ;
• révéler progressivement : l'agent reçoit les détails au fur et à mesure du besoin ;
• conserver l'état hors de la fenêtre : fichier de progression, notes, mémoire externe ;
• répéter les règles clés à la fin du contexte, là où l'attention est garantie plus forte.

Une catégorie à part regroupe ce qui ne doit jamais être enfreint. Ces contraintes ne doivent pas reposer sur l'attention du modèle : il faut les verrouiller avec des hooks et des droits d'accès. Si l'interdiction de supprimer ou d'écrire est implémentée comme une vérification avant l'appel de l'outil, peu importe qu'une couche ait ou non atteint cette règle au 300 000e token.

Voici l'ordre pratique proposé pour une équipe qui construit un agent sur des modèles ouverts. D'abord, déterminer l'architecture du modèle choisi via son config.json. Ensuite, garder le contexte de travail dans la plage de 128–256 k tokens au lieu de courir après le million. Dupliquer les règles critiques en fin de contexte, compresser l'historique long, et faire passer les interdictions strictes du texte du prompt au code du harnais.