Guides / cost per conversation
What is cost per conversation?
Cost per conversation is the total model spend for one complete exchange, every call, retry, and tool step included. It's a sum, not an average. Culpa, a local-first LLM cost, margin, and forecast ledger, prices each call from a versioned price book and rolls it up to the conversation that spent it, so you can name the exchange behind a spike.
Why this happens
Most teams measure cost per call because that's what the provider hands them. A call is the wrong unit. A user asks one question and your system might make nine calls, two of them retries and three of them tool lookups. Billing lives at the call level, but the thing a customer experienced, and the thing your feature is worth, is the conversation. Until you sum to that boundary you can't say what an answer costs you.
What this usually looks like
- Your average cost per call looks healthy while your monthly bill keeps climbing, because call count is growing faster than you track.
- You can name your most expensive model but not your most expensive exchange, so optimisation work targets the wrong thing.
- Two features show similar call volumes and wildly different spend, and nobody can explain the gap from provider data alone.
- A support escalation about one user's session can't be costed, because the calls behind it were never grouped.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Dividing total monthly spend by total conversations to get an average. | Conversation cost is heavily skewed. A handful of runaway exchanges carry most of the spend, and an average hides exactly those. | Look at the distribution. Track the median and the 90th percentile separately, then read the top ten by absolute cost. |
| Counting only the calls your application code makes explicitly. | Retries, framework-internal calls, and tool steps are real spend that never appears in your own call sites. | Capture at the boundary where requests actually leave, so anything your stack sends gets counted whether you wrote it or not. |
| Treating a conversation as a fixed number of turns. | Cost grows faster than turn count, because most implementations resend the whole history on every turn. | Measure cumulative input tokens across the exchange. That growth curve, not turn count, is what drives the number. |
Run this check tonight
- Pick your ten most recent user sessions and count how many provider calls each one actually produced.
- For one of them, add the input and output tokens across every call in the exchange, including retries.
- Multiply each token total by the rate for the model that served it, then sum. That single number is your cost per conversation.
- Compare it to the revenue that session generated. If you can't, you have a margin blind spot, not a cost problem.
- Check whether resent history explains the growth. Divide turn five's input tokens by turn one's.
A five-turn exchange, priced call by call
Illustrative example
A support assistant on Claude Sonnet 5 at its introductory rate of $0.002 per 1k input and $0.010 per 1k output. The system prompt is 800 tokens and the full history goes back on every turn. Round numbers, so you can scale them.
About four cents for one exchange. The useful finding isn't the total, it's that input tokens grew 4.4 times while output didn't move. On this model that's where the money went.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $0.0416 | cost of a five-turn support exchange with history resent each turn | calculated | Sum of five turns at Claude Sonnet 5 introductory rates ($0.002 per 1k input, $0.010 per 1k output, price book effective 2026-07-02). Full arithmetic shown in the teardown. |
| 4.4x | growth in input tokens between turn one and turn five of that exchange | calculated | 4,400 input tokens at turn five divided by 1,000 at turn one, from the modelled token profile above. |
What a generic answer can’t know
A provider dashboard can tell you that you spent money on a model yesterday. It can't group nine calls into the one exchange a customer experienced, because it never saw your conversation boundary. That grouping needs request-level data, and request-level data means prompts and responses. Culpa keeps those on your infrastructure and counts the calls to run your plan, so you get conversation-level attribution without sending your prompts to anyone.
Questions founders ask next
What's the difference between cost per conversation and cost per call?
A call is one request to a provider. A conversation is every call behind one user exchange, including retries and tool steps. One conversation routinely costs five to ten times one call, and the gap is where unexplained spend hides.
Why does my cost per conversation grow with turn count?
Most implementations resend the entire history on every turn, so input tokens accumulate while output stays roughly constant. By turn five you're paying for turn one four extra times. Prompt caching or a rolling window both help.
Do retries count toward cost per conversation?
Yes. A retried call bills in full, and a failed call that produced tokens bills for those tokens. If your measurement excludes retries it will read lower than your invoice, and the gap grows exactly when something's going wrong.
How do I know which conversation was the expensive one?
You need a conversation identifier attached to every outbound call, then a sum grouped by it. Without that identifier the calls are unlinkable after the fact, which is why this has to be captured at request time rather than reconstructed later.
On your infrastructure
Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-01. Plain text version.