Multi-Turn Cost Simulator
Simulates a chat conversation turn by turn to show how re-sending the history makes the input bill grow with the square of the turn count.
Input is 76.8% of it. Turn 20 alone costs $0.04 — 4.4× turn 1.
- Input tokens billed, whole conversation
- 116,000
- Output tokens billed
- 7,000
- Tokens actually written by anyone
- 10,900
- Re-billing multiplier
- 11.3×
- Average cost per turn
- $0.02
- Cost of turn 1
- $0.0084
- Cost of turn 20
- $0.04
- With caching at 90% hit
- $0.18
- Saved by caching
- $0.27 (60.1%)
- At 1,000 conversations a month
- $453.00
- …the same, with caching
- $180.60
Estimated, not tokenized. Token figures here come from an approximation running in your browser: no tokenizer vocabulary is downloaded, because a real one is megabytes and nothing on this page fetches anything. It imitates how a byte-level BPE splits text — words, digit groups, punctuation runs, whitespace runs — but it has no merge table, so treat it as a planning number. The authoritative count is the usage object on a real API response.
Turn by turn
| Turn | Input tokens | This turn | Cumulative |
|---|---|---|---|
| 1 | 1,050 | $0.0084 | $0.0084 |
| 2 | 1,550 | $0.0099 | $0.02 |
| 3 | 2,050 | $0.01 | $0.03 |
| 4 | 2,550 | $0.01 | $0.04 |
| 7 | 4,050 | $0.02 | $0.09 |
| 9 | 5,050 | $0.02 | $0.13 |
| 11 | 6,050 | $0.02 | $0.17 |
| 13 | 7,050 | $0.03 | $0.23 |
| 16 | 8,550 | $0.03 | $0.31 |
| 18 | 9,550 | $0.03 | $0.38 |
| 19 | 10,050 | $0.04 | $0.42 |
| 20 | 10,550 | $0.04 | $0.45 |
Sampled rows — the arithmetic runs over all 20 turns.
Here is the whole thing in one line. On turn k you send the system prompt S, everything said in the previous k−1 turns, and the new user message U:
input(k) = S + (k−1)(U + A) + U
That is linear in k — each turn is a bit dearer than the last. The bill is the sum of it, and summing a linear term is where the shape changes:
total input = N(S + U) + (U + A) · N(N−1)/2
The N(N−1)/2 is a triangular number, so for large N the total approaches (U + A)·N²/2. Input cost grows with the square of the turn count. Double the length of a conversation and you roughly quadruple what its history costs you. Output stays honestly linear at N·A, which is why long chats drift from output-dominated to input-dominated as they go: the per-turn cost of the reply never changes, and the per-turn cost of the history climbs forever.
This is the arithmetic behind the support bot that was cheap in testing and expensive in production. The history term is N(N−1)/2: at ten turns that is 45 units, at forty turns it is 780. Four times the conversation, seventeen times the history. Nothing about the model changed.
Prompt caching attacks exactly the growing term, and only that term. The prefix that existed at the end of the previous turn is by definition unchanged, so it is cacheable; only the new user message is fresh. If a cache read costs a tenth of an ordinary input token, the quadratic does not go away — it gets multiplied by a small constant, which at forty turns is the difference between an affordable product and a memo about margins. Set the hit rate above to 0 and back to see the whole effect at once. Two things break it in practice: cache entries expire between turns while a user is thinking, and anything you insert near the top of the prompt — a timestamp, a retrieved document, a rotating instruction — invalidates the entire prefix behind it.