—last turn alone
—vs flat cost
—with window/cache
Cost accelerates with turn count
The per-turn input keeps climbing as history piles up, so the cumulative cost curve bends upward — doubling the turns more than doubles the bill.
| At turn | This turn costs | Cumulative |
|---|
You pay for the history on every turn
A language model is stateless: it remembers nothing between API calls, so to continue a conversation your application re-sends the entire transcript — system prompt, every past user message and every past reply — as the input of each new request. That means the input grows one exchange at a time, and the cost of the whole conversation grows with roughly the square of the number of turns, not linearly. The last turn of a long chat is the most expensive one because it carries the most history, and the fixed system prompt is billed once per turn on top. Three levers bring it back down: a sliding window that keeps only recent turns (cost becomes linear, at the cost of memory), prompt caching that bills the repeated prefix at a steep discount, and summarising old turns into a short recap. Compare a single window on the context window cost calculator, size the caching win on the prompt caching savings calculator, and cost a full assistant on the chatbot cost calculator.
How this calculator works
Free multi-turn chat cost calculator — because every turn re-sends the whole history, LLM conversation cost grows with the square of turn count, not linearly.
Frequently asked questions
Why does a long chat cost more than the number of messages suggests?
Because an LLM has no memory between calls, every turn must re-send the entire prior conversation as input so the model can see the context. On turn ten the model re-reads all nine previous exchanges plus the system prompt, on turn twenty it re-reads nineteen, and so on. Input tokens therefore grow with each turn, and the cumulative cost of the whole conversation grows with roughly the square of the turn count rather than linearly. A hundred-turn conversation can cost far more than a hundred single-turn calls of the same message size — the history is what you pay for, over and over.
How can I stop conversation cost from exploding?
Three levers. A sliding window keeps only the last few turns of history, capping the input at a fixed size so cost grows linearly instead of quadratically — at the price of the model forgetting older context. Prompt caching lets the provider store the repeated prefix and bill it at a large discount on every reuse, which is ideal when the early history and system prompt stay identical. And summarisation compresses old turns into a short recap so you keep the meaning without keeping the tokens. This calculator shows the naive full-history cost alongside a windowed and a cached version so you can see which lever pays off for your conversation length.
Does a bigger system prompt matter in a long conversation?
Yes, more than people expect, because the system prompt is re-sent on every single turn. A 2,000-token system prompt in a fifty-turn conversation is billed fifty times — a hundred thousand input tokens before any user message is counted. In long or high-volume chats the fixed system prompt is often a larger share of the bill than the actual conversation, which is exactly the kind of cost that prompt caching is designed to remove. The calculator separates the system-prompt contribution so you can see whether trimming or caching it is worthwhile.