Quel rapport entre la context window et ma facture de tokens ?
La context window est le principal facteur de ce que vous payez, parce que votre agent de codage IA en renvoie la quasi-totalité à chaque tour et vous la facture à chaque fois. Les gens supposent que le coût vient du modèle qui « réfléchit » ou de la longueur de ses réponses. Ce n'est pas le cas. La partie chère, c'est l'input — la pile de code, d'historique, de définitions d'outils et de sorties de commandes que le modèle doit relire avant de pouvoir vous écrire la moindre ligne en retour. J'ai un doctorat en IA et je construis des outils de réduction de tokens pour gagner ma vie, donc je regarde beaucoup de logs de session. Le motif est toujours le même : l'output est une erreur d'arrondi, et l'input représente toute la facture. Un agent qui vous écrit un patch propre de 40 lignes a peut-être lu 80 000 tokens de contexte pour y arriver — et s'il lui a fallu six tours, il a relu la plupart de ces 80 000 tokens six fois. Voilà le mécanisme. Tout le reste de cet article n'est qu'une conséquence de cela. La fenêtre est aussi un plafond strict, pas seulement un compteur. Quand elle se remplit, l'agent commence à abandonner ou à résumer les tours précédents, et c'est de là que viennent les moments « attends, pourquoi a-t-il oublié ce qu'on vient de faire ? ». La fenêtre contrôle donc deux choses à la fois : combien vous payez, et à quel point l'agent reste cohérent. Les deux se dégradent à mesure qu'elle se remplit.Pourquoi l'agent renvoie-t-il toute la fenêtre à chaque tour ?
Il renvoie la fenêtre parce que le modèle est sans état — il n'a aucune mémoire entre les appels API, donc le client doit réexpédier l'intégralité de la conversation à chaque tour. Il n'y a pas de session côté serveur qui conserve discrètement votre transcript. Chaque requête vers le modèle est indépendante, et pour poursuivre une conversation, l'agent reconstruit l'état complet et le renvoie. Pour un chat one-shot, c'est acceptable. Pour un agent, c'est brutal, parce qu'un agent tourne en boucle : lire un fichier, lancer un test, lire la sortie, éditer, relancer le test. Chacune de ces étapes est un nouvel appel API qui transporte le contexte accumulé jusque-là. Le transcript croît de façon monotone — le tour 1 transporte 5k tokens, le tour 10 peut en transporter 60k — et vous payez le prix d'input sur la charge complète à chaque fois. C'est exactement pour cela que l'agentic coding est tellement plus gourmand en tokens qu'une simple complétion. Le coût n'est pas linéaire par rapport à la quantité de travail demandée ; il est plus proche du quadratique par rapport à la durée de la session, parce que chaque nouveau tour repaie tous les tours précédents. Le modèle mental honnête est « input tokens × tours », et la fenêtre est le multiplicateur que vous pouvez réellement contrôler.Le prompt caching ne rend-il pas tout cela gratuit ?
Le prompt caching rend le contexte renvoyé bien moins cher, mais il ne le rend pas gratuit, et il ne vous sauve pas d'une fenêtre boursouflée. Sur les modèles d'Anthropic, un cache read coûte environ 10 % du prix d'input normal (Anthropic pricing, 2026). C'est une remise réelle et importante sur le préfixe stable de votre contexte — le system prompt, vos règles de projet, les fichiers qui n'ont pas changé. Utilisez-le. C'est l'un des meilleurs leviers dont vous disposez, et j'en parle dans prompt caching pour réduire le coût d'input. Mais le caching a des limites contre lesquelles une grosse fenêtre fonce tout droit. Un cache hit ne s'applique qu'à un préfixe identique octet pour octet à une requête précédente ; dès que quelque chose change près du haut du contexte, tout ce qui suit doit être relu au prix fort. Les agents réordonnent les résultats d'outils, injectent de nouvelles sorties de commandes et éditent des fichiers en cours de session — autant de choses qui peuvent invalider le préfixe mis en cache. Et les entrées de cache expirent (la fenêtre par défaut d'Anthropic est de quelques minutes), donc un humain lent dans la boucle perd entièrement la remise. Le caching réduit donc le prix unitaire de la relecture du contexte. Il ne fait rien contre le problème plus profond : le contexte n'aurait jamais dû être aussi gros au départ. Une context window de 80k tokens mise en cache est moins chère qu'une non mise en cache, mais elle reste plus chère — et moins précise — qu'une fenêtre bien dimensionnée de 15k tokens. Le caching est une remise sur le gaspillage, pas un substitut au fait de ne pas générer ce gaspillage.Qu'est-ce qui remplit réellement la fenêtre — et combien ça coûte ?
Quatre sources remplissent la fenêtre d'un agent, et elles ne contribuent pas de la même manière. Voici comment se décompose une charge typique en milieu de session, avec la partie qui compte le plus : est-elle renvoyée à chaque tour ?| Source | Part typique | Renvoyée à chaque tour ? |
|---|---|---|
| Historique de conversation | Croît sans limite | Oui |
| Contenu des fichiers lus par l'agent | Volumineux, en pics | Oui, jusqu'à élagage |
| Définitions d'outils / MCP | 5k–25k tokens | Oui |
| Sortie de commandes + de tests | En pics, souvent énorme | Oui |
npm install ou un seul test verbeux peut déverser des dizaines de milliers de tokens de barres de progression et de stack traces dans le transcript, et vous renvoyez désormais ce bruit à chaque tour suivant.
Mettons-y de vrais prix. Sur Claude Opus 4.8, l'input est à 5 $ par million de tokens ; sur Sonnet 5, c'est 2 $ ; l'input de GPT-5.5 est à 5 $ (Anthropic pricing ; OpenAI pricing, 2026). Une fenêtre de 60k tokens qui traverse 15 tours, c'est 900k input tokens — environ 2,70 $ sur Sonnet, 4,50 $ sur Opus, pour une seule fonctionnalité, dont la majeure partie dépensée à relire la même chose. Pour le détail complet de la répartition des dépenses d'un agent de codage, voyez les coûts en tokens des agents de codage IA et le prix des tokens d'API LLM.
Comment garder la fenêtre petite sans perdre de contexte ?
Vous la gardez petite en changeant ce qui entre dans la fenêtre dès le départ, et non en la nettoyant après coup. Il y a quatre leviers, à peu près par ordre de rentabilité :- Récupérer, ne pas tout déverser. Au lieu de laisser l'agent lire des fichiers entiers « par sécurité », donnez-lui une semantic code search pour qu'il extraie les trois fonctions qui comptent et laisse les 580 autres lignes sur le disque. C'est le plus gros gain parce que la lecture de fichiers est la source la plus en pics.
- Filtrer la sortie de commandes. Retirez les barres de progression, les avertissements répétés et les 200 lignes de tests qui passent avant qu'ils n'atteignent le contexte. L'output filtering sur un test bruyant réduit régulièrement un bloc de 30k tokens à moins de 2k sans aucune perte de signal.
- Charger les outils paresseusement. N'expédiez pas tous les schémas MCP à chaque tour. N'exposez les définitions d'outils que lorsque l'agent est sur le point de les utiliser, pour que le plancher par tour reste bas.
- Compresser et squelettiser. Quand l'agent a vraiment besoin d'un gros fichier pour s'orienter, donnez-lui un skeleton — signatures et structure, pas les corps complets — et laissez-le demander l'implémentation complète seulement s'il en a besoin.
Ce qui dérape quand on ignore la fenêtre
Le mode de défaillance est progressif, et c'est pour ça que les gens passent à côté : l'agent ne casse pas, il devient juste discrètement plus cher et légèrement plus bête au fil d'une session. Voici les anti-patterns que je vois le plus. Laisser la session tourner indéfiniment. Plus une seule conversation vit longtemps, plus la fenêtre est grosse et plus chaque tour coûte cher. Une session de deux heures peut coûter 5 à 10 fois ce que coûterait le même travail réparti en sessions fraîches et cadrées. Quand une tâche est terminée, démarrez une nouvelle conversation ; ne traînez pas tout l'historique dans la suivante. Chargement empressé des MCP. Connecter chaque serveur dont vous pourriez un jour avoir besoin signifie payer pour tous ces schémas d'outils à chaque tour, pour toujours. Chargez paresseusement. Voyez les meilleurs serveurs MCP pour Claude Code pour savoir lesquels valent vraiment le coût par tour. Traiter le gonflement du contexte comme un problème de modèle du type « le milieu de la fenêtre est ignoré ». C'est réel — Liu et al. ont montré que la précision de récupération chute pour les faits enfouis au milieu d'un long contexte (« Lost in the Middle », 2023, arxiv.org/abs/2307.03172) — mais la solution n'est pas une fenêtre plus grande. C'est une fenêtre plus petite et plus dense. Une fenêtre bourrée coûte plus cher et masque le signal dont le modèle a besoin. Élaguer le bruit augmente à la fois votre marge et votre précision en même temps. Faire confiance au compteur que vous ne voyez pas. La plupart des gens n'ont aucune idée que leur fenêtre fait 70k tokens jusqu'à l'arrivée de la facture. Mesurez-la. Si votre outillage montre la taille d'input par tour, vous commencerez à sentir quelles actions sont chères, et cette intuition vaut plus que n'importe quelle optimisation isolée.Foire aux questions
Qu'est-ce qu'une context window, en une phrase ?
C'est la quantité maximale de texte — mesurée en tokens, pas en mots ni en caractères — qu'un modèle peut prendre en compte d'un coup, couvrant tout ce qu'on lui envoie et tout ce qu'il écrit en retour. L'entrée de glossaire context window en donne la définition complète ; cet article porte sur ce qu'elle vous coûte.Quelle est la taille de la context window de Claude ?
Les modèles Claude embarquent de grandes fenêtres, et le palier frontier atteint désormais 1 M de tokens. Mais le maximum publié est un plafond, pas un objectif : vous êtes facturé sur ce que vous mettez réellement dans la fenêtre à chaque tour, pas sur la taille qu'on vous autorise. Une fenêtre de 1 M utilisée à 40 k coûte exactement le prix de 40 k tokens. Cette distinction compte davantage que le chiffre lui-même, qui périme en une version — d'où notre choix de ne pas citer de valeurs par modèle : consultez la page du fournisseur, puis mesurez votre propre usage.Une plus grande context window coûte-t-elle plus cher ?
Pas par son existence, seulement par son remplissage. Les fournisseurs ne facturent pas la marge disponible. Ce qu'une grande fenêtre change, c'est le comportement : elle supprime le garde-fou qui tenait les sessions propres, alors on lit plus de fichiers « par sécurité » et on les paie à chaque tour suivant. Certains fournisseurs appliquent en outre une tarification majorée au-delà d'un seuil de tokens sur les requêtes à long contexte : une fenêtre remplie sans discernement devient alors un changement de tarif en plus d'un surcroît de volume. Vérifiez l'existence d'un palier long contexte chez votre fournisseur avant de supposer un coût linéaire.Une plus grande fenêtre améliore-t-elle la précision ?
Pas au-dessus du seuil de pertinence. Les modèles prêtent le moins d'attention à ce qui est enfoui au milieu d'une longue fenêtre — l'effet « lost in the middle » — si bien que rembourrer une fenêtre de fichiers vaguement liés dégrade la qualité tout en gonflant la facture. La pertinence bat le volume : c'est tout l'argument du retrieval contre le déversement.Comment voir la part réellement utilisée de ma fenêtre ?
Dans Claude Code,/context montre ce qui occupe la fenêtre à l'instant T — c'est la lecture qui indique quoi compacter. Faites-le en début de session avant de taper quoi que ce soit : ce qui s'y trouve déjà — système prompt, CLAUDE.md, schémas d'outils MCP — constitue votre surcoût permanent à chaque tour. Mesurer la consommation d'un agent traite la version multi-agents.
La fenêtre se réinitialise-t-elle entre les sessions ?
Oui : une nouvelle session démarre sur un transcript vide, ce qui fait du démarrage à neuf par tâche la gestion de contexte la moins chère qui soit. Compacter réduit une fenêtre existante en résumant les tours antérieurs ; cela rend les tours suivants moins chers, mais ne rembourse pas ce qui a déjà été dépensé.À voir aussi :
- Coût des LLM : ce qui le pilote et comment le réduire — la facture entière, pas seulement la fenêtre.
- Context engineering pour les agents de codage IA
- Comment réduire l'usage de tokens de Claude Code
- Glossaire : context window
Classé n°1 au Token-Harness Optimizer Leaderboard.
Tokenade est classé n°1 au Token-Harness Optimizer Leaderboard — un benchmark de bout en bout des optimiseurs de tokens, mesuré sur de vraies sessions de code. Installez-le une fois, il agit sur chaque prompt. Compatible avec Claude Code, Cursor, Codex, Copilot et plus.
