La fenêtre de 1 million de tokens

Un million de tokens de contexte, c’est environ 555 000 mots, soit à peu près 2,5 millions de caractères avec le découpage en tokens actuel : une base de code complète, un corpus documentaire entier ou des mois d’historique de conversation, en une seule requête. La génération 5 n’a pas inventé cette fenêtre, mais elle l’a rendue universelle : en 2026, elle est passée d’une option en bêta à la norme de toute la gamme.

Comment la fenêtre d’un million s’est généralisée

Aujourd’hui, les quatre modèles actuels (Fable 5.1, Opus 5.5, Sonnet 5.5 et Haiku 5.5) offrent tous un million de tokens, par défaut et sans en-tête bêta. Seuls des modèles plus anciens, comme Haiku 4.5 ou Sonnet 4.5, restent à 200 000. Une nuance pour Haiku 5.5 : au-delà de 100 000 tokens de prompt, son tarif augmente. Charger un contexte massif dans le modèle choisi pour son faible coût reste donc une décision à chiffrer.

La sortie suit : 128 000 tokens par réponse sur tous les modèles actuels, contre 64 000 sur Haiku 4.5 et Sonnet 4.5. C’est de quoi produire un rapport complet ou un fichier de code entier d’un seul tenant, sans enchaîner plusieurs requêtes et recoller les morceaux. Une même requête accepte aussi jusqu’à 600 images ou pages de PDF, et, depuis le 28 octobre 2026, jusqu’à 128 Mo sur l’API Claude.

Quand la fenêtre déborde

Deux cas sont à distinguer. Si l’entrée seule dépasse la fenêtre, l’API refuse la requête avec une erreur 400 (« prompt is too long »). Si l’entrée tient mais que la génération atteint la limite, la réponse s’arrête avec stop_reason: "model_context_window_exceeded" : votre code doit traiter cette valeur comme une réponse incomplète.

Aller au-delà de 128 000 tokens en sortie

Pour les traitements massifs, il existe une marche supplémentaire. Sur l’API Message Batches, Claude Opus 5.5, Opus 5, Sonnet 5.5, Sonnet 5, Haiku 5.5, Opus 4.8, Opus 4.7, Opus 4.6 et Sonnet 4.6 acceptent jusqu’à 300 000 tokens de sortie, avec l’en-tête bêta suivant :

output-300k-2026-03-24

Notez la restriction : cela passe par l’API Batches, donc par un traitement asynchrone. Ce n’est pas un levier pour vos requêtes interactives, mais une piste précieuse pour les chantiers de fond (génération de documentation, traduction de corpus, réécriture de catalogues), où l’on soumet un lot le soir pour récupérer les résultats sans contrainte de latence.

Un grand contexte ne dispense pas de sélectionner

C’est l’erreur la plus fréquente depuis l’arrivée des grandes fenêtres : puisque tout tient, pourquoi continuer à sélectionner l’information ? Parce que charger un million de tokens à chaque requête se paie trois fois. En argent d’abord : vous payez tous les tokens d’entrée à chaque appel, et un contexte dix fois plus gros coûte dix fois plus cher. En latence ensuite : un contexte plus long retarde la réponse, sans qu’aucune erreur n’apparaisse. En qualité enfin, et c’est le plus contre-intuitif : la documentation prévient qu’à mesure que le nombre de tokens grandit, la précision et la capacité à retrouver une information baissent, un phénomène qu’elle appelle context rot. Un contexte court et pertinent bat souvent un contexte massif et bruité.

Alors à quoi sert la grande fenêtre ? À ne plus découper artificiellement un document qui forme un tout : un contrat, une base de code dont les fichiers se référencent, un dossier dont les pièces s’éclairent l’une l’autre. Elle sert aussi à garder un historique long sans compaction agressive, quand la perte de détails anciens dégraderait la suite. La distinction à retenir : la grande fenêtre supprime les découpages subis, elle ne rend pas obsolètes les découpages choisis.

C’est là que la mise en cache des prompts devient décisive. Si votre contexte long est stable d’une requête à l’autre (la même base documentaire interrogée en boucle, le même code analysé sous plusieurs angles), le cache évite d’en repayer la totalité : une lecture en cache coûte au plus un dixième du tarif d’entrée, et moins encore sur Opus 5.5, Sonnet 5.5 (un vingtième) et Fable 5.1 (un quarantième). L’association contexte long et cache est ce qui rend viable ce qui, sans cache, ferait exploser la facture.

À vous de jouer

Chiffrer avant de charger. Prenez le plus gros document que votre application envoie à Claude et comptez-le avec le point d’accès de comptage. Calculez le coût d’entrée de dix requêtes qui l’envoient en entier, sans cache puis avec cache, aux tarifs du modèle que vous utilisez. Décidez ensuite ce qui doit rester dans la requête, et ce qu’un outil de recherche pourrait aller chercher à la demande.

Sources officielles : Context windows (documentation Claude : tailles, débordement, context rot) · Models overview · Batch processing · Prompt caching · Release notes (dates)

Points clés à retenir

• Un million de tokens, environ 555 000 mots : une bêta en 2025, la norme de toute la gamme actuelle en 2026, Haiku 5.5 compris
• 128 000 tokens en sortie, jusqu’à 300 000 par l’API Batches avec l’en-tête output-300k-2026-03-24
• Entrée trop longue : erreur 400 ; génération qui atteint la limite : model_context_window_exceeded
• Un grand contexte ne remplace pas une bonne sélection : le context rot dégrade la qualité
• Associez contexte long et cache des prompts pour maîtriser le coût