Claude API Pricing in 2026: The Real 30-Day Bill

Quick answer (July 2026): The Claude API bills per token, not per seat. As of July 2026 the working rates are Claude Haiku 4.5 at $1 input / $5 output per million tokens, Claude Sonnet 5 at $2 / $10 (introductory, through August 31, 2026, then $3 / $15), and Claude Opus 4.8 at $5 / $25. Output is priced 5x input on every model, so on generative workloads output usually drives 45 to 63 percent of the bill. The three levers that actually move the number are prompt caching (cache reads at 10 percent of input), the Batch API (50 percent off input and output), and model tiering. Below is what that looks like as a real 30-day bill.

The Claude API is Anthropic's pay-as-you-go developer platform for the Claude model family. Every teardown of it online reprints the same price table and stops. That is the least useful part. The rate card tells you the unit price; it does not tell you what you will actually pay, because your bill is decided by two things the table hides: your output-to-input ratio, and how much of your input repeats. This post runs the arithmetic on three real workload shapes and shows which lever cuts each one.

All prices below are pulled from Anthropic's official model pricing page and claude.com/pricing, verified July 2026. Nothing here is invented.

The 2026 rate card, ranked by output price

The only column that matters for budgeting is output. Here are the current first-party rates, cheapest model first.

Two things to read off this before you model anything:

• Opus 4.8 output at $25 is 2.5x Sonnet 5's $10 and 5x Haiku 4.5's $5. The model you pick for the response is the single biggest cost decision you make.
• Sonnet 5's $2 / $10 is introductory. On September 1, 2026 it becomes $3 / $15, a 50 percent step-up on both sides. If you are budgeting past Q3, budget the higher number.

Cohort 1: a support bot on Haiku 4.5

A small SaaS runs a support and FAQ assistant. Answers are short, context is a trimmed knowledge snippet. Anthropic's own worked example puts this at about $37.00 per 10,000 tickets on Haiku 4.5, roughly 3,700 tokens per conversation, most of it input.

Scale that to 30,000 support conversations a month:

Effective cost: about $3.70 per 1,000 resolved tickets. This is the one workload where input dominates, because the answers are tiny. It is the exception that sets up the rule for the next two: the moment your model starts writing a lot, the math inverts.

Cohort 2: a production agent on Sonnet 5

An internal coding or agent tool runs 5,000 tasks a month. Each call carries about 18,000 input tokens (repo context, tool definitions, history) and generates about 3,000 output tokens.

Effective cost: $0.066 per run. Output is already 45 percent of the bill on only 14 percent of the tokens.

Now turn on prompt caching. Say 14,000 of those 18,000 input tokens are a static system prompt plus tool schemas reused on every call. Cache reads bill at $0.20 per million (10 percent of input):

Caching cut a repetitive-context workload by about 38 percent and did not touch output at all. That is the tell: caching only helps the input side, so it helps most exactly when input is large and repeated, and does nothing for a workload that is output-heavy.

One caveat worth pricing in: on September 1, 2026 the same uncached workload moves from $330 to about $495 a month when Sonnet 5 hits $3 / $15. The caching lever is what keeps that step-up from landing at full force.

Cohort 3: an Opus 4.8 reasoning workload

A product runs 2,000 high-value complex calls a month on Opus 4.8, each about 12,000 input and 4,000 output tokens.

Effective cost: $0.16 per call, and output is now 63 percent of the bill. On Opus, the response is the product and the response is where the money goes.

The lever here is not caching, it is tiering. Audit the 2,000 calls; in most products roughly 70 percent do not need frontier reasoning. Route those 1,400 calls to Sonnet 5 instead:

Moving the easy 70 percent down a tier saves about $134 a month and leaves Opus doing only the work that genuinely needs it. Model tiering is the highest-leverage structural change on any Opus-heavy bill.

The tokenizer gotcha nobody prices in

Here is the number the other pricing posts miss. Sonnet 5 at $2 / $10 looks 33 percent cheaper than Sonnet 4.6 at $3 / $15. It is not, on the same text.

Per Anthropic's pricing notes, Opus 4.7 and later, Sonnet 5, and Fable 5 use a newer tokenizer that produces about 30 percent more tokens for the same text. Sonnet 4.6 and earlier use the previous tokenizer. So an identical prompt is counted differently:

The real saving is about 13 percent, not 33 percent, once the token inflation is applied. Sonnet 5 is still cheaper, and usually smarter per dollar, but budget it against actual token counts from your own logs, never against the sticker delta between two tokenizers.

The three levers, in order of impact

Before you switch providers to chase a lower sticker, exhaust the levers on the one you have. For reference, the OpenAI API rate card and Google's Gemini API pricing sit in the same range, and the same three moves apply to all of them.

1. Model tiering. Send the response to the cheapest model that clears the quality bar. Opus output is 5x Haiku's. This is the biggest structural saving on any generative workload.
2. Prompt caching. Cache reads bill at 10 percent of input. A 5-minute cache write costs 1.25x input and pays for itself after a single read; a 1-hour write costs 2x and pays off after two. Cache anything static and repeated: system prompts, tool schemas, long documents.
3. Batch API. For anything that does not need an immediate answer (classification, backfills, evals), the Batch API is 50 percent off input and output, and it stacks with caching.

A fourth, quieter one: server-side web search is $10 per 1,000 searches on top of tokens, so meter it. New accounts also get a small block of free credits to test with, but there is no perpetual free tier; the API is postpaid per token.

If you want to plug your own token counts into these rates, our token cost calculator runs the same arithmetic across models. For the neighboring rate cards, see our OpenAI API pricing teardown and the OpenRouter pricing breakdown for when an aggregator undercuts first-party rates.

A note on the subscription-versus-API debate that comes up constantly on r/ClaudeAI: for a single heavy interactive user, a flat Pro or Max seat can be far cheaper than metered API calls. The API wins when you are building a product that serves many users or runs unattended, where per-token billing scales with usage instead of paying for idle seats. They solve different problems; price both against your actual pattern.

Math check: output is 5x input on every Claude model, so on generative workloads it drives 45 to 63 percent of the bill on 15 to 25 percent of the tokens. Budget by output tokens, tier the model down wherever quality allows, and cache everything static. The rate card is the floor; your ratios decide the bill.