Last reviewed: 2026-10-25 · Prices from our dataset, rechecked against each provider’s official page · Price history

The list price per million input tokens is rarely what a production workload pays. Two mechanisms change it the most: prompt caching, which bills repeated input at a fraction of the normal rate, and batch processing, which discounts work you can wait for. Every provider we track handles them differently. This page sets out the rules from each provider’s own documentation and prices two workloads with them.

What caching and batching actually discount

Prompt caching applies to the start of a prompt that repeats exactly: a system prompt, tool definitions, a long document, or the earlier turns of a conversation. The provider keeps the processed prefix for a while; when the next request begins with the same tokens, those tokens are billed at the cached (or “cache hit”) rate. Change one token early in the prompt and everything after it is a miss.

Batch processing means submitting many requests as a job and accepting results later (OpenAI, Anthropic and Google describe a window of up to 24 hours). In return, the provider discounts every token in the job. It suits evaluations, classification backfills, nightly summaries and embeddings-style bulk work; it does not suit a user waiting for a reply.

Provider by provider

Anthropic (Claude)

• You mark what to cache with cache_control breakpoints, or turn on automatic caching. Minimum cacheable prompt: 512 tokens on the current models (Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5).
• Cache writes cost 1.25× the input price for the default 5-minute lifetime, or 2× for a 1-hour lifetime. Each cache hit refreshes the 5-minute timer at no charge.
• Cache reads cost 0.1× input as the standard multiplier, 0.05× on Opus 5.5 and Sonnet 5.5, and 0.025× on Fable 5.1.
• Message Batches: 50% off all usage. The discount stacks with caching, but cache hits inside a batch are best-effort (Anthropic cites 30–98% hit rates); its docs suggest the 1-hour cache for batches with shared context.

OpenAI

• For GPT-5.6 and later, cache writes cost 1.25× the input rate for the default 30-minute lifetime, or 2.5× for a 12-hour lifetime (Responses API). Reads cost 0.1× on most of these models and 0.05× on GPT-6.1 Sol.
• OpenAI stresses that the write rate is not an extra fee on top: each input token is billed once, at the uncached, cached or cache-write rate.
• Minimum cacheable prefix: 1,024 tokens for GPT-5.6 and later. Reported cached tokens are rounded down to a multiple of 128.
• Batch API: 50% off, results within 24 hours. The batch price table also halves cached-input and cache-write rates.

Google (Gemini)

• Implicit caching is on by default for Gemini 2.5 and newer: no setup, savings applied automatically on a hit. Minimum input for a hit: 4,096 tokens on Gemini 4 Argon, 3.8 Flash, 3.6 Flash and 3.1 Pro.
• Gemini 4 Argon supports implicit caching only. Other models also offer explicit caches, which add a storage charge per million tokens per hour (for example $0.50 on 3.8 Flash through 2026, $1.00 on the Flash-Lite models, $4.50 on 3.1 Pro).
• On Gemini 4 agent loops, Google notes that a new turn adding fewer than 2,050 tokens re-processes the last 2,050 tokens of the previous request at the standard input rate.
• Batch API: 50% of the standard price, 24-hour target turnaround; cache hits inside a batch are billed at the normal caching rates.

xAI (Grok)

• Caching is automatic for messages at the start of the conversation that match the previous request exactly. xAI recommends sending an x-grok-conv-id header to raise the hit rate.
• No separate write charge appears on the pricing page; cached tokens have their own listed rate.
• Batch API discount varies by model: 20% on Grok 4.7 (and other listed Grok 4.x models), applied to input, output, cached and reasoning tokens. Grok Build 0.1 is not on the discount list. Priority processing costs 2× standard rates.

DeepSeek

• Context caching on disk is enabled for everyone by default; a request hits the cache when its prefix fully matches a stored “cache prefix unit”. DeepSeek calls it best-effort, with no guaranteed hit rate.
• Cache hits are priced far below misses (see the table below). There is no separate write fee on the pricing page.
• DeepSeek’s pricing page lists no batch discount. Its equivalent lever is time of day: off-peak hours cost half the peak rate (peak is 01:00–04:00 and 06:00–10:00 UTC on weekdays).

Every model’s cache and batch rates

“Cache write” is shown only where the provider charges a separate write rate (Anthropic’s 5-minute lifetime, OpenAI’s 30-minute default). DeepSeek rates are peak-hour; Gemini 4 Argon and 3.8 Flash have announced price increases (see the Gemini page).

When a cache write pays for itself

With a 1.25× write and a 0.1× read, writing a prefix once and reading it once costs 1.35× its normal input price, against 2× for sending it twice uncached; OpenAI’s documentation works through the same numbers. Over ten uses the cached version costs 2.15× instead of 10×. So caching pays from the second hit, as long as the hits arrive before the entry expires: within 5 minutes on Anthropic’s default, 30 minutes on OpenAI’s. Low-traffic apps that send a request every 20 minutes may pay write prices again and again without ever reading, which is what the longer (and pricier) lifetimes are for.

Example A: a support assistant with a long fixed prefix

5,000 requests a day. Each sends a 6,000-token fixed prefix (instructions plus product documentation), 300 tokens of question, and gets 300 tokens back. The prefix is 95% of the input and clears every provider’s minimum length. At this traffic (several requests a minute) the cache stays warm, so we treat the prefix as read from cache and ignore the occasional write.

On Sonnet 5.5, for example, the bill falls from $2,340 to $630 a month. Notice that the saving is never the full read discount: output tokens and the uncached question are billed at the normal rates, and output is the expensive part (see input vs output pricing).

Example B: an offline classification job through the Batch API

200,000 support tickets a month, labelled overnight. Each request is 800 input tokens and 50 output tokens, and nobody is waiting for the answer, so it can go through a batch job.

A dash means the provider publishes no batch discount for that model. For DeepSeek, running the same job outside peak hours halves it instead. Batch and caching can be combined on Anthropic, OpenAI and Google, but a shared prefix of 800 tokens is too short to cache on Gemini (4,096-token minimum) and on OpenAI (1,024), which is why this example uses batch alone.

Common mistakes

• Putting variable content first. A timestamp, user name or retrieved snippet at the top of the prompt breaks the prefix for everything after it. Put the stable parts first and the changing parts last.
• Prefixes under the minimum. A 900-token system prompt is not cached on OpenAI or Gemini, and no error tells you so. Check the cached-token field in the response usage.
• Assuming batch is free money. A 24-hour window is fine for backfills and bad for anything user-facing; and on xAI the discount is 20%, not 50%.
• Forgetting storage on explicit Gemini caches. Explicit caches bill per hour they exist, used or not.

To try your own cache hit rate, set the cached share in the calculator.

Read next