Accueil → Aide

Utilisation des tokens absente d'une réponse en streaming

Le streaming omet l'usage par défaut. Définissez stream_options: {"include_usage": true} et les décomptes arrivent dans un fragment supplémentaire tout à la fin, après le dernier fragment de contenu.

Ce que vous voyez

usage is null on every chunk of a streamed response
Token counts appear for non-streamed calls and never for streamed ones
Your own cost tracking reads zero while the provider bills normally

Pourquoi cela arrive

L'utilisation ne peut être connue qu'une fois la génération terminée, il n'y a donc rien à mettre dans les premiers fragments. Plutôt que d'envoyer une valeur provisoire, l'API laisse le champ à null et ajoute un fragment final quand les chiffres existent.

Ce fragment final a un tableau choices vide. Le code qui arrête de lire dès qu'il voit finish_reason, ou qui ignore les fragments sans delta, jette justement le fragment dont il a besoin.

Toutes les implémentations compatibles OpenAI ne prennent pas en charge l'option. Là où elle manque, vous pouvez soit estimer localement, soit lire les chiffres qui font foi dans le journal du fournisseur.

Vérifiez si c'est bien la cause

Demandez l'usage et regardez la dernière ligne du flux :

curl -N 'YOUR_BASE_URL/chat/completions' \
  -H 'Authorization: Bearer YOUR_KEY' -H 'Content-Type: application/json' \
  -d '{"model":"MODEL","stream":true,"stream_options":{"include_usage":true},"messages":[{"role":"user","content":"hi"}]}' | tail -3

Le fragment qui précède [DONE] doit contenir un objet usage rempli avec un tableau choices vide.

Comment le corriger

Demandez l'option explicitementAjoutez stream_options avec include_usage à true. Sans cela, le champ reste à null quelle que soit la manière dont vous lisez le flux.
Continuez à lire jusqu'à [DONE]Ne sortez pas de la boucle sur finish_reason. Le fragment d'usage arrive après.
Considérez les décomptes locaux comme des estimationsLes tokeniseurs côté client s'écartent de ce que facture le fournisseur, surtout avec l'entrée en cache. Rapprochez-vous du journal du fournisseur, pas de votre propre compteur.

APICLAN enregistre chaque appel côté serveur, avec ou sans streaming : horodatage, modèle, entrée, sortie, lecture de cache, écriture en cache et montant exact débité. Ce journal est le chiffre de référence pour les rapprochements.

Voir aussi

Unexpected token '<' lors d'un appel à une API compatible OpenAI 401 invalid API key : quand la clé semble correcte mais échoue quand même

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.