Claude API Cost Calculator

Ten dollars fifty for a million and a half tokens

Processing 1,000,000 input tokens and 500,000 output tokens through Claude Sonnet costs $10.50 — $3.00 for input and $7.50 for output.

Output is 2.5 times the input cost here despite being half the volume, which reflects the standard pricing structure across providers: generating tokens is sequential and expensive, reading them is parallel and cheap.

The model tiers

Claude is offered in tiers that trade capability against cost, and choosing correctly is usually worth more than any prompt optimisation:

Haiku — the fastest and cheapest. Well suited to classification, extraction, routing, simple summarisation and high-volume tasks where the work is mechanical.

Sonnet — the balanced tier, and the default choice for most production work: coding, analysis, content generation and agentic tasks.

Opus — the most capable and most expensive. Reserved for genuinely difficult reasoning, complex multi-step agentic work, and tasks where quality differences justify the cost.

The cost gap between tiers is large — frequently an order of magnitude between the smallest and largest. An application sending every request to the top tier is usually spending several times what it needs to.

The two discounts that matter

Prompt caching allows a prefix of the prompt to be cached and reused across requests. Writing to the cache costs slightly more than standard input; reading from it costs a fraction of the standard rate.

This is transformative for applications with a large fixed context — a long system prompt, a codebase, a policy document, a set of few-shot examples. Where the cached portion dominates the prompt, the effective input cost can fall by most of its value. Caches have a limited lifetime, so the benefit depends on request frequency against that window.

Batch processing offers approximately 50% off both input and output for requests submitted asynchronously and returned within a processing window. Suited to anything not needing an immediate response: bulk document processing, dataset generation, offline evaluation, periodic enrichment jobs.

The two combine — a batched request against a cached prefix is substantially cheaper than a naive synchronous call.

Estimating token volume

The heuristics for English are roughly 1 token ≈ 4 characters or 0.75 words. A page of text is about 500 tokens; a medium source file perhaps 2,000–5,000.

Two cautions for Indian applications: text in Devanagari and other Indic scripts tokenises far less efficiently than English, often at two to four times the token count for equivalent content. And long-context requests — sending an entire document or codebase — consume input tokens at a rate that makes caching essential rather than optional.

Reading the result

The subtotal before batch line shows the cost at standard synchronous rates, which makes the batch saving explicit.

Treat the figure as a unit cost to be multiplied by volume. The useful exercise is cost per user action, then per user per month, then across your expected user base — that is where an apparently trivial per-call cost becomes a line item worth managing.

Rates change over time and generally downward. Verify current pricing before committing to a projection, and re-check periodically, since a model that was uneconomic at launch may not be a year later.

Common mistakes

Using the top tier for everything. Routing by difficulty is the largest single saving.

Not caching a large fixed prefix. It is the most under-used optimisation.

Paying synchronous rates for asynchronous work. Batch halves it.

Estimating Indic-script volume at English rates. It can be several times higher.

Projecting from a single call. Measure across realistic traffic before committing.