TL;DR (updated September 13, 2026): Anthropic's current first-party API rate card lists Claude Fable 5.1 at $10 / $50 per million input/output tokens, Opus 5 at $5 / $25, Sonnet 5 at $2 / $10, and Haiku 4.5 at $1 / $5. Sonnet 5's planned September increase was canceled, so $2/$10 is now the standard rate. Claude API organizations also have monthly spend caps and model-specific RPM, input-token-per-minute (ITPM) and output-token-per-minute (OTPM) limits. Those provider controls are useful backstops; your own application still needs its own workload attribution and hot-path policy if you want customer budgets or request blocking.
Claude API pricing in September 2026
| Model | Input / MTok | Output / MTok | Typical role |
|---|---|---|---|
| Claude Fable 5.1 | $10 | $50 | Highest-cost frontier tier |
| Claude Opus 5 | $5 | $25 | Deep reasoning / complex agents |
| Claude Sonnet 5 | $2 | $10 | General production default for many workloads |
| Claude Haiku 4.5 | $1 | $5 | Lower-cost classification / high-volume work |
Claude pricing is not just input + output anymore. Prompt caching, Batch API, data residency, fast mode and server-side tools can all change effective cost. For example, Anthropic currently documents a 50% Batch API discount on input and output, while prompt-cache reads cost a fraction of base input pricing. If your cost model uses only one hardcoded input/output pair per model, it will drift from the invoice.
Sonnet 5 did not rise to $3/$15
Anthropic originally announced Sonnet 5's $2 input / $10 output rate as introductory pricing through August 31, with a planned move to $3 / $15 on September 1. That increase was canceled. Anthropic's current pricing documentation says $2 / $10 is now the standard Sonnet 5 price.
This is a good example of why announced future prices should be effective-dated rather than copied directly into application code as guaranteed future state. If you had scheduled a September 1 rate flip, the correct production action was to remove it—not to preserve it because an old announcement once said so.
Monthly API spend caps: Start, Build and Scale
Anthropic currently documents three standard API usage tiers plus Custom:
| Tier | Monthly API spend cap |
|---|---|
| Start | $500 |
| Build | $1,000 |
| Scale | $200,000 |
| Custom | Arranged with account team |
When an organization reaches its tier spend cap, API usage pauses until the next calendar month unless the organization moves to a higher limit sooner. Anthropic also lets organizations set a lower self-imposed spend limit on the Billing page. The provider cap is therefore a genuine enforcement control for the Claude API account.
That still does not replace application-level policy. A provider organization cap answers "how much may this Anthropic account spend?" It does not answer "may customer A run this $3 workflow now?" or "has tenant B exhausted its product allowance?" Those decisions belong before the provider request, inside the gateway/application that knows the customer and product policy.
Rate limits are RPM + ITPM + OTPM
Claude's Messages API rate limits are measured separately for requests, uncached input and generated output:
- RPM — requests per minute
- ITPM — input tokens per minute
- OTPM — output tokens per minute
Limits are organized by usage tier and model class, and Anthropic uses a token-bucket algorithm rather than a simple fixed-minute reset. Short traffic spikes can therefore hit a limit even if an average-per-minute calculation looks safe. Anthropic also notes that only uncached input counts toward ITPM for most Claude models, so a healthy cache rate can materially increase effective throughput.
Do not hardcode one universal rate-limit table into your product. Anthropic exposes current limits in the Claude Console and now has a Rate Limits API for organizations that need to synchronize gateways/proxies with their configured limits.
What actually drives Claude cost
The unit-price table is only the start. Production cost usually moves because of workload shape:
- Model routing. Sending routine work to Fable/Opus instead of Sonnet/Haiku changes unit economics immediately.
- Growing context. Agents resend conversation history, retrieved documents and tool results. Input can grow much faster than request count.
- Retries and fan-out. One customer action can trigger multiple model calls, tool retries or sub-agents.
- Cache behavior. Repeated context with prompt caching is dramatically cheaper than reprocessing the same uncached input every turn.
- Provider-side features. Server tools, fast mode, data residency and other features can add separate price components.
A safer production architecture
Separate four responsibilities instead of trying to make the provider bill do all of them:
- Authorization: before calling Claude, your application decides whether the customer/workload is allowed to run.
- Provider execution: call Claude under Anthropic's account-level spend/rate limits.
- Application metering: after successful billable work, record the quantity against the customer/product/meter that caused it.
- Reconciliation: compare your application-side period totals and cost model with Anthropic's usage/billing data.
This separation prevents a common design mistake: treating a post-hoc usage ledger as if it were an inline circuit breaker. A ledger can prove what happened. Only the hot-path application/gateway can prevent the next request.
Where UsageBox fits
UsageBox does not import Anthropic billing data, manage Claude API spend caps, or block Claude requests. Anthropic remains the source of truth for its provider invoice and provider-side limits.
UsageBox can preserve the customer-facing quantity your own application emits. That lets you reconcile questions such as "what customer workload produced this provider spend?" without making the provider invoice your only operational ledger. Use subscription/product-item/meter ingest keys to preserve the cuts you will need later, then compare those totals against the provider bill.
See the AI API billing reconciliation pattern →