Anthropic API pricing in 2026: every rate and the real cost levers

The full Anthropic API rate card

Everything below is from Anthropic's own detailed pricing docs, checked 13 August 2026. Prices are USD per million tokens, which the docs shorten to MTok. Worth knowing before you copy a URL: platform.claude.com/docs/en/pricing is a redirect stub that returns nothing, and the real page lives under /about-claude/pricing.

Three things in that table are worth pausing on.

Five generations of Opus are priced identically. Opus 5, 4.8, 4.7, 4.6 and 4.5 all bill at $5 in and $25 out. If you are still pinned to an older Opus for reproducibility reasons, you are not saving money by doing it, and the retired Opus 4.1 is the only one still on the old $15 and $75 card.

Sonnet got cheaper, which is not how this usually goes. Sonnet 5 lands at $2 and $10 against $3 and $15 for Sonnet 4.6, a 33% cut on both meters in one generation. For most production traffic that makes Sonnet 5 the obvious default rather than a compromise.

Fable 5 at $10 and $50 is exactly 2x Opus 5. Hold that number, because it comes back when we get to fast mode.

If you want the Claude models capability context alongside the prices, the specs line up like this:

Anthropic's own steer is to start with Claude Opus 5 for complex agentic and enterprise work, and treat Fable 5 as the reach model rather than the default.

Work out your own number

The rate card only becomes a budget once you put your own traffic through it. Set the four inputs below and it will price the month, then show you what the same workload would have cost with no caching and no batch discount.

Move the cache slider and watch the total, because that single control moves the number more than switching model tier does on an input-heavy workload. That is the whole argument of the next section.

Four multipliers decide the bill, not the rate card

Anthropic publishes the per-token price prominently and the multipliers quietly. The multipliers are where the money is.

Prompt caching is the biggest lever, and the short cache is the cheap one

Caching has three prices, all expressed against the model's base input rate: a 5-minute cache write costs 1.25x, a 1-hour write costs 2x, and a cache hit costs 0.1x. Setting the breakpoints themselves is free. The steady-state ceiling is a 90% discount on whatever prefix you reuse.

The break-even arithmetic is where people get it wrong. Each hit saves 0.9x base, so the 5-minute cache pays for itself after one hit, and the 1-hour cache needs two. Write plus one hit on the 1-hour TTL comes to 2.1x against 2.0x for not caching at all, so a single-reuse prompt on the long cache is actively worse than leaving caching off.

Anthropic's own guidance is to stay on the 5-minute cache for anything hit more often than every five minutes, because it refreshes at no additional charge every time it is used. The 1-hour TTL is for gaps: a long side-agent run, or a user who might not reply for ten minutes.

Then there is the part almost nobody prices in. Cache reads are not deducted from your input-token rate limit. Anthropic's worked example is a 2,000,000 ITPM limit paired with an 80% cache hit rate, which lets you push 10,000,000 input tokens per minute through the same account. Caching is not only a discount, it is a 5x throughput multiplier, and it is the cheapest way to raise a ceiling you would otherwise have to ask Anthropic to raise for you.

Haiku 3.5 is the documented exception where cache reads do count against the limit, and it is retired on the first-party API anyway.

This is also why headline token counts mislead so badly. One practitioner correcting someone else's cost estimate on Hacker News put it about as clearly as it can be put:

"i run a bunch of claude agents for automation and like 85% of input tokens end up being cached reads -which cost 1/10th of the sticker price. so your $200k number is probably closer to $25-30k in real cost"

tcbrah, Hacker News

Several people running production automation independently report 85% to 92% of input tokens landing as cache reads. If you price a token count at the sticker rate, you are overstating a real bill by roughly 10x.

The minimum cacheable prefix is the trap underneath all of this, because it does not move in a straight line across generations:

Opus 5 caches from 512 tokens. Haiku 4.5 needs eight times that. Fall short of the threshold and caching silently does nothing and returns no error at all, which is why a bill that refuses to drop after you "turned caching on" is usually a prompt that never qualified. Both cache_creation_input_tokens and cache_read_input_tokens sitting at zero in the response is the tell.

A few more mechanics that quietly cost money. The read lookback window is 20 blocks, so a turn that adds more than 20 pushes past your last write and misses. Modifying tool definitions invalidates the whole cache, since the hierarchy runs tools, then system, then messages. And the documented common mistake is putting the breakpoint on a block containing a timestamp or the incoming user message, which buys a fresh write on every single request and never a read.

Batch is a flat 50%, with two exclusions

The Batch API takes 50% off both input and output on every active model, and it stacks with caching. Limits are 100,000 requests or 256 MB per batch, most complete inside an hour, and the hard ceiling is 24 hours.

The billing detail I like: errored, canceled and expired requests are not billed at all. Only successes cost money, which makes batch a low-risk place to run a large classification job. The counterweight is that a batch can go slightly over your configured spend limit because of concurrent processing, so it is not a hard budget fence.

Two exclusions to plan around: batch does not combine with fast mode, and the discount does not apply to Managed Agents sessions.

Effort is the default nobody sets

output_config.effort controls how many tokens Claude spends, and it covers text, tool calls and thinking alike, so it bites even with thinking off. The levels run low, medium, high, xhigh, max.

The default is high on every model Anthropic documents, which is the second-most-expensive setting on the ladder. Anthropic's own best-practice list opens with "set effort explicitly", which is a polite way of saying the out-of-the-box behaviour is not the one you want for volume work.

No token multipliers are published for any level, so treat it as a dial to measure rather than a discount to claim. The one comparable anchor Anthropic gives is that Sonnet 5 at medium is roughly Sonnet 4.6 at high. Two gotchas worth knowing before you start tuning: changing effort between requests invalidates your cached prefixes, so the two levers fight each other, and on Opus 5 lower effort shortens the thinking rather than the visible answer, so prompt for length if brevity is what you were after.

The two surcharges hiding in the docs

Fast mode gives Opus 5 and Opus 4.8 up to 2.5x faster output at $10 in and $50 out, exactly 2x standard. Which produces the buying decision I find most interesting on the whole card: fast-mode Opus 5 costs precisely what standard Fable 5 costs. If you are reaching for fast mode on a hard problem, price the more capable model at the same rate before you commit. Fast mode is first-party API only, and it does not combine with batch.

The quieter one is data residency. Pinning inference to the US with inference_geo: "us" on Claude 4.6 and later applies a 1.1x multiplier to every token category, and that includes cache writes and cache reads, not just input and output. It is a 10% surcharge on the entire bill, it is easy to set once and forget, and global routing is the standard-priced default.

Stack all four levers and the spread on a single model is larger than the gap between model tiers:

The tool and agent costs that sit on top of tokens

Server-side tools bill separately, and these are the lines that surprise people reading a monthly invoice for the first time.

That last row deserves a note, because it moves the right way. Opus 4.7 carried the worst fixed tool overhead on the card at 675 tokens with auto, and Opus 5 cut it to 286. If you run a heavy MCP tools setup with thousands of small requests, that is a real 58% reduction in a cost line you never chose.

Anthropic publishes its own worked example for a one-hour Managed Agents coding session on Opus 5, and it is the cleanest caching-ROI figure available anywhere in the docs:

That is a 25.5% cut on the whole session from caching alone, on a workload where output dominates and caching can only touch part of the bill.

There is no long-context premium anymore

This is the change most third-party pricing posts still get wrong. Claude 4.6 and later include the full 1M token window at standard rates, and the pricing docs state it plainly: a 900k-token request is billed at the same per-token rate as a 9k-token request. Caching and batch discounts apply across the whole window too.

Two caveats stop that being a free lunch. Anthropic itself warns that accuracy and recall degrade as the token count grows, so paying for a fuller window can buy you worse answers. And overflow behaviour changed on Claude 4.5 and later: if input plus max_tokens exceeds the window, the request is accepted and stops with stop_reason: "model_context_window_exceeded" partway through, and you pay for whatever was generated before it stopped.

How Anthropic API pricing compares

Here is the honest head-to-head against the other frontier APIs, taken from each vendor's own page on the same day. If you want the deeper version, we have a full three API providers breakdown and a direct Anthropic API comparison.

Read that table fairly and Claude is not the cheapest anything. Gemini pricing undercuts Sonnet 5 on input at the mid tier, grok-4.6 is dramatically cheaper on output at the frontier, and deepseek-v4-flash is in a different universe entirely at $0.14 and $0.28, with a cache-hit rate roughly 50x below its miss rate.

Where Anthropic wins is predictability, and at scale that is worth real money.

Start with long context, since no current Claude model carries a premium there while Gemini 3 publishes a doubled rate above 200K. xAI's version is harsher: its long-context rate applies to all tokens in the request once the prompt crosses 200K, so one token over repriced the entire call. Then compare the shape of the bill. Anthropic meters four things, input, output, cache writes and cache reads, plus a small set of named tools. xAI's page lists five separately-billed token types, six priced tool invocations, file and collection storage, egress, and a $0.05 fee on any request that trips its usage guidelines. Batch parity is a myth too: OpenAI discounts every meter, Google keeps context caching at standard rates on its Pro batch rows, and xAI gives grok-4.6 no batch discount at all.

There is also a wrinkle worth knowing if you are shopping on price. DeepSeek publishes an Anthropic-format base URL at api.deepseek.com/anthropic, which means the SDK you wrote against Claude will mostly point at a much cheaper model with a base-URL change. DeepSeek's own page also warns of a significant price increase coming, so treat today's figure as a floor rather than a plan. If the bill is the reason you are reading this, our Claude alternatives roundup is the place to start. The cheaper open-weight end is covered separately, with per-model rates for Qwen and for Kimi K2.5.

Why public Claude API bills disagree by four orders of magnitude

If you go looking for what the Anthropic API costs in practice, you will find numbers that cannot possibly describe the same product. It is worth understanding why before you take any of them as a benchmark.

Almost all the loud figures come from developers pointing a coding agent at a raw API key. Here is the shape of that:

"At API prices it's incredibly easy to burn cash. I ran through my Claude Max 20x last week and had $100 credit from when Anthropic banned OpenClaw, so I decided to use it to get some chores done. Three hours of very light work on Sonnet cost me $55."

u/satansxlittlexhelper, Reddit

Note that is Sonnet, not Opus, and he describes the work as very light. In the same thread another developer reports a peak burn rate of about $50 an hour, and someone else lost $300 in twelve hours to an unattended overnight run. One commenter names the specific failure mode that produces those numbers: $20 gone to an agent stuck in a tool-call loop, which is an argument for spend caps and loop guards rather than an argument about price.

Now the same API, in the same thread, doing bounded work:

"I'm using the API to relevance classify hundreds of articles a day. Been running for 2 ish weeks, I think I'm almost up to $2 in cost"

u/warnerbr0, Reddit

Fifty dollars an hour and two dollars a fortnight, on the same rate card. The variable is not the price list, it is whether the workload has a bounded prompt and a bounded output or an agent loop that decides for itself how much to spend. Almost every "the Claude API is expensive" claim you will read is measuring the second thing, and almost every server-side product integration is the first.

The practical read: ignore per-hour figures entirely when you are sizing a normal integration, and model your own token shape instead.

What the bill looks like at three real workloads

Sticker prices do not tell you much until you attach them to a job. All three below use published rates and the arithmetic is the same one the widget above runs.

A support triage classifier. 50,000 tickets a month, Haiku 4.5, a 3,000-token instruction block reused on every call plus 400 tokens of ticket text, and 150 tokens out. That is $170 of input and $37.50 of output, so about $208 a month, or four-tenths of a cent per ticket. Batch it and halve that again. This is the workload where the raw API really is close to free, and it is why per-ticket pricing on a support tool has to earn its keep against something this cheap.

A coding agent. 2,000 sessions a month on Opus 5, 60,000 input tokens per session with 80% served from cache, and 12,000 output tokens. Input works out to $120 uncached plus $48 in cache reads, and output at $600. Call it $768, with output carrying 78% of it. On agentic workloads the output meter is the bill, so caching helps far less than the discount headline suggests. That is the single most useful thing to know before you model an agent's cost.

A one-off document backfill. 200,000 documents, Sonnet 5, 5,000 tokens in and 800 out, run through batch. Input is $1,000 at the $1 batch rate and output is $800 at $5, so $1,800 for the run against $3,600 synchronously. Nothing to cache here, since every document is different, and this is exactly the shape batch exists for.

The pattern across all three: caching wins on input-heavy repetitive traffic, batch wins on anything you can wait for, and neither does much for an agent that writes a lot. Match the lever to the shape of the work.

Where the raw API stops being the cheap option

Everything above prices tokens. It does not price the system around them, and that is where most build-versus-buy arithmetic quietly falls over.

I have spent the last few years putting AI agents on live support queues, and the pattern in sales calls is consistent enough to be predictable. A prospect runs a test afternoon, watches the call counter move, and cannot extrapolate. One email-security company on Freshdesk, scaling toward 20,000 tickets a year, burned 200 API calls in a single test day and came back worried entirely about what 9,000 interactions a month would do to the number, not about whether the answers were any good. Another operator heading toward 150,000 tickets a month did the arithmetic at roughly 20 cents a ticket, landed on about $30,000 a month, and stalled there.

Neither of those is a token-price problem. Both are unit problems. Nobody forecasts in millions of tokens, and a per-token meter turns every capacity conversation into a modelling exercise rather than a budget line.

The counterargument is real too, and I would rather quote it than talk around it:

"We switched to a system that is working well at half the cost. But long term we will just build our own, which is so possible now with AI. I think you have a decent system for now, but we are probably too large of a customer for this."

A Canadian firearms-accessories brand running Zendesk with 2,190 synced docs, from eesel's internal sales-call records

That reader is right that the models are now cheap enough to make building tempting, and frameworks like AgentKit have made the scaffolding cheaper too. What the token bill leaves out is retrieval over your help centre, a helpdesk integration that survives an API change, escalation rules, a way to test against historical tickets before you point it at customers, and someone whose job it is to keep all of it running. We have watched a confident-sounding bot give wrong answers in production, which is why every rollout now gets simulated against real past tickets first, and simulation is not a line item you can buy on a rate card.

The honest version of the trade: if you need a classifier or a summariser, build it on the API and enjoy a bill measured in cents. If you need something answering customers, price the AI agent cost end to end, including the AI hallucinations risk and the maintenance nobody budgets for.

Then compare that against cost per resolution on something already built. Our chatbot cost breakdown works through the same arithmetic, and the AI helpdesk software roundup covers what you would be comparing against.

A last practical note on governance, since it is the thing people ask about after their first surprising invoice. Spend caps run $500 on Start, $1,000 on Build, and $200,000 on Scale, with Custom removing the cap entirely. Tiers are assigned on usage history rather than purchased, and new organisations can start in an Evaluation tier below the published limits. Hitting the cap pauses usage until the next calendar month, which works the same way as OpenAI rate limits if you have hit those before.

Console's usage page exposes your cache hit rate directly, which is the number to look at first, and it is worth instrumenting properly with LLM tracking tools if the bill matters. One structural note for anyone comparing routes: on the enterprise plan, seats are $20 a month each plus usage at these same API rates, so this rate card is the enterprise usage bill. That is a different calculation from Claude Pro, where a flat subscription absorbs the usage instead.

Try eesel for support automation

If the reason you are pricing the Anthropic API is a support queue, the unit is the thing to fix before the rate. eesel charges $0.40 per ticket with no seats and no platform fee, which is a number you can put in a forecast without modelling token counts per conversation. It plugs into Zendesk, Freshdesk or Gorgias in a few minutes, trains on your existing help centre and past tickets, and simulates against your ticket history before it ever replies to a customer, so you see the projected resolution rate and cost before going live.

You still get the per-action visibility a raw API build would make you construct yourself, which is usually the first thing teams miss when they estimate the build. Free to try, and you can see the projected numbers before you commit to any of it.