Skip to content

Conversation Token Tracker

Paste a transcript and see what the whole conversation was billed, including the history re-sent on every single turn.

This is an estimate, not a token count. The re-billing arithmetic is exact; the token count of each message is estimated. Paste a transcript with User: and Assistant: prefixes, or separate the turns with blank lines and they will be read as alternating. For the exact figure, read the usage object on any completion response — prompt_tokens and completion_tokens are what you are billed on, they cost nothing to read, and they settle the question for the model you are actually calling.
Tokens billed for this conversation
545

$0.0031 at the rates above. The transcript itself is only about 312 tokens — history is re-sent on every turn, so you paid for it 1.4 times over.

Messages parsed
5
Assistant replies (billable requests)
2
Tokens of text in the transcript
312
Billed input tokens
426
Billed output tokens
119
Re-billing multiple
1.37×
Input cost
$0.0013
Output cost
$0.0018
Cost per reply
$0.0015

Turn by turn

Reply 1
175 in + 53 out
Reply 2
251 in + 66 out
What this assumes: Every request carries the system prompt plus every earlier message, which is how a stateless chat API works: the model has no memory, so the history is the memory and you pay to re-send it each turn. No caching is assumed — with prompt caching the repeated prefix is billed at the cache-read rate instead, which changes the input figure substantially. Reasoning tokens are not included, and on a reasoning model they can exceed the visible reply.

Why a long chat costs more than the sum of its messages

A chat API is stateless. Each turn is a fresh request that contains the entire conversation so far, so the tenth reply is billed for nine previous exchanges plus the system prompt plus the new question. The cost of a conversation is therefore quadratic in its length, not linear: doubling the number of turns roughly quadruples the input tokens.

That is the number the re-billing multiple above is trying to make visible. A twenty-turn support conversation whose transcript is 4,000 tokens of text can bill 40,000 input tokens or more. Nothing is wrong when that happens — it is how the protocol works — but it does mean that a per-conversation budget derived from the length of the transcript will be wrong by an order of magnitude.

Two levers change it. Prompt caching bills the stable prefix at a fraction of the normal input rate, which is close to free money for a long-running conversation with a fixed system prompt, as long as the prefix really is byte-identical every turn. Trimming or summarising history caps the growth: keep the system prompt, keep the last few exchanges verbatim, and replace the middle with a short summary. Both are worth modelling before you assume you need a larger context window, because a larger window makes the problem more expensive rather than less.

Conversation Token Tracker · Multigrid