Calculer la consommation de tokens de l’API Responses : entrée, sortie, cache et raisonnement

Après avoir raccourci un prompt, vérifiez les économies à partir de usage de chaque réponse et du coût total de la tâche. Une réponse courte peut s’accompagner d’une consommation importante liée au raisonnement, et la poursuite d’une conversation peut entraîner une nouvelle prise en compte de l’historique. Pour maîtriser le budget, distinguez le volume de tokens, les catégories tarifaires et le nombre d’appels nécessaires pour obtenir le résultat.

Quatre compteurs et leur imbrication

Dans l’exemple de l’objet usage, OpenAI présente les entrées, les sorties et le détail de ces deux compteurs. Interprétez-les ainsi :

• input_tokens — volume total de tokens d’entrée pour cet appel, y compris le contexte utilisé pour poursuivre une conversation.
• input_tokens_details.cached_tokens — partie de l’entrée traitée à partir du cache. Elle est déjà incluse dans input_tokens.
• output_tokens — volume total de tokens générés, raisonnement compris.
• output_tokens_details.reasoning_tokens — partie de la sortie consacrée au raisonnement.

Les tokens de raisonnement sont déjà inclus dans output_tokens ; ne les ajoutez pas une seconde fois à la sortie. OpenAI les facture au tarif des tokens de sortie. De même, ajouter cached_tokens aux entrées revient à compter deux fois la même partie de la requête. Pour le volume total, utilisez total_tokens ou la somme input_tokens + output_tokens.

Coût : ventilez les entrées par catégorie

La page des tarifs actuelle présente séparément les entrées standard, les entrées mises en cache, l’écriture du cache et les sorties. Choisissez les tarifs correspondant au modèle effectivement utilisé, au mode de traitement et à la longueur de contexte applicable. Conservez les valeurs exactes dans une configuration de calcul versionnée.

Un point important de la documentation actuelle sur la mise en cache : pour GPT-5.6 et les modèles plus récents, input_tokens_details.cache_write_tokens est pris en compte. Si votre méthode prévoit une facturation distincte de l’écriture du cache, soustrayez cette catégorie des entrées standard et appliquez-lui son tarif.

I = input_tokens
C = input_tokens_details.cached_tokens
W = input_tokens_details.cache_write_tokens
O = output_tokens

ordinary_input = I - C - W
cost = ((I - C - W) * P_input
        + C * P_cached
        + W * P_write
        + O * P_output) / 1_000_000

Les prix sont exprimés ici par million de tokens ; pour une méthode sans catégorie distincte d’écriture, utilisez W = 0. La formule couvre les catégories de tokens indiquées. Ajoutez les outils payants sur des lignes distinctes, conformément à leurs conditions tarifaires.

Exemple hypothétique : 4 000 tokens d’entrée, dont 3 000 mis en cache et 500 liés à l’écriture du cache, et 1 000 tokens de sortie, dont 600 de raisonnement. On obtient 500 tokens d’entrée standard et 5 000 tokens au total. La sortie est facturée à hauteur de 1 000 tokens ; la valeur de 600 est conservée à des fins de diagnostic.

La poursuite d’une conversation consomme de nouveau des tokens d’entrée

Lorsqu’elle gère manuellement l’historique, l’application transmet les messages précédents avec la nouvelle entrée. Les messages inclus dans la requête suivante deviennent à nouveau du contexte d’entrée. Par conséquent, mesurer uniquement le dernier message de l’utilisateur ne tient pas compte de la consommation liée à l’historique.

Avec previous_response_id, l’application transmet une référence à la réponse précédente, et l’API relie le contexte. Selon les règles de facturation des continuations, les tokens d’entrée précédents de la chaîne sont de nouveau facturés comme des tokens d’entrée. Le cache peut modifier la catégorie tarifaire d’une partie de ces entrées ; vérifiez les éventuels succès de mise en cache dans cached_tokens de chaque réponse.

Comment vérifier le résultat d’une optimisation

1. Conservez un échantillon de référence. Comparez des tâches identiques, avec le même modèle, le même critère de réussite et des conversations de longueur comparable.
2. Consignez chaque appel. Enregistrez les identifiants de réponse et de tâche, le modèle, les paramètres de raisonnement, le statut, la latence et l’intégralité de usage. Conservez la version du prompt et de la configuration tarifaire.
3. Faites la somme des coûts de la tâche. Incluez tous ses appels et les réponses obtenues lors de nouvelles tentatives. L’indicateur principal est le coût d’une tâche menée à bien.
4. Distinguez les causes des variations. Suivez les entrées standard, la lecture et l’écriture du cache, les sorties et la part du raisonnement. Pour calculer le taux de mise en cache agrégé, divisez la somme de C par la somme de I.
5. Vérifiez la qualité et la distribution de la queue. Comparez le p95, le nombre de tentatives et le taux de réussite des tâches, en plus du coût moyen.

Le paramètre max_output_tokens limite la génération, y compris le raisonnement. Lorsque la limite est atteinte, la réponse peut recevoir le statut incomplete, y compris sans texte visible mais avec une consommation de tokens. Prenez ces réponses en compte lors de l’évaluation des économies : l’optimisation a atteint son objectif lorsque des tâches comparables se terminent avec succès pour un coût total inférieur.