Claude API Cost Per Million Tokens: 2025 Rates

If you're pricing out a Claude integration, the number that matters is cost per million tokens — it's the unit Anthropic bills on, and it's the fastest way to compare models or forecast your monthly spend. Claude's models are tiered, and the gap between the cheapest and most expensive tier is roughly 60x, so picking the right model for each task matters far more than shaving prompt length.

As a rough guide (always confirm current numbers on Anthropic's pricing page, since rates do shift): the Haiku-class models sit at well under a dollar per million input tokens and a few dollars per million output tokens, the Sonnet-class mid-tier models run a few dollars per million input and roughly 5x that for output, and the Opus-class flagship models are the most expensive, often an order of magnitude above Sonnet. Output tokens are consistently priced higher than input tokens across every tier — usually 4–5x — because generation is the expensive part of inference.

Why input and output are priced differently

Token cost isn't symmetric because the work isn't symmetric. Processing input (the prompt, context, tool results, system message) is largely a single forward pass. Generating output requires the model to produce tokens one at a time, which is why providers charge more per output token. This has a practical implication: if your use case involves long context windows (large documents, long chat histories, RAG retrieval) but short answers, your bill is dominated by input cost. If your use case generates long responses — code, reports, summaries — output cost dominates. Knowing which side of that split your workload falls on changes which optimizations actually move the needle.

How to estimate your monthly bill

The calculation is simple arithmetic once you know your token volume:

monthly_cost = (input_tokens / 1,000,000 × input_rate)
             + (output_tokens / 1,000,000 × output_rate)

A practical way to get real numbers instead of guesses: run a representative batch of requests through the model you're evaluating and look at the usage data returned with each response. Every Claude API response includes input and output token counts, so you can multiply by your actual traffic pattern instead of estimating from word counts (which are unreliable — token-to-word ratio varies with language, code, and formatting).

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 report in 3 bullets."}]
  }'

The response includes a usage object with input_tokens and output_tokens. Log that for every request in production and you'll have exact cost data within days, not estimates.

Model choice is the biggest lever

Before optimizing prompts, optimize model selection. A common pattern:

• Classification, routing, extraction, short chat replies → cheapest tier (Haiku-class). The quality difference versus a flagship model is often negligible for structured, low-ambiguity tasks.
• General chat, summarization, most coding tasks → mid tier (Sonnet-class). This is the default for most production apps — strong reasoning at a fraction of flagship cost.
• Complex multi-step reasoning, hard coding problems, high-stakes outputs → flagship tier (Opus-class), used selectively rather than as the default.

Routing requests by difficulty — even a simple heuristic based on prompt length or a cheap classifier call — can cut blended cost per million tokens by more than half without a noticeable quality drop for most users.

Levers that actually reduce cost per million tokens

1. Trim system prompts and context. Every token in your system prompt gets billed on every single request. A bloated 2,000-token system prompt sent on every chat turn adds up fast at scale.
2. Cap max_tokens intentionally. Output is the expensive side of the ledger. If your use case rarely needs more than 300 tokens of response, don't leave the limit at 4000.
3. Reduce redundant context. If you're resending full chat history every turn, consider summarizing older turns instead of sending them verbatim.
4. Batch where latency allows. Non-interactive workloads (nightly summarization, bulk classification) don't need real-time response and can often run on cheaper models with relaxed timing.
5. Stream only when needed. Streaming doesn't change the per-token price, but it improves perceived latency, which lets you comfortably use a cheaper, slightly slower model instead of over-paying for speed. See /docs/streaming.

Where SubToAPI fits

If you already have Claude access through a subscription and want to expose it as a proper HTTPS API for your product, SubToAPI turns that access into application API keys (sub_live_...) with the same /v1/messages interface, streaming, tool use, and per-key usage metadata — so you can see exactly how many input and output tokens each app, environment, or customer is consuming, broken down the same way Anthropic's own usage field reports it. That visibility is what makes model routing and cost-cutting decisions evidence-based instead of guesswork. Plans start at Solo for solo builders, with Team and Scale tiers adding seats and dashboards for teams tracking spend across multiple projects — see /pricing. There's a free trial at /signup, and /docs/quickstart gets you a working request in a few minutes.

questions

What's the actual cost difference between Claude models per million tokens? It depends on the model tier — cheapest tiers are priced in cents per million input tokens, mid-tier models run a few dollars, and flagship models can cost an order of magnitude more, with output tokens always priced 4–5x higher than input across every tier. Check the current official pricing page for exact figures since rates change.

How do I calculate my actual Claude API bill before committing to a plan? Run representative requests and read the usage field (input_tokens, output_tokens) in each response, then multiply by your real traffic volume and the per-million rate for your chosen model. This is far more accurate than estimating from character or word counts.

Does switching models mid-conversation save money? Yes — many production apps route simple messages (greetings, short lookups, classification) to a cheaper model and escalate only complex requests to a more expensive one. This blended-cost approach typically cuts spend significantly versus using one model for everything.