Anthropic charges for the Claude API per million tokens, split between input (what you send) and output (what the model writes back). As of May 2026 the lineup runs three tiers: Haiku 4.5 at $1 input and $5 output, Sonnet 4.6 at $3 and $15, and Opus 4.7 at $15 and $75. Pricing changes periodically, so anthropic.com/pricing is the source of truth for the live numbers.
This article is for anyone budgeting Claude API costs, comparing Anthropic to OpenAI, or trying to figure out whether your agent is going to cost $5 a day or $500.
The Pricing Table (May 2026)
Cost per million tokens, Claude family
The visual ratio is the point. Output bars are 5x longer than input bars within each tier. Sonnet is roughly 3x the cost of Haiku, Opus is 5x the cost of Sonnet.
Source: anthropic.com/pricing
Two patterns jump straight out of the chart. Output tokens cost roughly five times more than input tokens across every tier, which is industry standard and reflects the cost of generation being more expensive than reading. The second pattern is the step between tiers, and it is not uniform: Sonnet costs about 3x Haiku, and Opus costs about 5x Sonnet. Stack those steps and Opus output ends up roughly 15x Haiku output, which is the headline gap most cost models miss.
The 5x output-vs-input multiplier and the 3-to-5x cost-step between models means token-shape matters more than absolute volume. A workload that emits long responses on Opus will be 15-75x more expensive than the same workload on Haiku with shorter responses.
That math has a practical consequence. A team that picks Opus by default and lets responses run long will burn through budget an order of magnitude faster than a team on Sonnet with tighter output. The biggest cost decisions happen before you ever send a request, in the model you pick and the response length you ask for.
Prompt Caching, the Biggest Cost Lever
Prompt caching is the single largest discount Anthropic offers on inference, and most builders leave it on the table. When you mark a block of your prompt as cacheable, subsequent requests that reuse the same prefix read those tokens at roughly 10% of the normal input price, a 90% discount. Cache writes cost about 25% more than a normal input read, so the math pays off as soon as you reuse a cached prefix twice.
The cache lasts about five minutes from the last read, which sounds short but maps perfectly to the cadence of an interactive agent. Every time the agent makes another tool call within five minutes, the cache stays warm and the unchanging system prompt, tool definitions, and CLAUDE.md context all read at the discounted rate.
The practical setup is to put everything that does not change between turns at the top of the prompt and mark it cacheable. System instructions, your tool schemas, project context, conversation history up to the latest turn. The only thing outside the cache should be the newest user message and the freshest tool results.
You fundamentally have to design agents for prompt caching first, almost every feature touches on it somehow.
The implication for builders is that prompt structure dominates pricing strategy. An agent designed so that 90% of every request hits a cached prefix runs at roughly a third of the headline rate. An agent that rebuilds context every turn pays the full sticker price. Same model, same task, three times the bill.
Effective input cost, with and without caching
Relative to the model's normal input price. A cached prefix read costs roughly a tenth of the headline rate.
Source: Anthropic prompt caching docs
Two other levers are worth knowing about before we leave pricing mechanics. The Batch API discounts every model rate by 50% for workloads that can wait up to 24 hours, which is ideal for evals, bulk classification, and overnight processing. And the 1M context window on Sonnet 4.6 and Opus 4.6+ sits on a premium pricing tier above the standard rates, so check the live page if you plan to push past 200K tokens in a single request.
Anthropic vs OpenAI (Quick Compare)
The other half of the pricing question is how this stacks up against OpenAI, since most teams are picking between the two.
Per million tokens, Anthropic vs OpenAI
Approximate as of May 2026; both vendors update pricing periodically.
Source: Anthropic and OpenAI pricing pages
The shape of the comparison stays roughly the same even when specific dollar amounts shift.
GPT-4o-mini is unbeatable on raw cost for the bottom tier. At 15 cents per million input tokens, you can run a classifier on a million documents for under $200. Nothing in the Anthropic lineup competes on price alone for that workload. Sonnet 4.6 sits in the middle of the market and wins on coding quality, which is why most agentic IDEs default to it. Opus 4.7 and o1 are roughly in the same neighborhood on pricing for the hardest reasoning work, with the choice usually coming down to which model handles your specific domain better.
The honest summary is that no single provider wins across the whole range. The right answer is usually a portfolio: a cheap small model for routing and simple work, a mid-tier model for the main agent loop, and a premium model held in reserve for the hardest tasks.
When the Extra Spend Pays for Itself
The gap between Sonnet and Opus is real, but the gap that matters is the gap in tokens spent per shipped feature, not per individual request. An Opus run that solves a problem in one shot can be cheaper in total than three Sonnet attempts that each fail and burn context.
For pure throughput work like content moderation or document tagging, the cheaper tier wins on every axis. For agentic coding, where the cost of a wrong turn includes the human time spent reviewing the wrong code, the math flips. A senior engineer at $100 an hour costs more in twenty minutes than a full day of heavy Opus usage. If switching to the more expensive model removes a single round of revision, the API spend is already justified.
Start by just giving engineers as many tokens as possible.
The Anthropic team's internal stance is to err on the side of more tokens, because engineer time is more expensive than API spend. When Boris talks about giving engineers as many tokens as possible, he is making a cost argument disguised as a generosity argument. The math is the same either way: the bottleneck is usually attention and iteration, not dollars.
We're publishing a deep-dive series on how Anthropic engineers actually use the tools they ship.
Browse our Claude Code coverageWith the philosophy out of the way, here is what these numbers look like for the workloads most readers are actually running.
Budgeting in Practice
Rough cost ranges for common workloads, using Sonnet 4.6 unless noted. A casual one-hour Claude Code session with plan mode and around five file edits lands in the range of $0.30 to $1, assuming a healthy cache hit rate. A four-hour deep refactor session that touches a dozen files across several rounds of review lands somewhere between $3 and $8 on Sonnet, or $15 to $40 if you push the harder reasoning to Opus.
A production agent running 24/7 with prompt caching, doing background work like monitoring or triage, usually comes in at a few dollars per day for most use cases. The wide range exists because real costs depend mostly on cache hit rate and output length, both of which you control through prompt design. A team that ships with caching disabled and verbose response formats will see bills three to five times higher than a team that designs for cost from day one.
Two numbers are worth tracking from the first day of any project. Cache hit rate, which tells you whether your caching strategy is actually working, and average output tokens per request, which is the variable most teams underestimate. A 200-token system prompt and a 2000-token response is a normal-looking request that costs ten times what most builders expect.
The quadrant chart captures the most common mistake we see in budget reviews, which is treating model selection as a status decision rather than a fit decision.
Defaulting to Opus for every task. Sonnet 4.6 is near-Opus on most workloads at one-fifth the cost. The Claude Code team's own daily driver shifted to Sonnet 4.6 when it launched, with Opus reserved for the hardest reasoning. Match the model to the task.
The cleanest pattern most production teams converge on is a router. A small cheap model classifies the incoming request, then dispatches simple work to Haiku, standard work to Sonnet, and the rare hard problem to Opus. This pattern keeps bills predictable and reserves the premium models for the moments where they actually earn their keep.
Where to Check Current Numbers
The canonical source for Anthropic API pricing is anthropic.com/pricing. That page updates more often than this article will, and it carries the official numbers for every region, tier, and discount Anthropic offers. New accounts also get free Console credits, which is the cheapest way to test a model before committing real budget.
The structure of pricing is stable even when the dollar amounts shift. There will be an input rate, an output rate, a cache discount in the range of 90%, a batch discount in the range of 50%, and a step function between Haiku, Sonnet, and Opus tiers. Plan against those shapes, then plug in the live numbers when you build your cost model.
What This Means For You
- If you're a founder: Build a cost model for your top-3 expected workloads using these numbers; revisit quarterly as pricing shifts. Pick the model tier per workload, not per company.
- If you're changing careers: Start on Haiku for learning, $1 input and $5 output is cheap enough to experiment freely; graduate to Sonnet when you start building real features.
- If you're a student: Use Console free credits to learn Sonnet 4.6, the daily-driver model, without spending a dollar.
Match the model to the task, design for prompt caching, and most builders spend less than 30 dollars a month.
See the team's playbook