Pourquoi les tokens de sortie Claude coûtent 5 fois plus

Pourquoi les tokens de sortie coûtent plus cher que les tokens d’entrée

Les tokens de sortie coûtent cinq fois plus cher que les tokens d’entrée sur tous les modèles Claude actuellement proposés. Cette différence vient de la nature du calcul. La lecture d’un prompt correspond à un seul passage dans le modèle. La génération d’une réponse nécessite un passage par token, et chaque passage doit attendre la fin du précédent.

Ce ratio est identique sur chaque ligne de la grille tarifaire. Le modèle que vous choisissez ne change donc pas la part de votre facture liée aux sorties. C’est la structure de votre workload qui la détermine. Une étape d’agent qui lit 60,000 tokens et répond avec 800 tokens consomme presque rien en sortie. Une tâche de rédaction qui lit 2,000 tokens et en génère 12,000 consomme presque rien en entrée. Les deux cas sont détaillés ci-dessous à partir des tarifs publiés par Anthropic en août 2026.

Le prefilling s’exécute une fois, le décodage une fois par token

Un serveur d’inférence traite une requête en deux phases dont les coûts sont très différents. Le prefilling lit le prompt. Le décodage génère la réponse.

Le prefilling traite l’intégralité du prompt en une seule fois. Tous les tokens du prompt entrent dans le réseau lors du même forward pass. Les opérations d’attention et feed-forward sont donc regroupées en un petit nombre de multiplications matricielles volumineuses portant sur des milliers de tokens à la fois. Une seule lecture des poids du modèle depuis la mémoire suffit pour traiter tout le prompt. Les unités matricielles de l’accélérateur restent sollicitées. Le prefilling est donc limité par le calcul : la limite dépend de la vitesse à laquelle la puce peut effectuer les multiplications.

Le décodage ne peut pas fonctionner de cette manière, car le token 2 dépend du token 1. Le token que le modèle vient de produire devient une partie de l’entrée de l’étape suivante. Les étapes ne peuvent donc pas s’exécuter simultanément. Chaque token de sortie nécessite son propre forward pass. Chacun de ces passages lit l’ensemble des poids du modèle depuis la mémoire à large bande passante pour produire un seul token. Le décodage est donc limité par la mémoire : la limite dépend de la vitesse à laquelle les poids peuvent être transférés, et non de la vitesse à laquelle ils peuvent être multipliés. Le même trafic de poids qui permettait de traiter tout un prompt pendant le prefilling ne produit qu’un token pendant le décodage.

Les systèmes de serving compensent cette contrainte par le batching. Plusieurs requêtes sont décodées ensemble. Une lecture des poids produit ainsi un token pour chaque requête du batch. C’est ce qui rend le décodage abordable. La limite vient à nouveau de la mémoire. Chaque requête en cours d’exécution conserve un KV cache (key/value cache, l’état d’attention stocké pour chaque token généré jusqu’à présent). Ce cache grandit à chaque token généré. Lorsqu’il remplit l’accélérateur, le batch ne peut plus augmenter.

Rien de tout cela ne fournit un nombre exact. Vous ne devez pas interpréter 5x comme un ratio matériel mesuré. Il s’agit d’un prix fixé par Anthropic, qui tient compte de cette asymétrie. Vous pouvez toutefois vérifier vous-même la tendance. Cela prend environ une minute.

Mesurez vous-même le délai d’entrée et de sortie

Installez les outils sur n’importe quelle machine Ubuntu :

sudo apt update && sudo apt install -y curl jq moreutils

Diffusez maintenant un prompt court qui demande une réponse longue, et ajoutez à chaque ligne l’heure à laquelle elle est arrivée.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s préfixe chaque ligne avec le nombre de secondes écoulées depuis le début de la commande. Deux éléments sont importants dans cette sortie. La première ligne content_block_delta correspond à votre délai avant le premier token ; tout le prefill s’est déroulé pendant cette étape. Chaque ligne suivante correspond à une petite étape de décodage, et les valeurs continuent d’augmenter jusqu’à l’arrivée de message_stop.

Inversez maintenant la configuration. Placez un long document dans le prompt et limitez la réponse à quelques tokens.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

Le premier delta prend plus de temps qu’avec le prompt court, car le prefill doit lire beaucoup plus de texte. Une fois ce delta arrivé, la réponse se termine presque immédiatement, car il ne reste que quelques tokens à décoder. Des dizaines de milliers de tokens sont entrés, mais l’horloge a à peine avancé. Quelques centaines sont sortis, et l’horloge a continué à tourner pendant toute l’opération.

Chaque réponse non diffusée se termine par les nombres utilisés pour la facturation.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

Journalisez les 4 champs pour chaque requête. output_tokens inclut le extended thinking ; un modèle qui réfléchit avant de répondre facture donc cette réflexion au tarif de sortie. Pour calculer le prix d’un prompt avant de l’envoyer, POST /v1/messages/count_tokens accepte le même corps de requête, renvoie {"input_tokens": N} sans exécuter le modèle, et cette opération est gratuite.

Tarifs de Claude par million de tokens en août 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

La dernière colonne correspond au rapport entre la sortie et l’entrée, et affiche 5 sur chaque ligne. Haiku 4.5 facture $1 pour l’entrée et $5 pour la sortie. Opus 5 facture $5 et $25. Fable 5, le modèle le plus cher, facture $10 et $50. Ce que ces tarifs de Fable 5 vous permettent d’obtenir mérite d’être lu avant d’écarter cette première ligne. En montant dans la gamme, les deux tarifs sont multipliés par le même facteur. Le total change, mais la répartition entre entrée et sortie reste exactement la même.

Sonnet 5 apparaît deux fois, car son tarif de lancement expire. Jusqu’au 31 août 2026, il facture $2 et $10. À partir du 1 septembre 2026, le tarif standard de $3 et $15 s’applique, soit 50% de plus pour l’entrée comme pour la sortie. Tous les exemples détaillés ci-dessous utilisent le tarif d’août.

Les tarifs évoluent. Cette page ne doit pas servir à les vérifier. claude.com/pricing fait référence. La méthode reste valable même après une modification des tarifs.

La liste des tarifs ne montre pas un élément important. La documentation d’Anthropic indique que Claude 4.7 et les modèles ultérieurs utilisent un tokenizer plus récent, qui produit environ 30% de tokens supplémentaires pour un même texte par rapport au tokenizer de Sonnet 4.6 et des versions antérieures. Comparer deux modèles uniquement selon leur prix par million de tokens favorise artificiellement le plus récent, car le même document contient davantage de tokens avec celui-ci. Comparez plutôt le coût par tâche terminée et testez vos véritables prompts avec le modèle que vous prévoyez réellement d’utiliser. Ce que représente réellement un million de tokens Claude explique à quoi correspond ce volume en pratique.

Quand la sortie commence-t-elle à dominer votre facture ?

Avec une sortie facturée 5 fois plus cher que l’entrée, le seuil d’équilibre est facile à retenir. Appelez I le nombre de tokens d’entrée et O le nombre de tokens de sortie. Le coût de l’entrée est I. Le coût de la sortie est 5 fois O. La sortie représente plus de la moitié de vos dépenses lorsque 5 fois O est supérieur à I, soit un ratio de 5 tokens d’entrée pour 1 token de sortie.

Ainsi, si votre prompt est plus de cinq fois plus long que votre réponse, l’entrée représente le poste de dépense principal. En dessous de ce ratio, c’est la sortie.

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

Avec un ratio de 100 pour 1, la sortie représente 4.8% des dépenses, et réduire le prompt est le seul travail qui en vaille la peine. Avec un ratio de 5 pour 1, les deux postes sont à égalité. Avec un ratio de 1 pour 6, la sortie représente 96.8% des dépenses et le prompt est négligeable. La plupart des utilisateurs évaluent mal leur propre ratio. Consultez donc vos journaux avant toute optimisation.

Un workload d’agent : contexte long en entrée, réponse courte en sortie

Effectuez une étape d’agent de retrieval : 60,000 tokens de documents récupérés et d’historique de conversation en entrée, puis une réponse de 800 tokens. Le ratio est de 75 pour 1, ce qui est normal pour tout système qui lit avant d’écrire.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

La sortie représente 6.25% du coût de cet appel sur tous les modèles, car le ratio reste fixe dans toute la grille tarifaire. L’appel coûte $0.32 sur Opus 5, $0.128 sur Sonnet 5 au tarif d’août, et $0.064 sur Haiku 4.5. Deux cents étapes de ce type par jour sur Opus 5 coûtent $64 par jour.

Le levier est évident dès que vous voyez la répartition. Réduire la réponse de 800 tokens à 400 n’économise qu’environ 3% du coût de l’appel. Retirer 20,000 tokens de contexte obsolète du prompt en économise environ un tiers. Réduire la longueur de sortie sur un agent qui lit beaucoup est presque un effort inutile. où vont réellement les tokens d’un agent de codage détaille ce qui remplit ce prompt au départ.

Une charge de génération : prompt court, brouillon long

Changez maintenant de configuration. Un brief de 2,000 tokens produit un brouillon de 12,000 tokens, soit un ratio de 1 à 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

La sortie représente 96.8% de cette facture. Opus 5 coûte $0.31 par brouillon, contre $0.062 avec Haiku 4.5. Cet écart d’un facteur cinq vient presque entièrement de la sortie. C’est précisément sur ce poste qu’un modèle moins cher vous fait économiser le plus.

La dernière colonne correspond à la même tâche via la Batch API, qui réduit de 50% le coût des entrées et des sorties. Opus 5 revient alors à $0.155 par brouillon. Batch renvoie les résultats sous 24 heures au lieu de les fournir immédiatement. Il convient donc à la génération nocturne de rapports et à la classification en masse. En revanche, il ne convient pas aux tâches pour lesquelles une personne attend le résultat.

Le routage entre modèles est rentable ici, contrairement à l’étape agent. Si la partie verbeuse de la tâche est mécanique, par exemple reformater du texte ou développer un plan que vous avez déjà approuvé, le modèle moins cher produit ces tokens pour un cinquième du prix. choisir entre Opus, Sonnet et Haiku explique où se situe réellement le seuil de qualité.

Le cache réduit le coût des entrées, et uniquement des entrées

Le prompt caching stocke un préfixe de votre prompt sur le serveur et facture une fraction du tarif des entrées pour le relire. En août 2026, les multiplicateurs sont de 1.25x le tarif de base des entrées pour écrire un cache de 5 minutes, de 2x pour écrire un cache d’1 heure et de 0.1x pour lire une entrée en cache.

La sortie n’est pas concernée. Il n’existe pas de sortie mise en cache. Chaque token généré par le modèle est facturé au tarif complet des sorties, à chaque fois, quelle que soit la quantité du prompt relue depuis le cache.

Prenez la même étape d’agent avec Opus 5, avec 55,000 des 60,000 tokens d’entrée servis depuis un cache actif.

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

L’appel passe de $0.32 à $0.0725. La ligne de sortie ne change pas : $0.02 avant, $0.02 après. Le caching réduit la facture et en modifie la répartition. La sortie représentait 6.25% de cet appel. Elle en représente maintenant plus d’un quart, ce qui change le levier à utiliser ensuite.

Le premier appel paie l’écriture. L’écriture d’un cache de 5 minutes coûte 1.25x le tarif de base des entrées : elle est donc amortie après une seule lecture. L’écriture d’un cache d’1 heure coûte 2x : il faut donc deux lectures. les multiplicateurs d’écriture et de lecture, et le point où le caching cesse d’être rentable présente ce calcul en détail.

Quatre leviers que vous contrôlez

1. Définissez max_tokens à partir de la longueur p95 de vos sorties, et non de la limite maximale du modèle.
2. Routez les étapes verbeuses vers un modèle moins cher.
3. Regroupez tout ce qui n’attend aucune réponse immédiate.
4. Supprimez les instructions qui allongent les réponses.

max_tokens est une limite stricte. La définir à une valeur élevée ne coûte rien en soi, car la facturation porte sur les tokens produits, jamais sur la limite. Une limite généreuse supprime la contrainte qui s’appliquerait à une réponse qui dérape. Extrayez la distribution output_tokens de vos journaux, définissez la limite légèrement au-dessus du 95e percentile, puis gérez stop_reason: "max_tokens" dans le code en poursuivant la réponse ou en effectuant une nouvelle tentative. Une troncature détectée coûte moins cher qu’une digression de 4,000 tokens que vous payez avant de la jeter. Le extended thinking est également inclus dans output_tokens. Définissez donc ce budget à partir des mêmes données.

Le routage est pertinent lorsque le coût principal d’une étape vient du volume plutôt que du jugement. Conservez le modèle performant pour la décision, et confiez la rédaction à un modèle moins cher. Mesurez d’abord la version routée sur votre propre jeu d’évaluation, car un modèle bon marché qui nécessite deux tentatives coûte plus cher qu’une seule tentative avec un modèle coûteux.

Le batching est le seul levier qui réduit le coût de la sortie. Une remise de 50% sur les deux côtés, des résultats disponibles sous 24 heures, et toute tâche planifiée sont éligibles.

Le dernier levier est celui que beaucoup négligent. Des formulations comme « soyez exhaustif » et « expliquez votre raisonnement » définissent la longueur de sortie pour chaque appel que vous effectuerez. Remplacez-les par la forme souhaitée : « Répondez en trois phrases maximum » ou « Retournez uniquement l’objet JSON, sans préambule ». Un system prompt qui ajoute 300 tokens à chaque réponse coûte cinq fois plus cher que ces mêmes 300 tokens dans le prompt. maîtriser les coûts d’un agent qui s’exécute en continu couvre le suivi, et déterminer si l’API ou un abonnement forfaitaire revient moins cher pour votre usage mérite d’être tranché avant de passer une semaine à optimiser une dépense par token qu’un abonnement aurait absorbée.

FAQ

Pourquoi les tokens de sortie coûtent-ils plus cher que les tokens d’entrée ?

Leur génération nécessite beaucoup plus de temps de calcul sur les accélérateurs, token par token. Un prompt est traité en un seul forward pass sur l’ensemble du texte : une seule lecture des poids du modèle couvre des milliers de tokens, et le matériel est alors limité par le débit des opérations de multiplication. Une réponse est produite un token à la fois. Chaque token nécessite son propre forward pass, qui relit l’ensemble des poids du modèle. Le matériel est donc limité par la bande passante mémoire. Anthropic facture la sortie cinq fois plus cher que l’entrée dans toute sa gamme actuelle, de Haiku 4.5 à Fable 5.

Le prompt caching réduit-il le coût des tokens de sortie ?

Non. Le prompt caching s’applique uniquement à l’entrée. En août 2026, une lecture du cache coûte 0.1x le tarif d’entrée de base. L’écriture dans le cache coûte 1.25x pour une durée de 5 minutes, ou 2x pour une durée de 1 heure. La sortie est facturée au tarif plein à chaque appel, quel que soit le fonctionnement du cache. C’est pourquoi le caching modifie à la fois la structure et le montant de votre facture : une fois le coût de l’entrée réduit, la sortie devient la part qui mérite votre attention.

Un max_tokens élevé me coûte-t-il de l’argent si la réponse est courte ?

Non. Vous payez les tokens effectivement produits par le modèle. max_tokens est donc une limite maximale, et non une réservation. Ce paramètre reste important, car c’est la seule limite stricte qui empêche une réponse de devenir excessivement longue. Définissez-le légèrement au-dessus du 95e percentile de votre output_tokens observé, puis gérez stop_reason: "max_tokens" dans le code au lieu de déployer une réponse tronquée sans avertissement.

Comment déterminer mon propre ratio entre tokens d’entrée et de sortie ?

Journalisez input_tokens, output_tokens, cache_read_input_tokens et cache_creation_input_tokens depuis l’objet usage de chaque réponse, puis divisez les totaux calculés sur une semaine. Au-delà de 5 tokens d’entrée pour 1 token de sortie, votre coût vient principalement du prompt. Mettez donc sa partie stable en cache et réduisez le reste. En dessous de ce ratio, votre coût vient principalement de la réponse. Limitez donc sa longueur et déplacez vers un modèle moins cher ou vers la Batch API les étapes qui génèrent le plus de contenu.