Claude Code API Pricing, Rate Limits, Usage Cost
What Claude Code actually costs: $13 per developer per active day, the full model price table, Start/Build/Scale rate limits, and why cache reads don’t count against your limit at all.
Advertisement

There are two completely separate ways to pay for Claude Code, and almost every confusing answer about its cost comes from mixing them up.
On a Pro, Max, Team or Enterprise subscription, you pay a flat monthly fee and draw against a seat allowance that resets on a rolling five-hour window and a weekly window. No per-token bill exists. On the Claude Console or a cloud provider, you pay per token, subject to rate limits and a monthly spend cap that depends on your usage tier.
Same CLI, entirely different economics. This covers both — what it costs in practice, the full API price table, how the rate limits actually work, and the levers that move your bill most.
All figures below come from Anthropic's own documentation, captured while writing.
What Claude Code Costs in Practice
Anthropic publishes real deployment numbers, which is unusual and worth quoting directly:
| Metric | Figure |
|---|---|
| Average cost per developer, per active day | ~$13 |
| Average cost per developer, per month | $150–250 |
| 90th percentile, per active day | Under $30 |
| Background token usage per session | Typically under $0.04 |
Those are API-billed figures across enterprise deployments. The distribution matters as much as the average: 90% of users stay under $30 on an active day, so budget for the tail rather than assuming everyone sits at $13.
Two things drive the variance more than anything else: leaving Opus as the default model, and long sessions that were never cleared. Both are covered below.
API Model Pricing
Per million tokens, in USD:
| Model | Input | Output | Cache write (5m) | Cache write (1h) | Cache read | Context |
|---|---|---|---|---|---|---|
| Claude Fable 5 | $10 | $50 | $12.50 | $20 | $1 | 1M |
| Claude Opus 5 | $5 | $25 | $6.25 | $10 | $0.50 | 1M |
| Claude Opus 4.8 / 4.7 / 4.6 | $5 | $25 | $6.25 | $10 | $0.50 | 1M |
| Claude Sonnet 5 | $2 | $10 | $2.50 | $4 | $0.20 | 1M |
| Claude Sonnet 4.6 | $3 | $15 | $3.75 | $6 | $0.30 | 1M |
| Claude Haiku 4.5 | $1 | $5 | $1.25 | $2 | $0.10 | 200K |
One piece of genuinely current news: Sonnet 5's $2/$10 pricing was announced as introductory through 31 August 2026, and the increase to $3/$15 scheduled for 1 September will not happen. That rate is now standard. If you deferred moving workloads onto Sonnet 5 because you expected a 50% price rise this week, that reason is gone — and at $2/$10 with a 1M context window it undercuts Sonnet 4.6 by a third while being the newer model.
The tokenizer trap
A per-token price comparison across model generations is misleading, and this is the detail most cost analyses miss.
Claude 4.7 and later use a newer tokenizer that produces roughly 30% more tokens for the same text. So moving from a 4.6-era model to a 4.7-era one at an identical headline rate is effectively a ~30% increase in cost per unit of actual work, not a wash. The exact figure depends on your content.
Judge cost per completed task, not cost per token. A model that needs fewer turns to get the answer right can be cheaper at a higher headline rate — and the reverse is also true.
Prompt Caching: The Single Biggest Lever
Caching multipliers are applied against the base input rate:
| Operation | Multiplier | Valid for |
|---|---|---|
| 5-minute cache write | 1.25× | 5 minutes |
| 1-hour cache write | 2× | 1 hour |
| Cache read | 0.1× | Same as the preceding write |
A cache hit costs 10% of the standard input price. The break-even is fast: the 5-minute cache pays for itself after one read, and the 1-hour cache after two.
Claude Code applies caching automatically, so most of this happens without configuration. Where it bites is when the cache misses — and there is an important asymmetry in cache lifetime:
- On a subscription: one hour.
- Once you are drawing on usage credits: five minutes.
- On an API key or cloud provider: five minutes by default.
That means your first message after a long break reprocesses your entire context at full price. On an API key, a fifteen-minute coffee break is enough to lose the cache on a large session.
Claude Code v2.1.251+ surfaces this directly — /usage shows a Prompt cache (main) line with request count, the share of input tokens served from cache, miss count, and whether the cache is warm right now. A request counts as a miss when it re-processed more than 5% and at least 2,000 tokens it could have read from cache.
Rate Limits: Start, Build, Scale, Custom
Limits are set per organisation, per model, and measured in requests per minute (RPM), input tokens per minute (ITPM) and output tokens per minute (OTPM). Organisations move up tiers automatically as usage history builds.
| Model | Start | Build | Scale | ||||||
|---|---|---|---|---|---|---|---|---|---|
| RPM | ITPM | OTPM | RPM | ITPM | OTPM | RPM | ITPM | OTPM | |
| Fable 5 | 1,000 | 500K | 100K | 2,000 | 1.5M | 300K | 4,000 | 4M | 800K |
| Opus 5 | 1,000 | 2M | 400K | 5,000 | 5M | 1M | 10,000 | 10M | 2M |
| Opus 4.x | 1,000 | 2M | 400K | 5,000 | 5M | 1M | 10,000 | 10M | 2M |
| Sonnet 5 | 1,000 | 2M | 400K | 5,000 | 5M | 1M | 10,000 | 10M | 2M |
| Haiku 4.5 | 1,000 | 2M | 400K | 5,000 | 5M | 1M | 10,000 | 10M | 2M |
Three things to notice.
Fable 5 is throttled far harder than everything else — 500K ITPM at Start against Opus 5's 2M, a quarter of the headroom. If you are building on Fable 5, capacity will constrain you long before it constrains an equivalent Opus 5 workload.
Opus 4.x share one combined bucket across 4.8, 4.7, 4.6 and 4.5, and Sonnet 4.x likewise across 4.6 and 4.5. Opus 5 and Sonnet 5 each have their own separate limits — so splitting traffic between Opus 5 and Opus 4.8 genuinely doubles your available headroom, while splitting between 4.8 and 4.7 does nothing at all.
Limits replenish continuously via a token bucket rather than resetting on the minute, so a burst can trip a limit even when your average sits well under it. New organisations may also start on an Evaluation tier below these published figures while account history builds.
Cache reads do not count toward your rate limit
This is the most valuable and least known fact on the page. For every current model, cache_read_input_tokens do not count toward ITPM. Only input_tokens and cache_creation_input_tokens do.
Anthropic's own worked example: with a 2,000,000 ITPM limit and an 80% cache hit rate, you can process 10,000,000 total input tokens per minute — 2M uncached plus 8M cached. Caching is not just a discount, it is a 5× throughput multiplier on the same tier.
Also worth knowing: max_tokens does not factor into OTPM at all, since output limits are evaluated against tokens actually generated. There is no rate-limit penalty for setting a generous max_tokens.
Spend Caps
| Tier | Monthly spend cap |
|---|---|
| Start | $500 |
| Build | $1,000 |
| Scale | $200,000 |
| Custom | No cap — arranged with your account team |
Hitting the cap pauses usage until 00:00 UTC on the first of the next month. The response is an HTTP 429 with error type rate_limit_error — but crucially with no retry-after header, so SDK auto-retries will fail repeatedly against it. Distinguish it by checking for error.details.error_code of enforced_spend_limit_reached. A limit you set yourself returns a 400 instead.
Sizing Rate Limits for a Team
Anthropic publishes per-user recommendations that scale down as headcount grows, because concurrency falls in larger organisations:
| Team size | TPM per user | RPM per user |
|---|---|---|
| 1–5 | 200K–300K | 5–7 |
| 5–20 | 100K–150K | 2.5–3.5 |
| 20–50 | 50K–75K | 1.25–1.75 |
| 50–100 | 25K–35K | 0.62–0.87 |
| 100–500 | 15K–20K | 0.37–0.47 |
| 500+ | 10K–15K | 0.25–0.35 |
At 200 users you would request about 20K TPM each, or 4 million TPM total. Limits apply at organisation level rather than per user, so individuals can temporarily exceed their share when colleagues are idle. Budget higher if you run live training sessions or anything with unusual concurrency.
One setup note: authenticating Claude Code with a Console account automatically creates a workspace named "Claude Code". You cannot issue API keys for it, but you can set a workspace rate limit on it — which is the clean way to stop Claude Code traffic from starving your production workloads.
What Server Tools Add
| Tool | Cost beyond tokens |
|---|---|
| Web search | $10 per 1,000 searches |
| Web fetch | Nothing — standard token cost only |
| Code execution | 1,550 free hours/month per org, then $0.05/hour per container (5-minute minimum; free when paired with web search or web fetch) |
| Managed Agents session runtime | $0.08 per session-hour, metered only while running |
Tool definitions themselves cost input tokens, and the overhead varies more than you would expect between models: the tool-use system prompt is 286 tokens on Opus 5 versus 675 on Opus 4.7 at tool_choice: auto. On a tool-heavy agent loop making thousands of calls, that difference compounds.
The Discounts and Premiums That Stack
- Batch API — 50% off input and output. Opus 5 drops to $2.50/$12.50, Sonnet 5 to $1/$5, Haiku 4.5 to $0.50/$2.50. For anything not latency-sensitive this is the largest single discount available, and it stacks with caching.
- Long context — no premium. Claude 4.6 and later include the full 1M window at standard rates. A 900K-token request bills at the same per-token rate as a 9K one. Several competitors charge a premium above 200K; Anthropic does not.
- Fast mode — $10/$50 on Opus 5 and Opus 4.8, double the standard rate, for up to 2.5× higher output speed. Not available with the Batch API.
- Data residency — 1.1× on every token category when you pin
inference_geo: "us". Global routing is the default and standard-priced.
Why a Long Session Costs More Than It Looks
Claude Code sends the full conversation with every request, and each tool call is another request carrying another batch of results. A one-line question in a session that has been open all day still draws usage for the whole conversation.
Named causes, in rough order of impact:
- Long context. The whole history rides along on every turn, at the cached rate if you are lucky and full price if not.
- Cache misses after a break longer than the cache lifetime.
- Agent teams. Roughly 7× more tokens than a standard session when teammates run in plan mode, because each maintains its own context window.
- Scheduled tasks and cross-session messages, which fire on their interval and send your full context even while you are idle.
- Compaction itself.
/compactreads the conversation it summarises, so compacting a large context is a large request./clearcosts nothing.
Cutting the Bill
- Clear between unrelated tasks. The highest-impact habit there is.
/renamefirst if you want to find the session again, then/resume. - Match the model to the job. Sonnet handles most coding well; reserve Opus for architecture and multi-step reasoning. Specify
model: haikufor simple subagents. - Lower the effort level with
/effortfor straightforward work. Thinking tokens bill as output tokens, and the default budget can run to tens of thousands per request. - Delegate verbose operations to subagents so test output and log processing stay in their context, not yours.
- Filter tool output with hooks. A
PreToolUsehook that greps a log forERRORturns tens of thousands of tokens into hundreds. - Move detail from CLAUDE.md into skills. CLAUDE.md loads at session start and stays in context whatever you are doing; skills load on demand. Aim to keep CLAUDE.md under 200 lines.
- Prefer CLI tools over MCP servers where both exist —
gh,aws,gcloudadd no per-tool listing overhead. Run/contextto see what is consuming space.
Tracking What You Spend
/usage is the main instrument. On a subscription it shows plan usage bars plus an attribution breakdown — what share of recent usage came from skills, subagents, plugins and individual MCP servers — and flags any behaviour accounting for 10% or more of usage. Press d or w to toggle 24 hours against 7 days. Figures are computed from local session history, so other devices are not included.
Two caveats worth knowing. The session cost figure is computed locally at list price, so if your organisation has contracted rates it will not match your invoice — an admin can fix that with the modelPricing managed setting, after which the total carries the note at your organization's configured rates. And on Max and Pro, the session dollar figure is not billing-relevant at all, since usage is included in the subscription.
For organisation-wide visibility: Teams and Enterprise use the spend report in org analytics, Console customers use the Console dashboard and Claude Code Analytics API, and cloud-provider customers need OpenTelemetry export — the only option that works on every setup and streams per-user metrics into your own stack in near real time.
Which Billing Model Should You Be On?
| If you... | Use |
|---|---|
| Code most days and want a predictable bill | Pro or Max subscription |
| Need spend to be zero on quiet months | API billing |
| Run automation, CI or scripted workloads | API billing — subscriptions meter on seat windows |
| Need per-user cost attribution | Console or Enterprise, plus OpenTelemetry |
| Need to cap what a team can spend | Console workspace spend limits |
| Run non-urgent bulk work | API + Batch — 50% off |
The Verdict
For an individual coding daily, a subscription is almost always cheaper and always more predictable — at $150–250 per developer per month on API billing, the flat plans price competitively against the average without exposing you to the tail.
For teams on the API, the two things that decide your bill are model selection and context hygiene, not tier or negotiation. Sonnet 5 at $2/$10 with a 1M context and no long-context premium is the strongest default the lineup has had, and the September price rise being cancelled makes that permanent rather than promotional.
And if you take one operational detail away, make it the caching one: cache reads cost 10% of input price and do not count against your rate limit at all. Tuning your cache hit rate is simultaneously the biggest cost lever and the biggest throughput lever available, and it is the one most teams never measure.
Keep Reading
More on Claude economics and tooling: Claude routines explained, how to use Claude Code for free, Claude pricing explained, Claude Max vs ChatGPT Pro, how to create a Claude skill and Claude AI stats 2026. Or browse all guides and prompts on PromptsRush.
Frequently Asked Questions
10 questions answered


