La capacité se mesure, ce n'est pas un chiffre d'un million

La ligne « 1M tokens » sur une fiche modèle est un plafond sur ce que l'API acceptera, pas une garantie de ce que le modèle utilisera bien. En août 2026, ofox.ai a envoyé un même document anglais de 420 mots à neuf modèles phares et mesuré un écart de 1,56x dans le nombre de tokens — 614 tokens sur Grok 4.20, 957 sur Claude Opus 5 — pour exactement le même texte. La fenêtre annoncée est une assertion de fiche ; la capacité réelle est une mesure, et selon Theorem 3, une propriété est garantie exactement quand son mécanisme est implémenté et mesure. Le mécanisme ici, c'est le tokenizer plus la courbe de précision de récupération, et ni l'un ni l'autre n'apparaît dans le chiffre de titre.

Ce qu'est réellement une fenêtre de contexte

Une fenêtre de contexte est le budget de tokens pour une seule requête d'API. Tout ce que le modèle lit et tout ce qu'il écrit doit tenir dans un seul nombre, et l'API est sans état — elle ne se souvient pas du dernier appel. À chaque tour, votre application renvoie toute la conversation, et la fenêtre est le plafond de la taille autorisée pour ce renvoi plus la réponse à venir.

C'est pourquoi la fenêtre n'est pas une mémoire, au sens utile. Un produit de chat qui semble se souvenir de votre nom d'une session à l'autre stocke ce texte quelque part et le réinjecte dans la fenêtre à chaque requête. La persistance vit dans votre application, pas dans le modèle.

Ce qui compte dans la fenêtre

Tout ce qui est dans la requête, plus tout ce qui est dans la réponse. Les éléments que les gens oublient sont généralement les plus coûteux :

• Prompt système. Compté à chaque tour, pas une fois par session.
• Historique complet des messages. Chaque tour précédent d'utilisateur et d'assistant que vous renvoyez.
• Définitions d'outils. Noms, descriptions et schémas JSON pour chaque outil que vous déclarez. Sur Claude, ils ajoutent en outre un prompt système d'usage d'outils par modèle, de 286 tokens sur Opus 5 à 675 sur Opus 4.7.
• Résultats d'outils. Souvent le plus gros poste isolé dans une boucle d'agent ; un listing de répertoire ou une réponse d'API peut atteindre des milliers de tokens.
• Tokens de raisonnement. Sur les modèles avec pensée activée, le raisonnement compte et est facturé même quand le texte ne vous est pas renvoyé.
• La réponse elle-même. C'est pourquoi max_tokens et la fenêtre de contexte interagissent : une requête qui ne laisse pas de place à la sortie est tronquée.

« 1M tokens », ce sont neuf nombres différents

[UNIQUE INSIGHT] La fenêtre annoncée est un plafond sur ce que l'API acceptera, pas sur ce que le modèle utilisera bien — et l'écart entre les deux est une question de benchmark, pas de fiche. Le mécanisme qui détermine la capacité réelle, c'est le tokenizer plus la courbe de précision de récupération, et ni l'un ni l'autre n'apparaît dans le chiffre de titre.

Parmi les neuf modèles phares qu'ofox.ai a catalogués le 2026-08-12, « 1M » se résout en neuf entiers distincts : d'un 1.000.000 rond (Claude Opus 5, Grok 4.20, DeepSeek V4 Flash) jusqu'à 1.131.072 (Qwen 3.8 Max). C'est un écart de 13 % avant d'avoir mesuré quoi que ce soit. Sur le catalogue complet de 119 modèles de texte, la fenêtre la plus courante est 256K (25 modèles), avec 22 à 1M.

Une précaution sur l'origine de ces chiffres. Les catalogues de passerelle et la documentation du fournisseur ne concordent pas toujours : le 2026-08-12, le catalogue d'ofox listait Grok 4.20 à 2.000.000 tandis que la propre documentation de xAI indique 1.000.000. La comparaison honnête utilise le chiffre du fournisseur, et vous vérifiez la page du fournisseur quand le chiffre compte. Une fiche est une assertion ; la doc du fournisseur est une assertion plus forte ; le prompt_tokens mesuré sur votre contenu est la seule qui réponde à votre question.

L'écart de 1,56x sur une entrée identique

La surprise la plus profonde, c'est que le tokenizer — pas le nombre de fenêtre — est le mécanisme porteur. ofox a envoyé un même document anglais de 2.638 caractères (un postmortem de service de 420 mots) à neuf modèles via un seul endpoint et a lu prompt_tokens sur chaque réponse :

• Grok 4.20 : 614 tokens (4,30 caractères/token)
• GPT-5.6 Sol : 626 (4,21)
• GLM-5.2 : 632 (4,17)
• DeepSeek V4 Flash : 634 (4,16)
• Gemini 3.1 Pro : 684 (3,86)
• Claude Opus 4.6 : 698 (3,78)
• Qwen 3.8 Max : 706 (3,74)
• Kimi K3 : 716 (3,68)
• Claude Opus 5 : 957 (2,76)

Un écart de 1,56x sur une entrée identique. Claude Opus 5 est la valeur atypique parce qu'Anthropic documente que Claude 4.7 et ultérieurs utilisent un tokenizer plus récent qui produit environ 30 % de tokens en plus pour le même texte.

Combinez les deux tableaux et la fenêtre annoncée cesse d'être le nombre utile. Les copies de ce même document de 420 mots qui tiennent réellement vont de 1.045 sur Claude Opus 5 à 1.677 sur GPT-5.6 Sol — un écart de 1,60x sur des modèles qui annoncent tous « environ 1M ».

Le ratio n'est pas constant selon les types de contenu. Sur un fichier TypeScript, l'écart était de 1,53x et GLM-5.2 était le plus économe plutôt que Grok. Sur de la prose chinoise, l'écart s'est élargi à 1,88x, et les deux modèles Claude se situaient près d'un token par caractère chinois contre 1,87 pour Grok. Traitez-les comme des échantillons, pas comme des règles : sur un second passage chinois plus riche en ponctuation, les deux mêmes modèles sont arrivés à 0,98 et 0,96 caractères/token, ce qui signifie que certains caractères coûtent plus d'un token. Si votre entrée est du code ou non anglaise, mesurez-la plutôt que de supposer.

Pourquoi les prix par token ne sont pas comparables entre fournisseurs

Parce qu'un token n'est pas une quantité fixe de texte, les prix par token ne sont pas directement comparables. Un fournisseur qui facture moins par token peut coûter plus cher au mot si son tokenizer est plus dense. Anthropic facture la fenêtre complète de 1M à des tarifs standard sans prime pour contexte long, donc une requête de 900K tokens coûte par token autant qu'une de 9K. Gemini 3.1 Pro passe de 2 $ à 4 $ par million de tokens d'entrée au-delà de 200K, et Grok 4.20 de 1,25 $ à 2,50 $ au même seuil. Le modèle au tarif de titre le moins cher peut être le plus cher pour un travail sur documents longs, et la différence de tokenizer s'ajoute au palier où vous atterrissez.

Une comparaison de budget qui lit le prix affiché et la fenêtre annoncée lit deux assertions. Une comparaison qui mesure prompt_tokens sur le document réel et multiplie par le tarif de palier applicable lit une mesure. La première est une supposition ; la seconde est un nombre contre lequel vous pouvez facturer.

La fenêtre n'est pas le contexte utilisable

La précaution la plus importante, c'est qu'un modèle qui accepte 1M tokens n'est pas la même chose qu'un modèle qui retrouve de façon fiable le fait que vous avez enterré au token 800.000. La précision de récupération se dégrade avec la distance pour tout modèle public, et l'ampleur de cet écart est une question de benchmark, pas de fiche. ofox pointe vers RULER, MRCR v2 et NoLiMa comme les benchmarks qui le mesurent réellement : RULER sonde la récupération à des profondeurs contrôlées dans des contextes synthétiques, MRCR v2 suit la récupération multi-sauts dans les documents longs, et NoLiMa teste si un modèle trouve encore une réponse quand le recouvrement lexical entre question et preuve est retiré. Aucun de ces scores n'apparaît sur une fiche à côté de « contexte 1M ».

Traitez la fenêtre annoncée comme un plafond sur ce que l'API acceptera, et les chiffres de benchmark comme le guide de ce que le modèle utilisera bien. Le premier nombre est un contrat ; le second est une mesure. Un modèle qui accepte un million de tokens mais récupère à 60 % de précision à la profondeur 500K a un contexte utilisable bien en dessous de ce qui est annoncé, et aucune fenêtre ne comble l'écart — seul un mécanisme différent (routage, récupération ou restructuration) le fait.

Le mécanisme, c'est la mesure, pas la fiche

[ORIGINAL DATA] Chez Everythink, nous traitons la fenêtre de contexte comme toute propriété affirmée : selon Theorem 3, une propriété est garantie exactement quand son mécanisme est implémenté et mesure. La ligne « 1M tokens » n'a pas de mécanisme derrière elle ; prompt_tokens sur votre propre contenu est le mécanisme. Nous mesurons avant de nous engager avec un fournisseur, et nous remesurons quand un fournisseur publie un nouveau tokenizer, parce que le chiffre de titre a dévié jusqu'à 1,6x dans un sens comme dans l'autre.

C'est la discipline de la remesure. Un tokenizer n'est pas une propriété stable de la physique ; c'est un artefact logiciel qu'un fournisseur peut remplacer par un plus récent qui produit 30 % de tokens en plus pour le même texte, comme Anthropic l'a fait avec Claude 4.7. Quand cela arrive, chaque estimation de capacité que vous aviez mise en cache de l'ancien tokenizer est fausse des mêmes 30 %, et pareil pour chaque estimation de coût bâtie dessus. Les équipes qui se font piéger sont celles qui ont mesuré une fois, écrit le nombre dans un fichier de configuration et ne sont jamais revenues. Celles qui restent honnêtes remesurent selon un calendrier, comme vous recalibreriez tout instrument.

Ce n'est pas une discipline nouvelle pour nous. Le HAI Engine est en production depuis 2016, et chaque prévision se ramifie vers plusieurs Sisters — chacune un agent d'IA typé avec sa propre personnalité et sa propre décision de budget de contexte — avant que l'Oracle ne fusionne leurs brouillons en un ensemble calibré. Une prévision n'est pas un prompt géant ; c'est un ensemble routé de prompts bornés, et la borne est une mesure, pas une ligne de fiche.

[PERSONAL EXPERIENCE] Cela fait une décennie que nous mesurons les budgets de contexte d'agents, et l'erreur la plus fiable que nous voyons est celle d'équipes qui choisissent un modèle sur la fenêtre annoncée puis découvrent, en production, que leur charge réelle tient 35 % de documents en moins que ce que la fiche impliquait. La correction n'est jamais une plus grande fenêtre. La correction, c'est mesurer votre propre contenu sur les modèles entre lesquels vous choisissez — une requête avec max_tokens: 1 renvoie prompt_tokens et coûte une fraction de centime — et router en conséquence.

Le routage précède la récupération

C'est le même principe que « the space is the router » : chez Everythink, la topologie network→community→room route une requête avant que quoi que ce soit réponde. Vous ne déversez pas le monde entier dans une fenêtre en espérant que le modèle trouve le bon fait au token 800.000 ; vous routez vers la room qui détient le contexte pertinent, de sorte que la fenêtre que le modèle voit réellement est petite, fraîche et mesurée. La capacité est un problème de routage avant d'être un problème de récupération, et la récupération est un problème de mesure avant d'être un problème de fiche.

The 21 papers codifient cela. Theorem 3 ne dit pas « plus grand, c'est mieux » ; il dit qu'une propriété tient exactement quand le mécanisme qui la garantit est en place et mesure. Pour la capacité, ce mécanisme est un tokenizer lisant votre contenu et un benchmark lisant la récupération du modèle en profondeur. Le nombre annoncé n'est ni l'un ni l'autre.

La souveraineté du client fonctionne sur la mesure

La souveraineté du client — votre réseau, votre marque, vos données — a une dépendance silencieuse à la mesure de capacité. Quand vous possédez la topologie network→community→room, vous décidez quel contexte atteint quel agent, et cette décision n'est bonne que comme votre estimation de ce qui tient. Un opérateur souverain qui se fie à la fiche remet la vraie décision au copy marketing du fournisseur. Un opérateur souverain qui mesure son propre corpus garde la décision de routage en interne, là où elle appartient. Il en va de même pour l'inclusion par conception : un utilisateur à connectivité réduite sur un forfait data mesuré est mieux servi par une fenêtre petite et bien routée, pas par un tuyau d'un million de tokens, et « petite et bien routée » est une mesure que vous ne pouvez faire que si vous avez mesuré.

Faire tenir plus dans la fenêtre que vous avez

Aucun de ces leviers n'agrandit la fenêtre ; tous réduisent ce que vous y dépensez. En ordre approximatif de rendement :

1. Cache de prompts. Un préfixe stable — prompt système, définitions d'outils, un document sur lequel vous continuez de questionner — est facturé à environ 10 % du tarif d'entrée sur un hit de cache chez Anthropic et plusieurs autres fournisseurs, quoique la remise exacte varie et soit plus profonde chez certains. C'est le plus gros levier pour les appels répétés, et il change le coût, pas la capacité.
2. Compaction. Résumé côté serveur des tours précédents quand la conversation approche de la limite, pour qu'une longue session d'agent continue au lieu d'échouer.
3. Édition de contexte. Nettoyer les résultats d'outils périmés et les anciens blocs de raisonnement du relevé. Les boucles d'agent se remplissent de sortie d'outils plus que de conversation.
4. Choisir le bon tokenizer pour votre contenu. Comme les mesures ci-dessus le montrent, cette seule décision vaut jusqu'à 1,6x de capacité effective avant d'optimiser quoi que ce soit d'autre.

Les trois premiers gèrent le budget. Le quatrième choisit contre quel budget vous mesurez. Les quatre sont des mécanismes ; aucun n'est un plus grand nombre sur une fiche.

Que se passe-t-il quand vous dépassez la fenêtre

Vous recevez un HTTP 400 et aucune sortie. Rien n'est silencieusement tronqué. ofox a envoyé une requête surdimensionnée à un modèle de 32.000 tokens et a reçu :

{"error":{"code":null,
  "message":"<400> InternalError.Algo.InvalidParameter: Range of input length should be [1, 30720]",
  "type":"invalid_request_error"}}

Lisez cette limite avec soin : le modèle annonce 32.000, et le plafond d'entrée imposé est 30.720, le reste étant réservé à la sortie. La fenêtre annoncée est le total, pas votre allocation d'entrée, et le nombre imposé peut être inférieur à celui du marketing.

Les formes d'erreur diffèrent selon le fournisseur, alors ne faites pas de pattern-matching sur la chaîne de message. Les endpoints compatibles OpenAI renvoient généralement un 400 avec un code de style context_length_exceeded. Claude peut au contraire terminer le tour avec stop_reason: "model_context_window_exceeded", distinct de max_tokens et qui nécessite sa propre branche dans votre code. Gérez les deux. Une réponse qui s'est arrêtée tôt parce que la fenêtre s'est remplie n'est pas le même échec qu'une qui s'est arrêtée parce que votre max_tokens était petit, et les corrections diffèrent.

Points clés à retenir

• La fenêtre annoncée est un plafond sur ce que l'API accepte, pas sur ce que le modèle utilise bien. La capacité réelle est une mesure, et la mesure, c'est le tokenizer plus la courbe de précision de récupération.
• « 1M tokens », ce sont neuf nombres différents, et le même document de 420 mots tient 1,6x plus de copies sur un modèle phare que sur un autre. Les prix par token ne sont pas comparables entre fournisseurs sans ajuster la densité du tokenizer.
• Mesurez votre propre contenu. Une requête avec max_tokens: 1 renvoie prompt_tokens et coûte une fraction de centime. Lancez-la sur votre charge réelle avant de choisir un modèle sur la taille de fenêtre, et relancez-la quand un fournisseur publie un nouveau tokenizer.
• Le mécanisme, c'est la mesure, pas la fiche. Selon Theorem 3, une propriété est garantie exactement quand son mécanisme est implémenté et mesure. La ligne « 1M » n'a pas de mécanisme ; prompt_tokens est le mécanisme.
• Le routage précède la récupération. Ne déversez pas le monde dans une fenêtre. Routez d'abord vers le contexte pertinent — la topologie network→community→room chez Everythink est le même principe au niveau produit — pour que la fenêtre que le modèle voit soit petite, fraîche et mesurée.

Questions fréquentes

Une fenêtre de contexte, est-ce la même chose que la mémoire ? Non. Une fenêtre de contexte est par requête, pas persistante. L'API est sans état : à chaque tour vous renvoyez toute la conversation, et la fenêtre est le plafond de ce qu'une requête peut contenir. Tout ce qui est en dehors disparaît, sauf si votre application le stocke et le renvoie. Les produits qui semblent se souvenir de vous d'une session à l'autre réinjectent du texte sauvegardé dans la fenêtre, ils ne puisent pas dans la mémoire du modèle.

Combien de mots font 1 million de tokens ? Pour de la prose anglaise, à peu près 440.000 à 685.000 mots — une gamme plus large que ne l'admet la règle de pouce habituelle. D'après la mesure d'ofox sur un même document, huit des neuf modèles se situent entre 587.000 et 684.000 mots par million de tokens ; Claude Opus 5 est la valeur basse atypique, environ 439.000, à cause de son tokenizer plus récent. Le code est plus dense (environ 2,4 à 3,6 caractères/token) et le chinois encore plus (0,9 à 1,9), donc la même fenêtre de 1M en contient bien moins.

Quelle est la plus grande fenêtre de contexte disponible en 2026 ? 1M tokens est le sommet de la catégorie grand public. Plusieurs fournisseurs se situent légèrement au-dessus du chiffre rond : Qwen 3.8 Max à 1.131.072, GPT-5.6 à 1.050.000, et Gemini, GLM et Kimi K3 à 1.048.576. Parmi les 119 modèles de texte du catalogue ofox au 2026-08-12, la fenêtre la plus courante est 256K (25 modèles), avec 22 à 1M.

Pourquoi le même fichier utilise-t-il plus de tokens sur Claude que sur GPT ? Des tokenizers différents. Anthropic note que Claude 4.7 et ultérieurs utilisent un tokenizer plus récent qui produit environ 30 % de tokens en plus pour le même texte que les Claude précédents. Sur le document de test anglais d'ofox, Claude Opus 5 a utilisé 957 tokens là où GPT-5.6 Sol en a utilisé 626, un écart de 1,53x sur une entrée identique. Rien ne va mal ; les modèles comptent simplement différemment, et les prix par token ne sont pas comparables entre fournisseurs sans ajuster pour cela.

Puis-je augmenter la fenêtre de contexte d'un modèle ? Non. Elle est fixée par le modèle et il n'y a pas de paramètre pour l'élever. Ce que vous pouvez changer, c'est combien vous en dépensez : le cache de prompts réduit le coût du renvoi d'un préfixe stable, l'édition de contexte nettoie les résultats d'outils périmés, et compaction résume les tours plus anciens. Ceux-ci gèrent le budget au lieu de l'étendre.

Si vous voulez arrêter de deviner la capacité et commencer à la mesurer, créez votre réseau — la topologie qui route avant que quoi que ce soit réponde, pour que la fenêtre que vos agents voient réellement soit celle que vous avez mesurée.

Sources

• 2026 — ofox.ai, « What Is a Context Window? Token Limits by Model (2026) » — https://ofox.ai/blog/what-is-a-context-window-token-limits-by-model-2026/
• 2026 — Anthropic, « Context windows » — https://platform.claude.com/docs/en/build-with-claude/context-windows
• 2026 — Anthropic, « Pricing, including the tokenizer note » — https://platform.claude.com/docs/en/about-claude/pricing