A chat request is stateless. The model retains nothing between calls, so if you want turn 6 to know what was said in turn 2, you send turn 2 again — along with turns 1, 3, 4 and 5, and the system prompt, every single time. This is the mechanic that breaks chat budgets, and it breaks them quietly, because the per-request cost looks fine in development where nobody has a long conversation.
Take the defaults in the calculator above: an 800-token system prompt, 60-token user messages, 220-token replies, six turns, on Claude Haiku 4.5 at $1.00/$5.00 per million tokens.
| Turn | History carried | Input tokens | Input cost |
|---|---|---|---|
| 1 | 0 | 800 + 60 = 860 | $0.00086 |
| 2 | 280 | 1,140 | $0.00114 |
| 3 | 560 | 1,420 | $0.00142 |
| 4 | 840 | 1,700 | $0.00170 |
| 5 | 1,120 | 1,980 | $0.00198 |
| 6 | 1,400 | 2,260 | $0.00226 |
Each completed turn adds 60 + 220 = 280 tokens to the history that every subsequent turn must carry. Turn 6 sends 2.63× the input of turn 1. Add output — 220 tokens at $5.00 per million is $0.0011 on every turn regardless — and turn 1 costs $0.00196 while turn 6 costs $0.00336, a 1.7× increase in total request cost.
Across the whole conversation: 9,360 input tokens at $1.00 per million is $0.00936, plus 1,320 output tokens at $5.00 per million is $0.0066. $0.01596 per conversation, or $319.20 a month at 20,000 conversations.
The growth is quadratic, and that is the whole problem
The general form is worth memorising, because it tells you what happens when your product succeeds and people start using it properly. Total input tokens over n turns equals n × (system + user) + (user + assistant) × n(n−1)/2. The first term grows linearly. The second term is the killer.
Run the same numbers at 20 turns instead of 6: 20 × 860 = 17,200, plus 280 × 190 = 53,200, giving 70,400 input tokens and 4,400 output tokens. That is $0.0704 + $0.022 = $0.0924 a conversation. Turns went up 3.3×; cost went up 5.8×. At 20,000 conversations a month you are looking at $1,848 rather than $319.20, and nothing about your product changed except that users found it useful enough to keep talking.
Notice also where the money sits in the six-turn case. The 800-token system prompt is resent on all six turns: 4,800 tokens, which is 51% of all input and $0.0048 of the $0.01596 — 30% of the entire bill, spent on instructions the user never sees. At 20,000 conversations that is $96 a month for one block of text.
Three ways to contain it, and what each one costs you
Sliding window. Keep the last N turns verbatim and drop everything older. With a window of 4, the six-turn conversation carries 3,920 tokens of history instead of 4,200 — a saving of 280 tokens, $5.60 a month across 20,000 conversations. Effectively nothing. This is the finding people miss: at short conversation lengths a window does almost no work, because there is nothing to truncate. Its value appears exactly where the quadratic term does. At 20 turns the window cuts input from 70,400 to 36,800 tokens, taking the monthly bill from $1,848 to $1,176 — $672 saved.
The trade-off is amnesia with a hard edge. The model will confidently contradict something it said nine turns ago, and it will ask again for a detail the user already supplied. That is tolerable for transactional support chat, where each turn is nearly self-contained. It is unacceptable for anything where the user is building something up over the conversation — a booking with accumulating constraints, a debugging session, an interview.
Rolling summary plus a window. Compress everything older than the window into a short paragraph and prepend it. The calculator models the summary at roughly 35% of one assistant reply, about 77 tokens. At 20 turns with a window of 4, that gives 37,955 input tokens against the window's 36,800 — very slightly more expensive, and the point is that the extra 3% buys back continuity. Detail degrades gracefully rather than vanishing: the model still knows the user is on the enterprise plan and already tried restarting, even if it no longer has the exact wording.
The costs are real but different in kind. You pay for the summarisation calls themselves, which the table above does not include — budget one extra generation every few turns, and use a cheap model for it; Gemini 2.5 Flash-Lite at $0.10/$0.40 or Ministral 3 at $0.10/$0.10 will summarise four turns of chat perfectly well. You also introduce a compounding error: summaries of summaries lose specifics, and a wrong detail baked into a summary at turn 8 will still be wrong at turn 30 with no way for the model to notice.
Cache the fixed prefix. This is the one with no quality cost at all, and it is why the cache hit rate field sits next to the model selector. Claude Haiku 4.5 charges $0.10 per million for cached input against $1.00 standard. At a 90% hit rate on the 800-token system prompt, the 4,800 tokens per conversation cost 480 × $1.00 ÷ 1,000,000 + 4,320 × $0.10 ÷ 1,000,000 = $0.000912 instead of $0.0048. That is $77.76 a month back out of $319.20 — a quarter of the bill — for a change that is purely structural.
The condition is that the cached block must be byte-identical and first in the prompt. Inject the user's name, their plan tier, or the current timestamp above the system prompt and the hit rate collapses to zero without any error appearing anywhere. Put variable content after the fixed block, always. The prompt caching savings calculator works out the hit rate you need before the write premium eats the gain.
Use all three. They are independent: caching cuts the fixed cost, the window cuts the quadratic term, and the summary buys back the quality the window destroyed. What you should not do is pick a strategy from a blog post and never measure — set the average turns field to what your analytics actually report rather than what you hoped for, because that single number moves the answer more than the model choice does. Cut your LLM bill covers the rest of the levers, and if your history is long enough that you are wondering whether to retrieve from it rather than resend it, the context window cost calculator prices that crossover.
Prices used by this calculator were last verified on 15 August 2026 from the vendors' own pricing pages. See the full price index for every figure and its source, the change log for what has moved recently, and the methodology for how the index is maintained and where its limits are.