Comparaison fenêtre contextuelle LLM 2026 : tokens d'entrée et de sortie max pour chaque modèle majeur

Les éditeurs citent deux chiffres de contexte distincts. La fenêtre d'entrée est le total de tokens que le modèle accepte dans une seule requête, incluant le prompt système, l'historique de conversation, les définitions d'outils et le message utilisateur courant. Le cap de sortie est le nombre maximum de tokens que le modèle est disposé à retourner en une seule réponse — une limite distincte et généralement plus petite fixée par l'éditeur.

Confondre les deux est la plus grande surprise de coût que nous voyons. Claude Sonnet 4.6 a une fenêtre d'entrée de 500k mais plafonne la sortie à 64k ; si vous lui demandez de traduire un document de 200k tokens dans une autre langue, vous ne pouvez pas obtenir la traduction complète en une seule réponse — la sortie s'arrête à 64k. Vous devez diviser la requête.

Les modèles de raisonnement compliquent davantage le côté sortie. O4-reasoning d'OpenAI partage son budget de sortie de 100k entre les tokens de raisonnement cachés et la sortie visible ; un modèle qui réfléchit pendant 80k tokens n'a que 20k restants pour la réponse visible. Planifiez les budgets de sortie en conséquence. Pour la stratégie de fenêtre d'entrée spécifiquement, notre générateur de prompt de code aide à structurer les longs prompts techniques qui s'adaptent proprement aux fenêtres plus serrées.

La conversion tokens-à-mots utilise la règle empirique 1 token ≈ 0,75 mots en anglais. Le ratio réel varie — le code et le texte non-anglais sont plus bas, les données structurées plus hautes — mais pour la planification la règle fonctionne.

200k tokens ≈ 150 000 mots ≈ 500 pages de prose dense. Exemples : le texte intégral de Guerre et Paix (1 200 pages) ne rentre pas, mais la plupart des livres techniques complets (300-450 pages) le font. Un manuel d'entreprise technologique moyen plus ses politiques référencées rentre confortablement.

1 000 000 de tokens ≈ 750 000 mots ≈ 2 500 pages de prose dense. Exemples : la série Harry Potter complète (~1,1M mots sur 7 livres) rentre avec une marge de manœuvre. Un 10-K financier de 200 pages plus 50 transcriptions de soutien. Un codebase de taille moyenne de 50-80k lignes de code.

2 000 000 de tokens ≈ 1 500 000 mots ≈ 5 000 pages. Exemples : 4-5 romans complets à la fois, les œuvres complètes de Shakespeare avec annotations, ou un codebase de 300 fichiers avec 200k LOC. À cette taille, la génération augmentée par récupération (RAG) surpasse presque toujours l'insertion de tout dans le contexte — moins cher, plus rapide et généralement plus précis selon les benchmarks publiés.

10 000 000 de tokens (Llama 4 Scout) : environ 7,5M mots, ou 25 000 pages. Les benchmarks de rappel au-delà de 500k sont mitigés ; traitez le chiffre principal comme « nous acceptons cette quantité d'entrée » plutôt que « nous raisonnerons de manière fiable sur cette quantité d'entrée ».

Le benchmark aiguille dans une botte de foin place un seul fait spécifique à des positions aléatoires dans un long document et teste si le modèle peut le récupérer. La plupart des modèles obtiennent près de 100 % sur les entrées plus courtes et se dégradent à mesure que l'entrée augmente — généralement s'effondrant entre 50k et 200k tokens de contenu dense.

Selon les benchmarks publiés 2026 : Gemini 3.1 Pro Preview maintient une récupération à 95%+ jusqu'à environ 600k tokens avant de se dégrader. Claude Opus 4.8 reste au-dessus de 90 % jusqu'à ~300k. gpt-5.5 reste au-dessus de 90 % jusqu'à ~200k. Llama 4 Scout, malgré son titre de 10M tokens, montre des résultats mitigés au-delà de 500k.

La conclusion pratique : concevez votre prompt autour du rappel effectif, pas de la fenêtre annoncée. Si la plage fiable du modèle est de 300k tokens mais que vous avez besoin d'interroger 500k, divisez le document, notez les chunks pour la pertinence et transmettez seulement les correspondances top-k en contexte. C'est RAG, et cela surpasse presque toujours l'insertion de contexte brut au-delà d'une certaine taille de document.

Pour RAG spécifiquement, le coût d'embedding domine la facture de construction d'index — voir notre calculateur de coût d'embedding pour les prix actuels d'embedding par modèle.

Disons que vous devez examiner un document de 250 000 tokens — un ensemble de contrats de 600 pages avec annexes. Quelle fenêtre rentre ?

Éligible par fenêtre brute : tous les modèles du tableau sauf OpenAI o4-reasoning (200k) et Claude Haiku 4.5 (200k). Éligible par rappel effectif (en supposant un contenu dense) : gpt-5.5-pro, Claude Opus 4.8, Claude Sonnet 4.6, Claude Fable 5, Gemini 3.x, Gemini 2.5 Pro, Qwen 3 Max.

Comparaison des coûts pour un examen unique avec un budget d'entrée de 250k et de sortie de 2k. gpt-5.5 : 1,31 $ (1,25 $ entrée + 0,06 $ sortie). Claude Sonnet 4.6 : 0,78 $ (0,75 $ + 0,03 $). Gemini 2.5 Pro : 0,33 $ (0,3125 $ + 0,02 $). Claude Opus 4.8 : 1,30 $ (1,25 $ + 0,05 $). Gemini 3.1 Pro Preview : 0,52 $.

Même contenu, 0,33 $ à 1,31 $ par examen selon le choix du modèle. Si vous exécutez 1 000 examens par mois, la différence s'accumule à 330 $ vs 1 310 $ par mois — un delta mensuel de 980 $ pour la même charge de travail. Faites correspondre le modèle à la profondeur de rappel requise, puis choisissez l'option la moins chère qui atteint la barre de rappel. Pour les stratégies de qualité de prompt qui survivent à un niveau moins coûteux, notre générateur de description meta aide à compresser les requêtes de récupération.

Vous devez générer un document de 50 000 tokens — un rapport long format, un roman traduit, un codebase généré. Quels modèles peuvent retourner cela en une seule réponse ?

Les modèles qui peuvent retourner 50k tokens en un seul appel : Claude Opus 4.8 (cap de sortie de 64k), Claude Sonnet 4.6 (64k), Claude Fable 5 (128k), famille Gemini 2.5/3.x (65k), OpenAI o4-reasoning (100k partagé avec le raisonnement, donc ~30-50k visible après le raisonnement). Les autres plafonnent à 8-32k de sortie.

Si votre modèle plafonne en dessous de 50k, vous devez diviser : générez les premiers 16k, demandez au modèle de continuer à partir d'où il s'est arrêté, répétez. La division introduit un risque de continuité — le deuxième chunk peut répéter du contenu, perdre le fil ou changer de ton. La génération en un seul appel dans un modèle avec un cap de sortie plus élevé est presque toujours plus propre.

Note de coût : à 50k de sortie, Claude Sonnet 4.6 facture 0,75 $ par génération (0,003 $ d'entrée sur un petit prompt + 0,75 $ de sortie). À 50k de sortie sur gpt-5.5, vous devriez diviser trois fois, payant l'entrée deux fois supplémentaires ; la facture réelle se situe autour de 1,00 $-1,20 $ selon la relecture de contexte.

La règle empirique pour 2026 : sous 100k tokens de contenu pertinent, l'insertion de contexte est généralement plus simple et donne de meilleures réponses. Entre 100k et 500k, cela dépend de la densité de requête — une seule question ciblée est mieux servie par RAG, tandis qu'une analyse multi-facettes bénéficie d'un contexte complet. Au-delà de 500k, RAG gagne presque toujours sur le coût, la latence et la précision.

Mathématiques des coûts : un seul appel Gemini 2.5 Pro avec 1M tokens d'entrée coûte 1,25 $ en entrée. Interroger le même document 10 fois dans une session coûte 12,50 $. Construire un index d'embedding des mêmes 1M tokens avec text-embedding-3-small (0,02 $/1M) coûte 0,02 $ une seule fois, puis les requêtes extraient seulement les chunks top-k (généralement 5-20k tokens) à 0,0063 $-0,025 $ par requête — une réduction de coût de 100-1 000x à l'échelle de la session.

Mathématiques de la latence : les appels long-contexte prennent des secondes au premier token (souvent 5-20s sur 1M-token d'entrée). Les requêtes RAG avec une récupération de 10k tokens retournent généralement le premier token en moins de 1s. La différence UX cumulative à l'échelle est grande.

Quand dévier de la règle : documents avec des références croisées que aucune récupération au niveau chunk ne surfacera — les longs contrats juridiques où les clauses se référencent mutuellement sur le document, les analyses financières multi-documents où vous avez besoin de corrélations sur toutes les sources, les révisions de code sur des systèmes étroitement couplés. Là, le contexte complet vous achète quelque chose que RAG ne peut pas faire.

La plupart des fournisseurs facturent un taux fixe par token indépendamment de la taille de la fenêtre, mais certains appliquent une surcharge au-dessus d'un seuil. En juin 2026, OpenAI facture son taux standard jusqu'à la fenêtre complète sur la plupart des modèles. Anthropic facture le même taux sur la fenêtre complète de 500k sur Sonnet 4.6 et Opus 4.8. Google facture le même taux jusqu'à 200k sur Gemini 2.5 Pro et Gemini 3.1 Pro Preview, avec une modeste surcharge au-dessus de ce seuil (confirmez sur tarification Gemini).

Le plus gros facteur de coût est simplement que les appels long-contexte traitent plus de tokens. Un appel Gemini 2.5 Pro de 1M tokens coûte 1,25 $ juste pour l'entrée, indépendamment du nombre de tokens que le modèle utilise réellement. Si vous remplissez la fenêtre à chaque appel, votre facture d'entrée augmente linéairement avec la taille de la fenêtre — à 100k appels par mois, 125 000 $.

La mise en cache des prompts change cela dramatiquement. Anthropic et OpenAI offrent tous deux des réductions de cache qui facturent la partie en cache à 10 % du taux standard. Pour les requêtes répétées contre le même grand document — une base de connaissances, un contrat, un codebase — la mise en cache transforme un appel de 1,25 $ en 0,125 $. Voir tarification Anthropic Claude et tarification OpenAI API pour les mécaniques de cache en détail.

Chaque estimation du tableau ci-dessus suppose de la prose anglaise à environ 0,75 mots par token. Ce ratio est pratique pour les calculs rapides, mais c'est un chiffre unique sur une distribution qui s'étend à peu près 3x selon la langue, l'ensemble de caractères et le type de contenu. Si vous budgétisez une fenêtre de 200k ou 1M tokens pour une charge de travail multilingue, la planification au taux anglais sous-estimera régulièrement le compte de tokens réel de 50-200 %. La même fenêtre qui contient 150 000 mots anglais contient seulement 60-80 000 caractères chinois, 40-50 000 lignes de JSON joliment formaté, et quelque part entre 8 000 et 12 000 lignes de Python selon le style.

Commencez par les tokenisateurs eux-mêmes. La famille GPT d'OpenAI utilise cl100k_base pour GPT-4 et GPT-5.x, un encodage pair-par-octet (BPE) entraîné principalement sur du texte web anglais avec environ 100 277 tokens dans le vocabulaire. Claude d'Anthropic utilise son propre tokenisateur BPE avec des fusions comparables mais non identiques — les comptages de tokens entre OpenAI et Claude pour le même passage anglais diffèrent généralement de 1-4 % dans chaque direction. La famille Gemini de Google utilise SentencePiece avec un vocabulaire d'environ 256k tokens, qui compresse les scripts non-latins plus agressivement que cl100k_base. Llama 4 utilise une variante SentencePiece de 128k. La taille du vocabulaire et la distribution d'entraînement déterminent l'efficacité avec laquelle une langue donnée se compresse, et l'écart entre modèles sur le même texte non-anglais peut atteindre 30-40 %.

L'anglais se compresse bien parce que les tokenisateurs BPE voient un texte d'entraînement anglais énorme et fusionnent les sous-chaînes fréquentes ('ing', 'tion', 'the ') en jetons uniques. Le taux anglais empirique est de 0,73-0,78 mots par token sur les tokenisateurs frontier modernes, ou environ 4 caractères par token. Les langues romanes (espagnol, français, italien, portugais) sont légèrement pires — 0,65-0,72 mots par token — parce que l'entraînement BPE penche vers l'anglais. L'allemand court 0,55-0,65 à cause des longs noms composés qui se fragmentent souvent en 2-4 tokens. Le russe et les autres langues en script cyrillique s'exécutent généralement à 0,4-0,55 mots par token. L'arabe, avec des mots morphologiquement riches et un script droite-à-gauche, court souvent à 0,35-0,5.

Les scripts logographiques et syllabiques sont le cas pénalisant. Sur cl100k_base, un caractère chinois typique coûte 1,5-2,5 tokens — ce qui signifie que 100k tokens de chinois contiennent seulement 40 000-65 000 caractères, ou à peu près la longueur d'un seul roman de 200 pages plutôt que l'ensemble de 500 pages que la même fenêtre contient en anglais. Le japonais est légèrement pire que le chinois parce que les kanji, hiragana et katakana tokenisent différemment. Le Hangul coréen court 1,2-1,8 tokens par bloc de syllabe sur cl100k_base. Les tokenisateurs SentencePiece (Gemini, Llama 4) réduisent cela d'environ moitié — Gemini traite un caractère chinois plus près de 0,8-1,2 tokens — ce qui est une vraie raison pour laquelle les équipes exécutant des charges de travail CJK gravitent vers Gemini ou des modèles avec des tokenisateurs similaires.

Le type de contenu compte autant que la langue. Le code est dense en caractères mais pauvre en tokens par rapport au nombre de caractères (approximativement 1 token par 3,5-4,5 caractères), mais lourd en tokens par rapport au nombre de lignes parce que les identifiants, la ponctuation et l'espacement blanc consomment tous des tokens. Une règle pratique : une fenêtre de 200k tokens contient 1 600-2 400 lignes de Python densément commenté, 1 200-1 800 lignes de Java ou C#, 800-1 400 lignes de TypeScript avec JSX, ou 6 000-10 000 lignes de JavaScript minifié. JSON et XML poussent dans l'autre direction — ils sont coûteux en tokens parce que chaque guillemet, accolade et balise est son propre token ou deux. Une fenêtre de 200k tokens contient environ 40-55k lignes de JSON formaté ou 25-35k lignes de XML. Markdown s'assied entre la prose et le code ; la notation mathématique en LaTeX est parmi les pires, s'exécutant à 0,3-0,5 « concepts » par token parce que chaque commande backslash, paire d'accolades et indice fragment fortement.

Exemple travaillé. Une fenêtre contextuelle de 200k tokens contient approximativement : 150 000 mots anglais (environ 500 pages), 100 000-120 000 mots espagnols, 65 000-80 000 caractères chinois sous cl100k_base, 110 000-130 000 caractères chinois sous le tokenisateur Gemini, 8 000-12 000 lignes de Python, 4 000-6 000 lignes de XML, ou 45 000-55 000 lignes de JSON compact. Une fenêtre Gemini 2.5 Pro de 1M tokens contient environ 750 000 mots anglais mais seulement 550 000-650 000 caractères chinois — toujours bien plus que ce que cl100k_base rendrait possible, mais bien court de l'extrapolation naïve anglaise. La règle actuelle pour les charges de travail multilingues est de budgétiser à 1,5-2x le taux de tokens anglais pour les scripts non-latins sur OpenAI et Claude, et à peu près 1,2-1,5x sur Gemini et Llama 4.

Le conseil pratique : ne vous engagez jamais sur une taille de fenêtre basée uniquement sur les comptages de caractères ou les comptages de mots. Exécutez votre contenu réel via le tokenisateur du modèle — bibliothèque tiktoken d'OpenAI pour GPT, point de terminaison count_tokens d'Anthropic pour Claude, API count_tokens de Google pour Gemini — sur un échantillon représentatif de 5-10 documents réels, puis planifiez avec un tampon de sécurité de 20-30 % sur le taux mesuré. Le coût de mal estimer est concret : un flux de travail conçu pour 150k mots anglais qui tourne réellement sur du chinois frappera le cap de fenêtre de 200k au document 1, échouera silencieusement ou tronquera, et livrera des réponses cassées aux utilisateurs. Mesurez d'abord, puis choisissez la fenêtre.

Commencez par le plus grand élément de contenu unique que votre charge de travail traite — un document, un historique de conversation, un morceau de codebase. Ajoutez le prompt système, les définitions d'outils, la mémoire de conversation et un tampon de sécurité de 20 %. C'est votre fenêtre minimale requise.

Si la réponse est inférieure à 50k, presque tous les modèles fonctionnent. Si 50k-200k, éliminez Haiku 4.5 et o4-reasoning ; tout le reste se qualifie. Si 200k-500k, éliminez Mistral Large 3, DeepSeek V4 et Grok 4. Si 500k+, seules la famille Gemini, Claude Fable 5, gpt-5.5-pro (1M) et Llama 4 (1M-10M) s'en tirent.

Ensuite, testez le rappel effectif. Placez un fait connu aux positions 50 %, 75 % et 90 % de votre entrée max typique, demandez au modèle de le récupérer et vérifiez. Si le rappel tombe en dessous de 85 % au-delà de votre fenêtre opérationnelle, passez plutôt à RAG au lieu de pousser le modèle à sa limite annoncée.

Pour la plupart des équipes, le bon mouvement est : choisissez un modèle dont le rappel effectif couvre 80 % des tailles de document attendues, utilisez RAG pour la longue queue. Voir notre calculateur de coût GPT vs Claude vs Gemini pour une ventilation de coût côte à côte à chaque taille de fenêtre.