Claude API Cost: Prompt Caching vs Batching Real Invoice Compare

Last quarter, an AI team at a mid-sized SaaS company watched their Anthropic invoice climb past $18,000/month β up from $4,200 just six months earlier. Same workload, roughly. Same model. The difference? They’d scaled without thinking about how they were calling the API.
Prompt caching vs. batching isn’t an academic debate. It’s the difference between a five-figure monthly bill and a four-figure one. And most engineers don’t nail the tradeoff until they’ve already paid for the lesson.
This is a real invoice comparison of both approaches, with actual Claude API pricing from March 2026.
In brief: Prompt caching slashes costs on repeated-context workloads by up to 90% on cached tokens, while batch processing cuts baseline per-token costs by 50% across the board.
- Prompt caching on Claude 3.5 Sonnet costs $0.30/MTok for cache reads vs. $3.00/MTok for standard input β a 10x reduction when your system prompt is reused.
- The Anthropic Message Batches API delivers a flat 50% discount on all tokens, with results returned within 24 hours.
- The right choice depends almost entirely on your request structure: repeated long context favors caching, high-volume independent requests favor batching.
Background: How Claude API Pricing Actually Works in 2026
Anthropic’s API pricing structure has three layers that matter here. Standard input/output pricing, billed per million tokens (MTok). Prompt caching β introduced on Claude 3 models and now standard across the Sonnet and Haiku tiers. And the Message Batches API, which offers a blanket 50% discount in exchange for asynchronous processing.
As of March 2026, according to Anthropic’s official pricing page (via CostGoat’s Claude API Cost Guide):
- Claude 3.5 Sonnet standard input: $3.00/MTok | output: $15.00/MTok
- Claude 3.5 Sonnet cache write: $3.75/MTok | cache read: $0.30/MTok
- Batch API (all models): 50% off standard input and output rates
The Haiku tier runs significantly cheaper β $0.80/MTok input, $4.00/MTok output standard β but the relative discounts from caching and batching hold proportionally across tiers.
Prompt caching became production-ready for Claude 3 Haiku and Sonnet in late 2024. By early 2026, it’s a mature feature with a clear usage pattern: prepend cache_control: {"type": "ephemeral"} to any block you want cached, and Anthropic stores it for up to 5 minutes (or longer with explicit TTL configuration). The Batches API launched shortly after and works differently β you send a JSONL file of requests, Anthropic processes them asynchronously, and you poll for results.
How Prompt Caching Cuts Costs on Real Workloads
Take a legal document analysis pipeline. Each request sends a 4,000-token system prompt β instructions, formatting rules, legal definitions β plus a variable 1,000-token document chunk. Without caching, every call pays full price on all 5,000 input tokens.
With caching, the 4,000-token system prompt gets written once ($3.75/MTok β slightly more expensive than standard on that first call) and then read at $0.30/MTok on every subsequent call. Break-even hits on the second request. By request 100, the math is stark:
| Scenario | 100 Requests Γ 5K Input Tokens |
|---|---|
| No caching (3.5 Sonnet) | $1.50 (100 Γ 5K Γ $3.00/MTok) |
| With caching (after first write) | $0.342 (1 cache write + 99 cache reads + 100 Γ 1K standard) |
| Savings | ~77% |
That 77% drops straight to the invoice. On $18,000/month of predominantly repeated-context calls, that’s roughly $13,860 back in your budget.
The ceiling case β RAG pipelines, code review bots, document assistants with long static prompts β can hit 90%+ savings on input tokens specifically. The constraint is TTL. If your cache expires between calls (5-minute default window), you pay the write cost again. That’s the failure mode most teams discover too late: a cache that looks configured but isn’t actually hitting.
How Batch Processing Fits a Different Pattern
The Batches API is a different beast entirely. It doesn’t care about repeated context. It charges half price for everything, no questions asked β but it requires async tolerance.
Batch results come back within 24 hours. Often much sooner, but there’s no real-time SLA. So this is strictly for async workloads: nightly report generation, bulk content classification, dataset annotation, A/B test evaluation at scale.
A concrete example: running 10,000 classification requests on Claude 3.5 Haiku at ~500 tokens input + 100 tokens output each.
| Approach | Cost Calculation | Total |
|---|---|---|
| Standard API | 10K Γ 600 tokens Γ blended rate | ~$12.80 |
| Batch API (50% off) | Same volume, half price | ~$6.40 |
| Prompt caching (no repeated context) | No benefit β each request is unique | ~$12.80 |
Batching saves $6.40 here. At 1 million such requests per month, that’s $640 vs. $1,280. The saving is linear and completely predictable.
This approach can fail when teams apply it to latency-sensitive workloads. Batch processing is not a generic cost lever β it’s a specific trade: speed for savings. If your product requires a response in under two seconds, the Batches API is the wrong tool regardless of the discount.
The Comparison That Actually Matters
| Dimension | Prompt Caching | Batch API |
|---|---|---|
| Max discount | Up to 90% on cached input tokens | 50% flat across all tokens |
| Latency | Real-time | Up to 24 hours |
| Best trigger | Long repeated system prompts | High-volume independent requests |
| Cache dependency | Yes β TTL matters | No |
| Implementation complexity | Medium (cache_control headers) | Medium (JSONL + polling) |
| Stacks with other features? | Yes β batch + cache combined | Yes β combine both |
That last row deserves attention. You can combine both strategies. Send batched requests that also include cached prompts. For a pipeline with repeated context and async tolerance, stacking both discounts is valid β and according to Anthropic’s documentation, cache reads within batch requests still apply the $0.30/MTok rate.
When Stacking Both Makes Sense
The highest-ROI scenario: a nightly content moderation pipeline. You have a 3,000-token policy document (static), plus 50,000 unique content items to evaluate, and async processing is fine.
- Cache the policy document: $0.30/MTok reads vs. $3.00/MTok standard
- Run all 50,000 items as a batch: 50% off output tokens
- Net result: 80β85% total cost reduction vs. naive standard API calls
This pattern appears consistently in compliance workflows, SEO content auditing, and CRM data enrichment β anywhere you have a static ruleset applied to variable inputs at scale. The math is repeatable and the implementation isn’t complicated.
Practical Implications: Three Scenarios, Three Calls
Scenario 1 β Real-time chatbot with a long system prompt.
Cache that system prompt aggressively. A 2,000-token assistant persona re-sent on every turn is the most wasteful pattern in the Claude API. Add cache_control once, monitor your cache hit rate in the response headers, and target above 85%. Below that threshold, check whether context window resets are expiring the cache prematurely.
Scenario 2 β Bulk async classification or labeling. Default to the Batches API. Don’t over-engineer it. Submit your JSONL, poll the status endpoint, retrieve results. The 50% discount requires no structural changes to your prompt design β it’s the lowest-effort optimization available.
Scenario 3 β High-volume RAG pipeline with a large retrieval context. Your retrieved documents change per query, but your instructions don’t. Cache the instructions. Batch the requests if latency allows. On a pipeline processing 500K queries per day at 2K tokens each, the cost difference between optimized and unoptimized can easily exceed $40,000/month. That’s not a rounding error. That’s a headcount decision.
Conclusion & Forward Look
The core findings from this comparison:
- Prompt caching delivers the highest single-strategy discount β up to 90% on input β but only when context repetition is high and cache TTL is actively managed
- Batch processing delivers a guaranteed 50% cut with zero structural optimization required, just latency tolerance
- Combining both is valid and documented β the stacking effect is real and measurable
- The right strategy depends entirely on your request shape, not your budget size
Looking ahead 6β12 months: Anthropic is likely to extend cache TTL windows beyond the current 5-minute default and introduce tiered pricing for longer persistence. There’s also growing API surface around batch priority tiers β faster batch processing at a smaller discount. Pricing adjustments have historically landed without much warning, so the Anthropic changelog is worth watching closely.
The action item is straightforward. Pull your last 30 days of API logs, calculate your cache hit rate and async-eligible request percentage, then run the numbers against current March 2026 rates. The math usually makes the decision for you.
Key Takeaways
- Prompt caching cuts input token costs by up to 90% β but only when your system prompts repeat consistently and your cache TTL is managed
- The Batches API cuts all token costs by 50% β no context repetition required, just async tolerance
- Stacking both strategies is supported and documented; combined savings can reach 80β85% on eligible pipelines
- The wrong optimization costs you nothing extra β but the missed optimization can cost tens of thousands per month at scale
References
- Claude Pricing Explained: Subscription Plans & API Costs | IntuitionLabs
- Claude Code Pricing: Pro vs Max vs API Key β Which Saves You More? (2026)
- Claude API Pricing Calculator & Cost Guide (Mar 2026)
Photo by Vitaly Gariev on Unsplash


