Input tokens vs output tokens

Résumer avec l'IA
Citer cette page

Que sont les input tokens et les output tokens ?

Les input tokens sont le texte que vous envoyez dans un modèle sur une requête donnée — votre prompt, le system prompt, l'historique de conversation, les fichiers qu'un agent a collés, la sortie d'une commande, les définitions d'outils. Les output tokens sont le texte que le modèle génère en retour : son raisonnement, sa réponse, le diff qu'il écrit. Les fournisseurs comptent les deux séparément, et — c'est le point que les gens manquent — ils les facturent à des tarifs différents. Le mécanisme est simple une fois qu'on le voit. Un modèle de langage est un prédicteur du prochain token. Pour produire chaque output token, il doit attendre sur chaque input token déjà présent dans le contexte, donc les deux côtés font réellement des quantités de travail différentes, et le prix le reflète. L'output est le côté cher à l'unité. Avec Claude Opus 4.8 à 5 $ / 25 $ par million de tokens (MTok), chaque output token coûte cinq fois un input token ; Sonnet 4.6 tourne à 3 $ / 15 $, Haiku 4.5 à 1 $ / 5 $, et GPT-5.5 est à 5 $ / 30 $ — un écart de 6×. Une lecture naïve dit donc « surveillez votre output ». Pour les AI coding agents, cette lecture est fausse, et elle est fausse d'une manière coûteuse.

Pourquoi c'est important en 2026

Voici ce que je dois sans cesse réexpliquer. L'output d'un agent par étape est petit — quelques centaines de tokens de plan, un patch, une commande shell. Son input est énorme et, pire, il est renvoyé à chaque étape. L'agent relit l'arborescence des fichiers, les buffers ouverts, les vingt derniers résultats d'outils, tout le transcript qui ne cesse de grossir, à chaque tour. Une session de 50 étapes peut réingérer le même contexte des dizaines de fois. Donc, même si l'output est 5 à 6× plus cher par token, le volume d'input l'écrase. Dans de vraies sessions de coding, je vois régulièrement l'input dépasser l'output dans un rapport de 50:1 ou pire. Multipliez ça par les prix par token ci-dessus et la facture est massivement une facture d'input. Optimiser vos prompts pour qu'ils soient laconiques, ou plafonner max_tokens, ne bouge presque pas l'aiguille. L'aiguille vit du côté input. C'est toute la raison d'être du prompt caching : les cache reads sont facturés à environ 10 % du tarif d'input normal, donc le préfixe statique que vous renvoyez à chaque tour bénéficie d'une remise de 90 %. C'est aussi pourquoi le vrai levier consiste à fournir moins d'input à l'agent au départ — envoyer un skeleton d'un fichier plutôt que le fichier entier, une semantic search plutôt que de déverser un répertoire, une sortie d'outil filtrée plutôt que 4 000 lignes de log de build. Réduisez l'input et vous réduisez le coût dominant, ce qui est exactement ce que fait Tokenade en se plaçant entre votre agent et le modèle. (Voyez le détail des tarifs de tokens des API LLM si vous voulez les chiffres actuels par modèle.)

Quand la distinction n'a pas d'importance

  • Génération single-shot, dominée par l'output. Si vous demandez à un modèle d'écrire un essai de 3 000 mots à partir d'un prompt d'une ligne, l'output domine réellement — le cadrage input/output s'inverse et plafonner ou streamer l'output est le bon réflexe.
  • Vous ne faites pas tourner un agent. Un chat à un seul tour sans boucle de relecture ne repaie jamais son input, donc l'argument « l'input est réingéré » s'évapore.
  • Vous ne vous souciez que de la limite de context window, pas du coût. L'input comme l'output consomment le même budget de fenêtre quel que soit le prix, donc pour la question du « tout faire tenir », un token est un token.
Si vous faites tourner un agent, en revanche, traitez « réduire les tokens » comme « réduire les input tokens » et vous viserez le bon 90 % de la facture. Tokenade est source-available (MIT) et gratuit jusqu'à ~10M tokens/mois si vous voulez observer votre propre répartition input/output sur le dashboard d'économies avant de décider que ça compte.

Voir aussi