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

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. Cela tient à la nature du calcul. La lecture d’un prompt correspond à un seul passage sur le modèle. La rédaction d’une réponse nécessite un passage par token, et chaque passage doit attendre le précédent.

Ce ratio est identique sur chaque ligne de la grille tarifaire. Le modèle choisi ne modifie donc pas la part de votre facture consacrée à la sortie. C’est la forme de votre charge de travail qui la détermine. Une étape d’agent qui lit 60,000 tokens et répond en 800 dépense presque rien en sortie. Une tâche de rédaction qui lit 2,000 tokens et écrit 12,000 dépense presque rien en entrée. Les deux cas sont détaillés ci-dessous à partir des tarifs publiés par Anthropic, vérifiés le 27 octobre 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 produit la réponse.

Le prefill traite tout le prompt en une seule fois. Chaque token du prompt entre dans le réseau lors de la même passe forward. Les calculs d’attention et feed-forward deviennent donc un petit nombre de grandes multiplications matricielles couvrant plusieurs 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 occupées. Le prefill est donc généralement limité par le calcul : la limite dépend de la vitesse à laquelle la puce peut multiplier. La documentation NVIDIA dédiée au serving indique les exceptions : les prefills très courts et ceux dont un long préfixe est déjà présent dans le cache deviennent limités par la mémoire.

Le decoding ordinaire ne peut pas fonctionner ainsi, 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 s’exécutent donc l’une après l’autre. Chaque token de sortie nécessite sa propre passe forward. Chacune de ces passes lit l’ensemble des poids du modèle, ainsi que le KV cache (cache key/value, qui stocke l’état d’attention de chaque token traité jusque-là), depuis la mémoire à large bande passante afin de produire un seul token. Le decoding est donc généralement limité par la mémoire : la limite dépend de la vitesse à laquelle les poids et l’état mis en cache peuvent être transférés, et non de la vitesse à laquelle ils peuvent être multipliés. Pour les contextes longs, NVIDIA identifie précisément les lectures du KV cache comme le goulot d’étranglement. Le même trafic de poids qui a permis de traiter tout un prompt pendant le prefill ne permet de produire qu’un seul token pendant le decoding.

Le speculative decoding assouplit cette règle sans la supprimer. Un petit modèle draft prédit plusieurs tokens à l’avance. Le modèle principal les vérifie tous en parallèle lors d’une seule passe. Selon NVIDIA, cela peut déplacer le decoding vers une charge limitée par le calcul. Le modèle principal accepte toujours les prédictions dans l’ordre et s’arrête dès la première erreur. Une réponse longue nécessite donc toujours de nombreuses passes.

Les systèmes de serving compensent ce phénomène avec le batching. Plusieurs requêtes effectuent leur decoding ensemble. Une seule lecture des poids produit alors un token pour chaque requête du batch. C’est ce qui rend le decoding abordable. La limite vient de nouveau de la mémoire. Chaque requête en cours conserve son propre KV cache. Ce cache augmente à chaque token généré. Lorsqu’il remplit l’accélérateur, le batch ne peut plus grandir.

Rien de tout cela ne vous donne un nombre exact. Vous ne devez pas non plus interpréter 5x comme un ratio matériel mesuré. Il s’agit d’un coût défini par Anthropic et fondé sur cette asymétrie. Vous pouvez vérifier vous-même la tendance. Cela prend environ une minute.

Mesurez vous-même l’écart entre les entrées et les sorties

Installez les outils sur n’importe quelle machine Ubuntu :

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

Lancez maintenant un prompt court qui demande une réponse longue, et ajoutez à chaque ligne l’heure à laquelle elle est reçue.

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 ajoute en préfixe de chaque ligne le nombre de secondes écoulées depuis le début de la commande. Deux éléments sont à relever 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 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 est plus long qu’avec le prompt court, car le prefill doit lire beaucoup plus de texte. Une fois ce delta reçu, la réponse est presque immédiatement terminée, 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 tourné pendant toute l’opération.

Chaque réponse sans streaming se termine par les nombres utilisés pour votre 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 les tokens de réflexion : un modèle qui réfléchit avant de répondre facture cette réflexion au tarif des sorties. Pour estimer le prix d’un prompt avant de l’envoyer, POST /v1/messages/count_tokens utilise le même corps de requête pour la plupart des requêtes, renvoie {"input_tokens": N} comme estimation sans exécuter le modèle et reste gratuit dans la limite de son propre rate limit. Il refuse certains corps acceptés par l’API Messages : la plupart des server tools, comme la recherche web, le connecteur MCP et les blocs d’image ou de document dont la source est url ou file. Envoyez donc les images et les PDF en base64 lorsque vous les comptez. 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 consultées avant d’établir le budget d’un premier projet.

Ce que coûte Claude par million de tokens en octobre 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10,
    "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, 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 plus cher, facture $10 et $50, et ce que ces tarifs Fable 5 vous permettent de faire mérite d’être lu avant d’écarter cette première ligne. 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 facture $2 pour l’entrée et $10 pour la sortie. Anthropic l’a lancé à ce tarif promotionnel jusqu’au 31 août 2026, avec une hausse à $3 et $15 prévue le 1 septembre, puis a finalement fixé le tarif standard à $2 et $10. La hausse n’a jamais pris effet : le tarif utilisé dans chaque exemple détaillé ci-dessous est donc celui que vous payez aujourd’hui.

Anthropic a également sorti de nouveaux modèles depuis la mise en ligne initiale de cette page. Le site claude.com/pricing répertorie désormais les quatre modèles ci-dessus comme des modèles anciens qui restent disponibles. Les nouveaux conservent le même ratio de 5x. Opus 5.5 facture $4 et $20, Sonnet 5.5 facture $2 et $10, Fable 5.1 facture $10 et $50, et Haiku 5.5 facture $0.10 et $0.50 pour les prompts allant jusqu’à 100,000 tokens, puis $0.50 et $2.50 au-delà. L’étape d’agent de 60,000 tokens calculée plus loin reste sous ce seuil, mais un agent dont l’historique continue de grossir finira par le dépasser. Cet exemple montre l’impact de ces deux niveaux de prix de Haiku 5.5 sur une tâche réelle sur la facture. Les tarifs de base pour l’entrée et la sortie d’Opus 5.5 sont inférieurs de 20% à ceux d’Opus 5. Chaque montant non mis en cache indiqué plus bas pour Opus 5 est donc inférieur de 20% avec Opus 5.5. Les montants mis en cache diminuent davantage, car Opus 5.5 facture les cache hits $0.20 par million de tokens, contre $0.50 pour Opus 5, soit une réduction de 60%. L’étape d’agent mise en cache qui coûte $0.0725 avec Opus 5 coûte environ $0.047 avec Opus 5.5, soit environ 35% de moins.

Les tarifs changent, et cette page n’est pas la source à consulter pour les vérifier. claude.com/pricing fait foi. Ce qui reste valable après un changement de tarif, c’est la méthode.

Une réserve figure dans les notes sous le tableau des tarifs d’Anthropic, et non dans les tarifs eux-mêmes. La page de tarification d’Anthropic indique que Claude 4.7 et les modèles suivants 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 sur leur prix par million de tokens avantage le modèle le plus récent, car le même document contient davantage de tokens avec celui-ci. Comparez plutôt le coût d’une tâche terminée, et comptez vos prompts réels avec le modèle que vous prévoyez d’utiliser. Le même piège existe entre les fournisseurs, dont les tokenizers diffèrent également. Calculer le coût d’une tâche réelle avec Claude et ChatGPT vous renseignera donc davantage que de placer les deux grilles tarifaires côte à côte. Ce que représente réellement un million de tokens Claude dans un texte explique à quoi correspond ce volume en pratique.

Quand la sortie commence-t-elle à représenter l’essentiel de 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 en entrée et O le nombre de tokens en 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 en entrée pour 1 token en sortie.

Ainsi, si votre prompt est plus de cinq fois plus long que votre réponse, l’entrée représente le poste le plus important. 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 la seule tâche 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% et le prompt est négligeable. La plupart des gens évaluent mal leur propre ratio ; récupérez-le dans vos logs avant toute optimisation.

Charge de travail d’un agent : contexte long, réponse courte

Effectuez une étape d’un agent de récupération : 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 rapport est de 75 pour 1, ce qui est normal pour toute tâche qui lit avant d’écrire.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5",
    "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% de cet appel sur chaque modèle, car le rapport reste fixe dans toute la grille tarifaire. L’appel coûte $0.32 avec Opus 5, $0.128 avec Sonnet 5 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 devient évident une fois la répartition comprise. Réduire la réponse de 800 tokens à 400 n’économise qu’environ 3% du coût de l’appel. Supprimer 20,000 tokens de contexte obsolète du prompt en économise environ un tiers. Réduire la longueur de sortie d’un agent principalement consacré à la lecture revient presque à gaspiller ses efforts. où vont réellement les tokens d’un agent de programmation détaille ce qui remplit ce prompt.

Un workload de génération : prompt court, brouillon long

Inversion de la structure. 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",
    "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 là qu’un modèle moins cher vous fait économiser le plus.

La dernière colonne montre le même traitement via l’API Batch, qui réduit de 50% le coût des entrées et des sorties. Opus 5 revient à $0.155 par brouillon. Batch est asynchrone, et non immédiat. Anthropic indique que la plupart des batches se terminent en moins d’une heure, mais qu’un batch encore en cours après 24 heures expire. Toute requête qui n’a pas encore été traitée à ce moment-là revient avec le statut expiré, sans être facturée et sans message. Cette solution convient donc à la génération de rapports pendant la nuit et à la classification en volume, avec une étape de resoumission pour les éléments qui expirent. Elle ne convient pas lorsqu’une personne attend le résultat.

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

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

La mise en cache des prompts stocke un préfixe de votre prompt sur le serveur et facture une fraction du tarif d’entrée lors de sa relecture. Au 27 octobre 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 relire une entrée présente dans le cache sur les modèles tarifés sur cette page. Les modèles les plus récents facturent moins cher les entrées présentes dans le cache : 0.05x sur Opus 5.5 et Sonnet 5.5, et 0.025x sur Fable 5.1.

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 récupérée depuis le cache.

Exécutez la même étape d’agent sur Opus 5, avec 55,000 des 60,000 tokens d’entrée servis depuis un cache déjà alimenté.

[
  {
    "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. La mise en 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 à actionner en priorité.

Le premier appel paie l’écriture. L’écriture d’un cache de 5 minutes coûte 1.25x le tarif d’entrée de base : elle est donc amortie après un seul hit. Une écriture d’une heure coûte 2x : il lui faut donc deux hits. les multiplicateurs d’écriture et de lecture, et le point où la mise en cache cesse d’être rentable détaille ce calcul.

Quatre leviers que vous contrôlez

1. Définissez max_tokens sur la longueur de sortie p95, et non sur le maximum du modèle.
2. Acheminez les étapes verbeuses vers un modèle moins cher.
3. Traitez par lots tout ce que personne n’attend.
4. Supprimez les instructions qui allongent les réponses.

max_tokens est une limite stricte. La définir à un niveau élevé ne coûte rien en soi, car vous payez les tokens produits, jamais la limite. Un plafond généreux supprime simplement la limite qui s’applique à une réponse qui dérape. Extrayez la distribution de output_tokens de vos journaux, définissez le plafond 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 tirade de 4,000 tokens que vous payez avant de la jeter. Le raisonnement est également comptabilisé dans output_tokens et déduit de max_tokens. Définissez donc le plafond à partir des mêmes données. Sur les modèles à raisonnement adaptatif, réduisez le niveau d’effort si le raisonnement consomme constamment la réponse.

L’acheminement est efficace lorsque la partie coûteuse d’une étape tient au volume plutôt qu’au jugement. Gardez le modèle puissant pour la décision et confiez la rédaction à un modèle moins cher. Mesurez d’abord la version acheminée sur votre propre jeu d’évaluation, car la donnée importante est le coût par tâche terminée. Pour l’étape d’agent ci-dessus, deux tentatives avec Haiku 4.5 coûtent $0.128, contre $0.32 pour une tentative avec Opus 5. L’écart de prix couvre donc un ou deux nouveaux essais. En revanche, il ne couvre pas une réponse incorrecte que personne ne détecte.

Le traitement par lots est le seul levier qui réduit le prix de la sortie. 50% de réduction sur les deux côtés, la plupart des lots étant traités en moins d’une heure, et toute tâche planifiée est admissible, à condition que le traitement soumette à nouveau les tâches qui expirent au bout de 24 heures.

Le dernier levier est celui que les gens 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 prompt système qui ajoute 300 tokens à chaque réponse coûte cinq fois plus cher que les mêmes 300 tokens ajoutés au prompt. maîtriser les coûts d’un agent en fonctionnement couvre l’aspect supervision, et déterminer si l’API ou un abonnement forfaitaire est 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. Pour un développeur, cela revient surtout à déterminer si les $20 mensuels de Claude Pro et les limites d’utilisation associées couvrent le travail que vous factureriez sinon à l’usage. Si vous atteignez déjà ces limites au milieu d’une session, déterminer sur quelle fenêtre vous êtes en attente devient prioritaire, car la solution consiste alors à utiliser un modèle plus petit, un contexte plus léger, des crédits d’utilisation supplémentaires ou à déplacer ce travail vers l’API facturée à l’usage. Si l’API facturée à l’usage s’avère être l’option la moins chère pour ce travail, passer à un forfait inférieur ou résilier l’abonnement préserve le mois déjà payé. Le changement ne vous coûte donc rien. Si le forfait auquel vous comparez Pro est celui de ChatGPT et non l’API facturée à l’usage, les gammes d’abonnement des deux services affichées côte à côte indiquent lequel revient le moins cher pour le travail de programmation. 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 chaque levier de cette page s’applique toujours à la moitié facturée à l’usage de cette facture.

FAQ

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

Leur génération nécessite beaucoup plus de temps de calcul sur les accélérateurs, token par token. Le prompt est traité en un seul passage forward sur son ensemble, si bien qu’une seule lecture des poids du modèle couvre des milliers de tokens et que le matériel est généralement limité par le débit des opérations de multiplication. Lors du décodage classique, la réponse est produite un token à la fois. Chaque token nécessite son propre passage forward, qui relit les poids du modèle ainsi que le cache KV qui s’allonge. Le matériel est donc généralement limité par la bande passante mémoire. Des techniques comme le speculative decoding réduisent cet écart sans le supprimer. Anthropic facture la sortie cinq fois plus cher que l’entrée dans l’ensemble de son catalogue actuel, de Haiku 5.5 à Fable 5.1.

La mise en cache du prompt réduit-elle le coût des tokens de sortie ?

Non. La mise en cache du prompt s’applique uniquement à l’entrée. Au 27 octobre 2026, la lecture du cache coûte 0.1x le tarif d’entrée de base sur la plupart des modèles, 0.05x sur Opus 5.5 et Sonnet 5.5, et 0.025x sur Fable 5.1. 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 complet à chaque appel, quel que soit l’effet du cache. C’est pourquoi la mise en cache modifie la structure de votre facture autant que son montant : lorsque la part liée à l’entrée s’effondre, la sortie devient la part sur laquelle 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 réellement produits par le modèle. max_tokens est donc une limite maximale, et non une quantité réservée. Ce paramètre reste important, car c’est la seule limite stricte qui empêche une réponse de continuer indéfiniment. 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 avertissement.

Comment trouver 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 calculez les totaux sur une semaine. Au-dessus de 5 tokens d’entrée pour 1 token de sortie, votre coût se situe dans le prompt : mettez sa partie stable en cache 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 les étapes qui en génèrent le plus vers un modèle moins cher ou vers la Batch API.