Claude API Cost Per Conversation Calculator
How to Calculate Claude API Cost Per Conversation
The Claude API charges per token, not per conversation, so there's no fixed "cost per chat" — it depends on how many tokens go in and out, and how long the conversation runs. To calculate it, you multiply the input tokens by the input price, the output tokens by the output price, and then add those together for every turn in the conversation, because each new message resends the growing conversation history as context.
The short version of the formula is:
cost_per_turn = (input_tokens * input_price_per_token) + (output_tokens * output_price_per_token)
cost_per_conversation = sum(cost_per_turn) for every turn in the session
The tricky part isn't the math — it's estimating input_tokens correctly, because it grows with every back-and-forth. Below is a practical way to build your own calculator, plus a worked example and a reusable snippet.
Why Cost Per Conversation Isn't a Fixed Number
Three variables move the number around:
- Conversation length — a 2-turn support chat costs far less than a 15-turn debugging session.
- Context accumulation — Claude sees the full conversation history on every call, so turn 10's input includes everything said in turns 1–9.
- System prompts and tool definitions — if you're using tool use, the tool schema is sent as input tokens on every single request, even if the model doesn't call a tool.
This is why "average cost per conversation" is a range, not a single figure, and why any calculator needs assumptions baked in before it spits out a number.
Step 1: Estimate Tokens Per Message
As a rough rule of thumb, 1 token is about 4 characters of English text, or roughly 0.75 words. So a 100-word user message is roughly 130–140 tokens. For planning purposes:
- Short chat message: 20–60 tokens
- Paragraph-length message: 150–300 tokens
- Claude's response (typical chat): 100–400 tokens
- Claude's response (long-form, code, or structured output): 500–2000+ tokens
Step 2: Account for Context Accumulation
If a conversation has n turns and each turn adds roughly t tokens of new content (user message + assistant reply), the input tokens for turn k are approximately:
input_tokens(k) ≈ system_prompt_tokens + (k - 1) * t
That means turn 1 is cheap, but turn 10 of a long thread is sending nearly 9x more input context than turn 1, even though the user only typed one new sentence.
Step 3: Apply Your Pricing Tier
Anthropic publishes different per-model prices for input and output tokens, and they differ meaningfully between model tiers (fast/cheap models vs. the most capable ones). Always check the current rate card before running real numbers — don't hardcode last year's pricing into a spreadsheet. Once you have the per-token rates, plug them into the formula from the top of this article.
Worked Example
Assume (for illustration only — check live pricing before using real figures):
- System prompt: 300 tokens
- Average new content per turn: 150 tokens
- Average output per turn: 250 tokens
- Input price: $3 / million tokens
- Output price: $15 / million tokens
- Conversation length: 6 turns
| Turn | Input tokens | Output tokens | Input cost | Output cost | |------|--------------|----------------|------------|--------------| | 1 | 450 | 250 | $0.00135 | $0.00375 | | 2 | 600 | 250 | $0.0018 | $0.00375 | | 3 | 750 | 250 | $0.00225 | $0.00375 | | 4 | 900 | 250 | $0.0027 | $0.00375 | | 5 | 1050 | 250 | $0.00315 | $0.00375 | | 6 | 1200 | 250 | $0.0036 | $0.00375 |
Total: roughly $0.038 for the full 6-turn conversation. Double the conversation length and the cost more than doubles, because of context accumulation — this is the part most back-of-envelope estimates miss.
A Simple JavaScript Calculator
function conversationCost({
turns,
systemPromptTokens,
newTokensPerTurn,
outputTokensPerTurn,
inputPricePerMillion,
outputPricePerMillion,
}) {
let total = 0;
for (let k = 1; k <= turns; k++) {
const inputTokens = systemPromptTokens + (k - 1) * newTokensPerTurn;
const inputCost = (inputTokens / 1_000_000) * inputPricePerMillion;
const outputCost = (outputTokensPerTurn / 1_000_000) * outputPricePerMillion;
total += inputCost + outputCost;
}
return total;
}
console.log(
conversationCost({
turns: 6,
systemPromptTokens: 300,
newTokensPerTurn: 150,
outputTokensPerTurn: 250,
inputPricePerMillion: 3,
outputPricePerMillion: 15,
}).toFixed(5)
);
Swap in your model's actual pricing and typical turn count, and you have a reusable estimator for budgeting before you ship a feature.
Tracking Real Costs Instead of Estimates
Estimates are useful for planning, but once a feature is live, you want actual per-request usage, not projections. If you're calling Claude through SubToAPI, every response includes usage metadata so you can see real input/output token counts per request and reconcile them against the estimate above. That's useful for catching cases where context grew faster than expected — long tool-use chains or verbose system prompts, for example.
curl https://api.subtoapi.app/v1/messages \
-H "Authorization: Bearer $SUBTOAPI_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-sonnet-4",
"max_tokens": 500,
"messages": [{"role": "user", "content": "Summarize this ticket."}]
}'
The response includes token usage per call, which you can feed back into your calculator to tighten your per-conversation estimates over time. See the messages docs for the full response shape, or the quickstart if you're setting up your first API key. Pricing for SubToAPI itself — separate from the underlying model token costs — is on the pricing page.
questions
Does the Claude API charge per conversation or per request? Per request. Each API call is priced individually based on input and output tokens for that call. "Cost per conversation" is a derived metric you calculate by summing the cost of every turn in a session.
Why does the same conversation get more expensive as it goes on? Because Claude needs the full conversation history as context on every new request. Turn 10 resends everything said in turns 1–9 as input tokens, even though only one new message was typed, so cost grows with conversation length.
How accurate are token estimates based on word count? Reasonably accurate for planning (roughly 0.75 words per token in English), but not exact. For billing-sensitive decisions, use actual token counts from your API response's usage metadata rather than estimates.