LLM Conversation Cost Calculator

How the math works

The Messages and Chat Completions APIs are stateless: they carry no memory of a conversation between requests. Each turn's input is the system prompt plus every prior message plus the new one^{⁠[Claude context windows] ⁠[OpenAI conversation state]} — and every one of those resent tokens is billed again, in full, at the input price. With system prompt tokens S, an average user message U, an average assistant reply A, and turn number n:

historyBefore(n) = S + (n - 1) * (U + A)   // system prompt + n-1 completed turns
input(n)         = historyBefore(n) + U    // + this turn's new message
output(n)        = A

cumulativeInput(N) = sum of input(n) for n = 1..N
                   = N*(S + U) + (U + A) * N*(N - 1) / 2

Turn 1 has no history yet (input(1) = S + U); every turn after that adds exactly U + A new tokens to what gets resent. That constant per-turn increment is why the cumulative total grows quadratically, not linearly: turn 2's extra tokens get billed again on turns 3 through N, turn 3's again on turns 4 through N, and so on.

Take the site's own reference case — a system prompt, average user message, and average assistant reply of 250 tokens each, 20 turns. input(n) works out to exactly 500n tokens, so the cumulative total is 500 · 20 · 21 / 2 = 105,000 input tokens — while the conversation itself, at the final turn, only actually contains 10,000 tokens of context. That's a 10.5× history multiplier: you paid to process ten and a half times more input than the conversation contains. At Claude Sonnet 5's verified $2/MTok input price, that's $0.21 of input cost alone for a conversation whose final state is 10,000 tokens^{⁠[Claude pricing]}. Load this exact scenario with the "Load reference example" button above the calculator.

Prompt caching discounts the resend — it doesn't eliminate it

With caching on, this tool assumes a cache breakpoint is extended on every request (the common pattern: mark the end of the growing prefix each turn). Turn 1's whole input is new — a cache write. From turn 2 on, the previous turn's entire input was already cached and comes back as a cheap cache read; only the newest slice — the previous reply plus this turn's new message — is written fresh:

turn 1:    cacheWrite = input(1),               cacheRead = 0
turn n≥2:  cacheRead  = input(n-1),               cacheWrite = U + A

cost(n) = cacheRead * inputPrice * cacheReadMultiplier
        + cacheWrite * inputPrice * cacheWriteMultiplier
        + output(n) * outputPrice

Verified 2026-09-25 against the provider pricing pages^{⁠[Claude pricing]⁠[OpenAI pricing]}: Anthropic prices a 5-minute cache write at 1.25× base input and a cache read at 0.1× (0.05× on Claude Opus 5.5, its deeper discount). OpenAI's prompt caching has no separate write charge — the first occurrence of a prefix is just standard input price (1.0×) — and a cache read is a flat 0.1× across the current GPT-6 family. Output tokens are never cached or discounted by any provider; caching only ever touches input.

What this deliberately simplifies

The model is exact arithmetic given its inputs, but the inputs themselves are simplifications:

• Every turn is assumed the same size. Real conversations vary — a clarifying one-word reply followed by a long code dump will not average out cleanly over a short conversation. Use averages you trust for your product, or run the calculator per phase of a longer conversation.
• Caching assumes a hit on every eligible later turn. A real cache expires (5 minutes of inactivity on Anthropic's default duration) and is scoped to backend infrastructure — a request that lands on a different server, or a gap between turns longer than the cache window, pays full price instead. Bursty, human-paced chat usually hits; a slow batch job usually doesn't.
• Thinking/reasoning tokens are not modeled. Extended thinking and reasoning tokens are billed as output on every current provider, but they don't have a stable average the way a chat reply does — add them to the assistant-reply figure if your use case enables thinking, or expect the real output bill to run higher than this tool shows.
• Tool definitions and tool-call/result content aren't modeled separately. If your conversation uses function calling, the tool schemas and every tool_use/tool_result block are additional input tokens on top of the system prompt and messages — fold an estimate of them into the system prompt or per-turn figures.
• No context-window ceiling. A long enough conversation eventually needs summarization or a sliding window to fit the model's context window at all — this tool shows what the naive full-resend approach costs, not when it stops being possible.

When this calculator is wrong

Cases where the numbers here will visibly diverge from a real bill:

• Sliding-window or summarized history. If your application trims old turns or summarizes them instead of resending the full transcript, the resend growth this tool models does not apply past the trim point — model only the window size that's actually sent.
• RAG or retrieved context. Retrieved documents injected per turn add input tokens that don't come from the conversation history and typically are not cacheable the same way a stable system prompt is (different retrieval results each turn) — add them to the per-turn user-message figure, but don't expect them to benefit from caching.
• Batch or async processing. Batch APIs discount both input and output roughly 50% in exchange for non-realtime turnaround — this tool models realtime, synchronous pricing only.
• Multi-turn tool-calling loops within a single user turn. An agent that calls tools several times before producing one user-visible reply sends multiple requests for what this tool counts as one turn — model each tool round as its own turn if you need that granularity.

Further reading

• Anthropic API pricing — the authoritative, current source for Claude model prices and prompt-caching multipliers.
• OpenAI API pricing — the authoritative, current source for GPT model prices and cached-input pricing.
• LLM API Integration Patterns for Backend Engineers — token budgets, sliding-window truncation, and the cost circuit breaker this calculator's numbers feed into.

About this tool

This calculator is part of BackendBytes' reference tools collection. The math lives in an open, unit-tested source file — if you disagree with a constant, the methodology above tells you exactly which input to change. Model prices are a typed constant dated 2026-09-25; prices change, so check the provider's own pricing page before budgeting off this tool, or enter custom prices directly.