Claude Prompt Caching Pricing: Cut API Costs

Cache Read and Cache Write Costs by Model

A cache read is the easy part of the answer. Prompt caching takes up to 90% off repeated input tokens. The discount applies when your request reuses eligible cached input rather than asking Claude to process the same context again.

The cache write is different. It creates the reusable prompt state, and its rate depends on the exact model and cache retention setting in your request. Check the live Anthropic rate card for the write terms that apply to your configuration.

Claude Haiku 4.5 costs $1 / $5 per 1M input/output tokens. Haiku is where repeated, structured work belongs when the job does not need deeper reasoning or a premium output.

Claude Sonnet 4.6 is priced at $3/$15 per million tokens. Sonnet is usually the practical middle ground when you need stronger reasoning, writing, coding, or instruction following without putting every request on the most expensive tier.

The Opus 4.x line is priced at $5/$25 per million tokens. Use that higher rate for work where the quality difference has a business consequence, not because a request happens to look complicated.

Fable 5, the top Claude tier, is priced at $10/$50 per million tokens. That makes Fable a deliberate choice. Put it behind a clear quality threshold, a customer tier, or an evaluation result.

The write-versus-read distinction matters most when the repeated block is large. A short reusable system instruction may not justify much engineering attention. A large policy set, retrieval bundle, codebase context, or tool catalog can. If the same context appears across a meaningful share of requests, caching earns its place. If every request has different context, it becomes ceremony around a discount you rarely collect.

Keep your cacheable material stable. Put durable instructions, policies, and shared reference context in the reusable portion. Keep user-specific details and changing retrieval results outside it. That structure is easier to reason about when a cost spike shows up in production.

You should also measure reuse rather than assuming it. A cache strategy looks great in a design document and can fall apart when each request varies slightly because a timestamp, user profile, tool list, or retrieval payload changes the prompt. The bill only cares whether the context gets reused.

Current Claude Model Pricing

All prices are per 1 million tokens. Confirm current rates against Anthropic's pricing page, since model versions and prices change.

The pricing structure follows a consistent pattern: output tokens cost exactly 5x input tokens across all models. This is important for cost estimation. If your application generates long outputs (code, articles, reports), output tokens will dominate your bill. If your application sends long context but generates short responses (classification, extraction, summarization), input tokens are the primary cost driver.

The Full Claude Lineup in 2026

The Claude lineup gives you a cost ladder. Haiku handles routine work. Sonnet handles the broad middle. Opus is for tasks that justify a premium model. Fable sits above the rest of the lineup and should be treated accordingly.

That does not mean every application needs every model. Most teams get a better result from a narrow routing policy than from an elaborate classifier that sends half the traffic to a premium tier because it cannot decide. Start with the work you have, then separate it by consequence.

Use Haiku for extraction, classification, formatting, straightforward transformations, and other jobs with clear acceptance criteria. These tasks benefit from predictable prompts and usually pair well with caching because the instructions are repeated.

Use Sonnet when the job needs judgment but does not justify the highest available cost. It is a sensible default for many production flows because it can cover a wide range of work while keeping the premium tiers reserved for a smaller share of requests.

Use Opus when the answer needs deeper reasoning, difficult code work, complex synthesis, or a higher bar for judgment. Opus 4.6 supports 128K output tokens. That matters for workloads that generate substantial output, but it also gives you another reason to be strict about routing: long answers are part of the bill.

Fable belongs where its top-tier price is justified by the value of a better answer. That could mean a high-stakes customer workflow, a difficult internal analysis, or a task that failed your Sonnet evaluation. It should not become the default because it makes a demo look polished.

The useful question is not which model is best in the abstract. It is which model produces an acceptable result for this request at a price the workflow can support. Put that rule in code, document the exceptions, and revisit it when your evaluation data changes.

Routing also gives you room to be more demanding about cache design. A large repeated prompt hurts more on expensive models, so the same caching discipline has a larger effect when premium traffic carries extensive shared context.

Routing between Haiku and Sonnet by task complexity can cut an overall bill by 60-80%. The gain comes from avoiding an expensive default, not from pretending every task can use the cheapest model.

Batch API: 50% Off Everything

The Batch API is the simplest way to cut Claude costs in half. You submit a batch of requests, and Anthropic returns results within 24 hours (typically faster, often within 1-2 hours). Both input and output tokens are billed at 50% of standard rates.

The batch API works well for: content generation pipelines, bulk document analysis, data extraction and classification, evaluation runs, and any workload where you do not need real-time responses. It does not work for chatbots, interactive assistants, or anything requiring sub-second latency.

One detail that surprises developers: prompt caching works with the Batch API. The discounts stack. A cached-input batch request on Haiku costs $0.05/1M for cached input tokens, which is 20x cheaper than standard Haiku input pricing.

Batch pricing changes the scheduling question. If a job does not need an immediate answer, sending it through the regular request path means paying for speed you did not need. That is a familiar form of waste because it hides inside infrastructure defaults.

Don't force live product interactions into a batch workflow just to chase a discount. A delayed answer can create a bigger problem than an API bill. The better move is to identify the jobs that already happen off the critical path and make Batch API the default for those jobs.

Evaluation workloads are a strong candidate. They often involve repeated prompts, a large collection of inputs, and no user waiting on the result. That gives you room to combine prompt caching with batch processing rather than treating them as competing choices.

The same goes for ingestion pipelines. If you are extracting fields from documents or classifying a backlog of records, there is little reason to treat each item as an urgent transaction. Batch the work, cache the stable instructions, and reserve higher-cost models for the records that fail a cheaper path.

For a wider market comparison, see LLM pricing per million tokens. If you are still sorting out how token bills behave across providers, LLM token pricing guide is the better starting point.

Prompt Caching: Up to 90% Off Input Tokens

Prompt caching is Claude's most powerful cost-saving feature, and it is underused. The concept: you mark a section of your prompt (system instructions, reference documents, few-shot examples) as cacheable. The first request writes it to a cache. Subsequent requests read from that cache at 90% off the normal input price.

How It Works

You add a cache_control breakpoint to your message content. Everything before that breakpoint is eligible for caching. There are two cache durations:

• 5-minute cache (ephemeral): Cache write costs 1.25x normal input. Cache read costs 0.1x normal input. Best for interactive sessions where the same system prompt is reused across multiple user messages.
• 1-hour cache: Cache write costs 2x normal input. Cache read costs 0.1x normal input. Best for batch processing pipelines where the same context is used across many requests over a longer period.

Caching Cost Math

The breakeven point is remarkably fast. If you reuse a cached prompt even twice, you save money. For a chatbot with a 2,000-token system prompt handling 100 messages per session, prompt caching turns $0.006 per message (at Sonnet rates) into $0.0006 per message after the first request. Over a million messages per month, that is $5,400 in savings.

Minimum Cache Sizes

The cached content must meet minimum token thresholds: Haiku 4.5 requires 1,024 tokens, Sonnet 4.6 and Opus 4.6 require 2,048 tokens. If your system prompt is shorter than these thresholds, pad it with reference documentation or few-shot examples. The caching savings almost always justify adding more context.

Where the Savings Come From

Prompt caching pays off when the expensive part of your input repeats. That is usually not the user's latest message. It is the machinery around it: system instructions, policies, tool schemas, examples, knowledge context, or a shared document set.

The first request establishes reusable context. Later requests reuse it if the relevant input remains stable and meets Anthropic's current cache rules. That is why prompt construction becomes a cost-control problem, rather than only a quality problem.

A good cache boundary separates stable material from volatile material. Put company policy, approved style guidance, output schemas, and repeated tool instructions in the stable section. Keep account-specific details, the latest user request, and changing data near the end.

Avoid rebuilding the reusable prompt for each request. Small changes can defeat reuse. If you insert a changing identifier into the middle of a shared instruction block, you may turn what looked like a cacheable workflow into a series of fresh writes.

The discount is substantial enough to deserve instrumentation. Prompt caching takes up to 90% off repeated input tokens. Track which workflows create reusable context, how often they reuse it, and where prompt drift prevents a cache hit.

That also makes debugging easier. When costs rise, you can inspect whether traffic increased, input grew, output grew, the model mix shifted, or caching stopped working. Those are different problems. Treating them as one generic "LLM cost issue" wastes time.

Extended Thinking Costs

All current Claude models support extended thinking, where the model reasons internally before generating a visible response. This improves output quality on complex tasks but increases costs because thinking tokens are billed as output tokens.

Here is what this means in practice:

• A simple classification task might use 50 thinking tokens and 10 output tokens. The thinking overhead is negligible.
• A complex coding task might use 5,000 thinking tokens and 500 output tokens. You are paying for 5,500 output tokens, 10x what you see in the response.
• A deep research analysis might use 20,000+ thinking tokens. At Opus output rates ($25/1M), 20K thinking tokens cost $0.50 per request.

You can set a max_tokens budget to cap thinking costs. This is important for production applications where unpredictable thinking lengths could spike your bill. A reasonable default: set max_tokens to 3-5x your expected visible output length.

Fast Mode Pricing (Opus 4.6 Only)

Opus 4.6 has a "fast" mode in research preview that provides significantly faster output at a steep premium: 6x standard pricing.

At $150/1M output tokens, fast mode is the most expensive LLM API available from any major provider. It makes sense for latency-sensitive applications where Opus-level reasoning is required and cost is secondary. For most workloads, Sonnet 4.6 at standard speed provides better value than Opus at fast speed.

Claude vs. Competitors: Price Comparison

How Claude stacks up against the other major LLM providers on price. Confirm current figures before budgeting, since rates change.

Claude Opus 4.6 at $5/$25 is cheaper than GPT-5 at $10/$30 while offering a larger context window (1M vs. 128K). Sonnet 4.6 at $3/$15 is slightly more expensive than GPT-4o at $2.50/$10 on a per-token basis. Where Claude loses on price is the budget tier: Haiku at $1/$5 is significantly more expensive than GPT-4o mini at $0.15/$0.60 or Gemini 2.0 Flash at $0.075/$0.30.

The pricing gap at the budget tier matters for high-volume classification and extraction tasks. If you are processing millions of documents and do not need Claude-quality reasoning, GPT-4o mini or Gemini Flash save 7-13x per token.

Real-World Cost Examples

Concrete cost estimates for common workloads, assuming standard pricing (no batch, no caching) and then with optimizations applied.

The "with optimizations" column assumes batch API (50% off) plus prompt caching on a 2K-token system prompt reused across all requests (which reduces that portion of input to 10% of standard). The actual savings depend on how much of your input is cacheable and whether your workload tolerates batch latency.

Model Selection: When to Use Which

Picking the right model for each task is the highest-impact cost decision. Here is a practical framework.

• Haiku 4.5 ($1/$5): Classification, entity extraction, data formatting, intent routing, simple Q&A, content filtering, and any task where the input is structured and the output is short. If you can write the expected output format in a few sentences, Haiku handles it.
• Sonnet 4.6 ($3/$15): Code generation, document analysis, multi-step reasoning, long-form writing, and general-purpose assistant tasks. This is the model most production applications should default to. It handles 90% of tasks at a fraction of Opus cost.
• Opus 4.6 ($5/$25): Complex research synthesis, novel problem-solving, tasks requiring deep domain reasoning, and situations where getting the right answer on the first try is critical (legal analysis, medical reasoning, financial modeling). Only use Opus when Sonnet demonstrably fails at the task.

A well-designed system routes each request to the cheapest capable model. A support chatbot might use Haiku for FAQ-style questions, Sonnet for troubleshooting conversations, and Opus only for escalated technical analysis. This model routing approach can reduce overall costs by 40-60% compared to running everything through Sonnet.

Stacking the Discounts: One Worked Bill

A production bill improves when you stack the discounts around the shape of the work.

Start with a workflow that repeats a large shared instruction block. Cache that stable context so repeated input receives the available cache-read discount. Put the non-urgent portion of the workload through Batch API, where the Batch API cuts all Claude token prices by 50%. Then route routine requests to Haiku and send more demanding work to Sonnet.

That combination attacks different sources of spend. Caching reduces repeated input. Batch pricing reduces the price for work that can wait. Routing avoids paying a stronger model for work that has a cheaper acceptable path.

The important constraint is that these tools do not excuse bad prompt design. If you send bloated context on every request, a discount only makes the waste cheaper. If you route a difficult task to Haiku and it fails, the retry can erase the savings. If you batch a task that needs a live response, the customer pays for your cost optimization with a worse product.

Use evaluation data to set the line between Haiku and Sonnet. Keep a small set of tasks that earn Opus or Fable. Cache only context that repeats enough to justify the added structure. Batch only work that is already off the critical path.

This is where teams usually win. They do not find one magic setting. They stop paying premium rates for routine work, stop reprocessing the same context, and stop treating every request as urgent.

Related Resources