Tokens d’entrée ou de sortie : le coût Claude

Pourquoi les tokens de sortie coûtent plus cher que ceux 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 du catalogue actuel. Cette différence vient de la nature du calcul. La lecture d’un prompt correspond à un seul passage sur le modèle. La génération d’une réponse nécessite un passage par token, chaque passage devant attendre la fin du précédent.

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

Le prefill s’exécute une fois, le decoding 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 prefill lit le prompt. Le decoding génère la réponse.

Le prefill 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 de feed-forward deviennent donc un petit nombre de multiplications matricielles de grande taille, 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 prefill est donc limité par le calcul : la limite dépend de la vitesse à laquelle la puce peut effectuer les multiplications.

Le decoding 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 en parallèle. 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 afin de produire un seul token. Le decoding est donc limité par la mémoire : la limite dépend de la vitesse de déplacement des poids, et non de la vitesse des multiplications. Le même trafic de poids qui permettait de traiter tout un prompt pendant le prefill ne produit qu’un token pendant le decoding.

Les systèmes de serving compensent ce problème avec le batching. De nombreuses requêtes effectuent leur decoding ensemble. Une lecture des poids produit ainsi un token pour chaque requête du batch. C’est la raison pour laquelle le decoding reste abordable. La limite vient de nouveau de la mémoire. Chaque requête en cours conserve un KV cache (key/value cache, l’état d’attention mémorisé pour chaque token généré jusqu’à présent). Ce cache augmente à chaque token généré. Lorsque la mémoire de l’accélérateur est pleine, le batch ne peut plus augmenter.

Rien de tout cela ne fournit un chiffre exact. Vous ne devez pas non plus 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 en revanche vérifier vous-même la direction de l’écart, et cela prend environ une minute.

Mesurez vous-même les délais 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 court prompt qui demande une réponse longue, et ajoutez à chaque ligne l’heure de sa réception.

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 utiles à relever dans cette sortie. La première ligne content_block_delta correspond à votre délai avant le premier token, et tout le prefill s’est déroulé pendant ce délai. Chaque ligne suivante correspond à une petite étape de decoding, et les horodatages 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 reçu, 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, et l’horloge a à peine avancé. Quelques centaines sont sortis, et l’horloge a tourné pendant toute l’opération.

Chaque réponse non streamé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 quatre champs pour chaque requête. output_tokens inclut le extended thinking : un modèle qui réfléchit avant de répondre facture cette réflexion au tarif de sortie. Pour estimer 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 est gratuit. Ce n’est pas la seule partie de l’API qui ne coûte rien, et les parties de l’API Claude qui ne vous sont jamais facturées méritent d’être vérifiées avant d’établir le budget d’un premier projet.

Ce que Claude facture 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 à la sortie divisée par l’entrée, soit 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 plus cher, facture $10 et $50. Ce que ces tarifs de Fable 5 vous apportent mérite d’être lu avant d’écarter cette ligne supérieure. En montant dans la gamme, les deux montants 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 changent. Cette page ne doit pas servir à les vérifier. claude.com/pricing fait foi. Ce qui reste valable après une modification tarifaire, c’est la méthode.

La grille tarifaire ne montre pas un point important. La documentation d’Anthropic indique que les modèles Claude 4.7 et ultérieurs utilisent un tokenizer plus récent, qui produit environ 30% de tokens en plus pour un même texte que le tokenizer de Sonnet 4.6 et des versions antérieures. Comparer deux modèles uniquement sur le prix par million de tokens favorise artificiellement le plus récent, car un même document contient davantage de tokens avec celui-ci. Comparez plutôt le coût d’une tâche terminée et comptabilisez vos vrais prompts avec le modèle que vous prévoyez réellement d’utiliser. Le même problème se pose entre les fournisseurs, dont les tokenizers diffèrent encore davantage. Calculer le coût d’une tâche réelle avec Claude et ChatGPT vous en apprendra donc plus que de placer les deux grilles tarifaires côte à côte. Ce que valent réellement un million de tokens Claude en texte explique à quoi ce volume correspond en pratique.

À partir de quand les sorties commencent-elles à peser sur votre facture ?

Lorsque la sortie est 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. Celui 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. À 5 pour 1, les deux postes sont à égalité. À 1 pour 6, la sortie représente 96.8% des dépenses et le prompt est négligeable. La plupart des gens évaluent mal leur propre ratio. Relevez-le dans vos logs avant toute optimisation.

Charge de travail d’un agent : long contexte en entrée, réponse courte en sortie

Examinez une seule étape d’un agent de retrieval : 60,000 tokens de documents récupérés et d’historique de conversation en entrée, pour une réponse de 800 tokens. Le rapport 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 chaque modèle, car le ratio reste fixe dans toute la grille tarifaire. L’appel coûte $0.32 avec Opus 5, $0.128 avec Sonnet 5 au tarif d’août, et $0.064 avec Haiku 4.5. Deux cents étapes de ce type par jour avec Opus 5 coûtent $64 par jour.

Le levier est évident dès que l’on voit cette répartition. Réduire la réponse de 800 tokens à 400 permet d’économiser environ 3% du coût de l’appel. Supprimer 20,000 tokens de contexte obsolète du prompt permet d’en économiser environ un tiers. Réduire la longueur de sortie d’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.

Une tâche de génération : prompt court, brouillon long

Changeons de configuration. Un brief de 2,000 tokens, 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 de cinq fois vient presque entièrement de la sortie, qui est précisément le poste sur lequel 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. Cette option convient donc à la génération nocturne de rapports et à la classification en volume. Elle ne convient pas aux tâches pour lesquelles une personne attend le résultat.

Le routage entre modèles est avantageux 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 déjà validé, le modèle moins cher produit ces tokens pour un cinquième du prix. La section choisir entre Opus, Sonnet et Haiku explique où se situe réellement la limite de qualité.

Le cache réduit le coût de l’entrée, et uniquement de l’entrée

Le prompt caching conserve un préfixe de votre prompt sur le serveur et facture une fraction du tarif d’entrée pour le relire. En août 2026, les multiplicateurs sont de 1.25x le tarif d’entrée de base pour écrire un cache de 5 minutes, de 2x pour écrire un cache d’une 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 de sortie complet, à chaque fois, quelle que soit la quantité du prompt renvoyée depuis le cache.

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

[
  {
    "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. Le coût de sortie ne change pas : $0.02 avant, $0.02 après. Le cache 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 qu’il est pertinent d’actionner ensuite.

Le premier appel paie l’écriture. Une écriture de cache de 5 minutes coûte 1.25x le tarif d’entrée de base ; elle est donc amortie après une seule lecture. Une écriture d’une heure coûte 2x ; il lui faut donc deux lectures. les multiplicateurs d’écriture et de lecture, ainsi que le point où le cache cesse d’être rentable détaille ce calcul.

Quatre leviers à votre disposition

1. Définissez max_tokens sur la longueur p95 de vos réponses, et non sur la limite maximale du modèle.
2. Acheminez 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 simplement la contrainte sur une réponse qui dérape. Extrayez la distribution output_tokens de vos logs, 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 réessayant. Une troncature détectée coûte moins cher qu’une réponse 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 la partie coûteuse d’une étape tient au volume plutôt qu’au 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 prix de la sortie. Une remise de 50% sur les deux côtés, avec des résultats sous 24 heures, et tout ce qui est planifié sont éligibles.

Le dernier levier est souvent négligé. Des formulations comme « soyez exhaustif » et « expliquez votre raisonnement » augmentent la longueur de vos réponses à chaque appel futur. 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. garder les coûts d’un agent en fonctionnement sous contrôle couvre le suivi, et déterminer si l’API ou un abonnement forfaitaire est moins cher pour votre usage mérite d’être réglé avant de passer une semaine à optimiser une dépense par token qu’un abonnement aurait absorbée. Pour un développeur seul, cela revient surtout à déterminer si les $20 par mois de Claude Pro et ses limites d’utilisation couvrent le travail qui serait autrement facturé à l’usage. Si vous atteignez déjà ces limites au milieu d’une session, déterminer quelle fenêtre vous devez attendre est prioritaire, car la solution peut ensuite être un modèle plus petit, un contexte allégé, des crédits d’utilisation supplémentaires ou le transfert de ce travail vers l’API facturée à l’usage. Si l’API facturée à l’usage s’avère moins chère pour ce travail, passer à un forfait inférieur ou le résilier conserve le mois déjà payé ; le changement ne vous coûte donc rien. Si le forfait auquel vous comparez Pro est celui de ChatGPT plutôt que l’API facturée à l’usage, les deux niveaux d’abonnement avec leurs prix côte à côte indiquent lequel revient moins cher pour le développement. Si la question concerne une équipe plutôt qu’un seul développeur, notez que Claude Enterprise associe des frais par siège à des tokens facturés aux mêmes tarifs API, de sorte que tous les leviers de cette page s’appliquent encore à la partie de la facture facturée à l’usage.

FAQ

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

Leur génération mobilise beaucoup plus de temps d’accélérateur par token. Le prompt est traité en un seul passage forward sur l’ensemble du texte : une seule lecture des poids du modèle couvre ainsi des milliers de tokens, et le matériel est 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 passage forward, 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 tout son catalogue actuel, de Haiku 4.5 à Fable 5.

Le prompt caching rend-il les tokens de sortie moins chers ?

Non. Le prompt caching s’applique uniquement à l’entrée. En août 2026, la 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 normal à chaque appel, quel que soit le fonctionnement du cache. C’est pourquoi le caching modifie la structure de votre facture autant que son montant : une fois le coût de l’entrée réduit, la sortie devient le poste sur lequel il faut agir.

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

Non. Vous êtes facturé pour les tokens effectivement produits par le modèle. max_tokens est donc une limite supérieure, pas une réservation. Ce paramètre reste important, car c’est la seule limite stricte qui empêche une réponse de devenir trop 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 distribuer une réponse tronquée sans l’indiquer.

Comment trouver mon propre ratio entre les 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 calculez les totaux sur une semaine. Au-delà de 5 tokens d’entrée pour 1 token de sortie, votre coût se situe dans le prompt : mettez donc en cache sa partie stable et réduisez le reste. En dessous de ce ratio, votre coût se situe dans la réponse : limitez sa longueur et déplacez vers un modèle moins cher ou vers la Batch API les étapes qui en génèrent la plus grande partie.