Token counts are usage, not quality

The numbers are a meter

A response can include counts of prompt tokens and completion tokens. Those counts are usage: how much text the API metered for this call. They are not a grade, and they are not a count of facts. A long completion can be padded. A short one can be the whole answer.

The finish reason, when you have it, is what says the reply stopped early. The completion count does not say that by itself. Do not infer a length limit from a small number.

The prompt count is not the user’s question

Prompt tokens can include the system text, retrieved chunks, and the user message. The count does not split them. You cannot point at the number and say how much of it was the user’s words. If you need that split, the log has to have stored the parts, and you cite those parts.

Do not paste the prompt into the ticket to explain the count when the prompt may hold secrets. The counts and the request id are enough for a usage note.

What to file

File the request id, prompt tokens, and completion tokens, labeled as usage. File the finish reason separately if you are discussing whether the reply is complete. Do not file “high quality” or “too short to trust” from the counts alone.

Worked case: a long reply treated as the better one

Response r-610 used 40 completion tokens and says the lab closes at 8, matching the hours page. Response r-611 used 400 completion tokens and adds three paragraphs that are not on the page. A draft keeps r-611 because it is longer.

The note records both usage pairs as meters. The sentence about closing time cites the hours page and r-610 only as a reply that matched it. Length is not the reason. r-611’s extra paragraphs are not promoted because they cost more tokens.

r-610  completion tokens: 40  agrees with the hours page
r-611  completion tokens: 400  extra paragraphs not on the page
write: both counts are usage
closing time: from the hours page
not: the longer reply is the better record