Claude API Cost Per Million Tokens Explained
Claude API Cost Per Million Tokens Explained
Anthropic prices the Claude API by tokens, not by requests or by the hour, and the number you see on the pricing page is almost always expressed as a rate per million tokens. That rate is split into two separate prices: one for input tokens (what you send to the model) and one for output tokens (what the model generates back). Output tokens cost noticeably more than input tokens for every Claude model, because generation is more compute-intensive than reading a prompt.
So when you see something like "$3 / $15 per million tokens," the first number is the input price and the second is the output price. To get your actual bill, you multiply your real token volume by those rates and divide by 1,000,000 — the "per million" unit is just a convenient denominator, not a minimum purchase or a flat fee.
Input Tokens vs Output Tokens
Every Claude API call has two cost components:
- Input tokens: your system prompt, user message, conversation history, any documents or tool results you attach, and (for Claude's extended thinking or tool use) the reasoning context.
- Output tokens: the text, JSON, or tool calls Claude generates in response.
Long conversation history is the most common place costs get out of hand, because every prior turn gets re-sent as input tokens on each new request. A chatbot with a 20-turn conversation can easily cost more per message at turn 20 than at turn 1, even though the user's new message is the same size.
Typical Price Ranges by Model Tier
Anthropic offers several model tiers, each with a different cost/capability tradeoff. Exact figures change over time, so always confirm current numbers on Anthropic's official pricing page before budgeting — but the relative structure looks like this:
| Tier | Relative input cost | Relative output cost | Best for | |---|---|---|---| | Haiku (fastest, cheapest) | Lowest | Lowest | Classification, extraction, high-volume simple tasks | | Sonnet (balanced) | Mid | Mid | Most production app features, chat, summarization | | Opus (most capable) | Highest | Highest | Complex reasoning, long-form analysis, hard edge cases |
Output tokens are typically priced 4–5x higher than input tokens within the same tier. This is consistent across all three tiers, so the choice that moves your bill the most is usually which model tier you pick, not fine-tuning prompt length.
How to Calculate Your Actual Cost
The formula is simple:
cost = (input_tokens / 1,000,000 × input_rate) + (output_tokens / 1,000,000 × output_rate)
Example with illustrative rates of $3 input / $15 output per million tokens:
function estimateCost(inputTokens, outputTokens, inputRate = 3, outputRate = 15) {
const inputCost = (inputTokens / 1_000_000) * inputRate;
const outputCost = (outputTokens / 1_000_000) * outputRate;
return inputCost + outputCost;
}
// A chat reply with 1,200 input tokens and 300 output tokens
console.log(estimateCost(1200, 300)); // ~0.0081 (under a cent per call)
Most individual API calls cost fractions of a cent. The number that actually matters is monthly volume: thousands of users sending dozens of messages a day adds up fast, and that's where per-million pricing becomes a real line item instead of a rounding error.
What Actually Drives Your Bill Up
- Conversation history re-sent every turn — trim or summarize old messages instead of keeping the full transcript.
- Large system prompts sent on every call — if your system prompt is 2,000 tokens and you make 10,000 calls a day, that's 20 million input tokens a day just from the prompt itself.
- Using a top-tier model for simple tasks — classification, tagging, or short extraction jobs often work fine on a cheaper tier.
- Verbose output formats — asking for unnecessary explanation alongside structured output (like JSON) inflates output tokens, which are the expensive side of the equation.
- Repeated identical context — sending the same large document in every request instead of caching it.
Making Costs Predictable Across a Team
Raw per-token billing is efficient but hard to forecast when multiple developers or team members are hitting the API independently — nobody knows the bill until it arrives. If you're giving a team shared access to Claude, it helps to put a layer in front of raw usage that gives you per-key metering and visibility before the invoice shows up.
This is one of the problems SubToAPI solves: it turns your existing Claude access into a standard HTTPS API with individual sub_live_... application keys per developer or service, streaming and tool use support, and usage metadata on every response so you can see token consumption per key instead of guessing. Instead of unpredictable per-million-token billing spread across a team, you get flat per-seat pricing — Solo at €9, Team at €19/seat, Scale at €49/seat — with a free trial at signup. Check the full breakdown on /pricing.
If you're integrating for the first time, the quickstart walks through creating a key and sending your first request, and the messages docs and streaming docs cover the request shapes you'll actually use day to day.
curl https://api.subtoapi.app/v1/messages \
-H "Authorization: Bearer $SUBTOAPI_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-sonnet",
"max_tokens": 300,
"messages": [{"role": "user", "content": "Summarize this ticket in 2 sentences."}]
}'
The response includes usage metadata so you can log token counts per call and reconcile them against your plan without needing to parse a separate billing dashboard.
Questions
Does "per million tokens" mean I'm billed in batches of a million? No. It's just the unit the rate is quoted in. You're billed for your exact token usage; the per-million figure is there so the numbers aren't awkward decimals like $0.000003 per token.
Why is output more expensive than input? Generating tokens requires the model to run inference for each new token sequentially, while reading input can be processed more efficiently in parallel. This computational difference is reflected directly in the pricing split.
Can I reduce cost without switching models? Yes — trimming conversation history, shortening system prompts, caching repeated context, and avoiding unnecessary verbose output all reduce token counts without touching which model tier you use.