Does Prompt Caching Save Money? Replaying Three Bills with the Same 12K Context

An agent may resend the same system prompt, tool definitions, repository rules, and long reference documents on every turn. Prompt caching promises to process that stable prefix once and charge later requests at a lower cache-read rate.

But “cached input is 90% cheaper” is not a complete bill. You still need to know:

Is the first write more expensive?
How many tokens are required before caching starts?
Does the entry live for five minutes or one hour?
Does changing one character invalidate the rest of the prefix?
After ten requests, how many dollars did you actually save?

This article does not invent three production-account bills. The environment did not have three publishable provider credentials, so the experiment is an executable billing replay built from official prices and one fixed token scenario. The inputs and formulas are reproducible, and the mechanisms were checked against official documentation on July 19, 2026. It answers the cost question without pretending to be a live latency benchmark.

The result first

For ten requests in our replay:

Plan	Input cost without caching	With caching	Saved	Saving rate
OpenAI `gpt-5.6-terra`	$0.302000	$0.066500	$0.235500	77.98%
Claude Sonnet 4.6, 5-minute cache	$0.362400	$0.079800	$0.282600	77.98%
Gemini 2.5 Flash, excluding explicit storage	$0.036240	$0.007080	$0.029160	80.46%

This table does not prove that Gemini has “better caching.” The underlying models, output prices, quality, context limits, and cache interfaces differ. It isolates only the input-side billing structure for one fixed token scenario.

Four variables determine the result:

reusable-prefix length;
reuse count inside the TTL;
first-write multiplier;
whether requests preserve a stable prefix.

Experiment design

Fixed parameters:

Stable prefix: 12,000 input tokens
Variable suffix: 80 input tokens per request
Requests: 10
Output cost: excluded to isolate input caching
Gemini explicit storage: zero hours in the main table

The 12K prefix represents a system prompt, safety rules, tool schemas, repository instructions, and a long product document. Only the question at the end changes.

Correct placement of a stable prefix and variable suffix

The sequence has three request types:

Cold / Write — send the full prefix and populate a cache;
Warm / Read — keep the 12K prefix unchanged and replace only the final 80-token question;
Miss — change content in the middle of the prefix to show why later content no longer qualifies as the same reusable prefix.

The cost table uses one write plus nine reads. The miss explains failure behavior but is excluded from the main bill because provider routing and implicit-cache behavior would otherwise make the replay less deterministic.

Cold request, cache hit, and broken-prefix miss

These are three different cache products

OpenAI: automatic prefix caching, with separately priced writes on newer families

OpenAI enables Prompt Caching automatically for eligible requests. Its current documentation states that:

prompts need at least 1,024 tokens by default;
hits require an exact prefix match;
static instructions, examples, images, and tools belong at the beginning;
user-specific values belong at the end;
caching is supported on gpt-4o and newer models;
reads appear in cached_tokens;
GPT-5.6 and later report writes in cache_write_tokens and support explicit breakpoints;
GPT-5.6 and later should use a stable prompt_cache_key for more reliable matching; OpenAI recommends roughly no more than 15 aggregate RPM per key and stable sharding above that rate.

The time-sensitive change is cache-write pricing. GPT-5.6-family writes cost 1.25× uncached input, while reads commonly cost 0.1× input. Older models generally had no separate write surcharge, so old caching heuristics should not be applied blindly to new families.

We use the official gpt-5.6-terra rates:

Uncached input: $2.50 / MTok
Cache write:    $3.125 / MTok
Cache read:     $0.25 / MTok

On GPT-5.6 and later, prompt_cache_options.ttl currently uses 30m. This is a minimum reusable duration, not a guarantee that the cache disappears after 30 minutes. Earlier in-memory caches are typically removed after 5–10 minutes of inactivity and may last up to about one hour; some older models support extended retention up to 24 hours. TTL probes must therefore be interpreted per model: waiting 31 minutes is not a deterministic miss test for GPT-5.6.

Anthropic: explicit cache semantics with 5-minute and 1-hour writes

Claude uses cache_control. The current API supports:

top-level automatic caching, which moves a breakpoint as a conversation grows;
explicit breakpoints on individual content blocks.

Pricing is expressed as multipliers:

5-minute writes: 1.25× base input;
1-hour writes: 2× base input;
hits and refreshes: 0.1× base input.

Official Claude Sonnet 4.6 rates are:

Base input: $3.00 / MTok
5m write:   $3.75 / MTok
1h write:   $6.00 / MTok
Cache read: $0.30 / MTok

Sonnet 4.6 requires at least 1,024 tokens. Shorter marked prompts do not fail; they simply do not cache. Verify behavior through usage:

{
  "usage": {
    "cache_creation_input_tokens": 12000,
    "cache_read_input_tokens": 0
  }
}

On a later hit, creation should fall and cache_read_input_tokens should rise. Concurrency also matters: the cache becomes available only after the first response begins. Ten simultaneous cold requests should not be modeled automatically as one write and nine hits.

Gemini: implicit-only in Interactions API, explicit objects in generateContent

Google's current docs distinguish two surfaces:

Interactions API supports implicit caching only and enables it by default on Gemini 2.5 and newer models;
generateContent API still supports explicitly created cache objects and TTLs.

Current Interactions API minimums include:

Model	Minimum tokens
Gemini 3.5 Flash	4,096
Gemini 3.1 Pro Preview	4,096
Gemini 2.5 Flash	2,048
Gemini 2.5 Pro	2,048

Place large common content first and send similar prefixes close together. Interactions reports hits through usage.total_cached_tokens; older generateContent responses commonly expose cachedContentTokenCount. A gateway must not assume both APIs share the same raw schema.

Official Gemini 2.5 Flash pricing is:

Regular input: $0.30 / MTok
Cached input:  $0.03 / MTok
Explicit cache storage: $1.00 / MTok / hour

Google separates cache reads from explicit storage. An implicit-cache test should not invent one hour of storage cost. If you create an explicit cache object, storage duration belongs in the bill.

Reconstructing the bill

Let:

$P$ be stable-prefix tokens;
$S$ be variable-suffix tokens;
$N$ be request count;
$U$ be uncached input price;
$W$ be write price;
$R$ be read price.

Without caching:

$$ C_{plain} = N(P+S)U $$

With one write and later hits:

$$ C_{cache} = PW + (N-1)PR + NSU $$

For explicit storage, add:

$$ C_{storage} = P \times H \times T $$

where $H$ is storage hours and $T$ is storage price per token-hour.

OpenAI replay

No cache: 10 × 12,080 × $2.50 / 1M = $0.302000
Cached:
  12,000 × $3.125 / 1M
+ 9 × 12,000 × $0.25 / 1M
+ 10 × 80 × $2.50 / 1M
= $0.066500

Claude 5-minute replay

No cache: 10 × 12,080 × $3.00 / 1M = $0.362400
Cached:
  12,000 × $3.75 / 1M
+ 9 × 12,000 × $0.30 / 1M
+ 10 × 80 × $3.00 / 1M
= $0.079800

Gemini implicit replay

No cache: 10 × 12,080 × $0.30 / 1M = $0.036240
Cached:
  12,000 × $0.30 / 1M
+ 9 × 12,000 × $0.03 / 1M
+ 10 × 80 × $0.30 / 1M
= $0.007080

The first Gemini prefix is priced as regular input, with no explicit storage in the main table. Keeping a 12K explicit cache for one hour adds:

12,000 × $1.00 / 1M × 1 hour = $0.012000

The scenario then costs $0.019080. It still beats uncached input, but the saving rate is lower.

How write, read, and uncached input compose the bill

When does caching break even?

Ignoring the short suffix, caching is cheaper when:

$$ W + (N-1)R < NU $$

Therefore:

$$ N > \frac{W-R}{U-R} $$

Strategy	Write multiplier	Read multiplier	First request count with lower total cost
OpenAI GPT-5.6 / Claude 5m	1.25×	0.1×	2 requests
Claude 1h	2×	0.1×	3 requests
Gemini implicit, first request at base price	1×	0.1×	2 requests

A cache used once offers no savings. A one-hour Claude cache used only twice can cost more than uncached input. Choose TTL from the actual reuse interval, not from the assumption that longer is always better.

Why the bill may not fall

You changed the prefix, not the suffix

Timestamps, random IDs, user names, or dynamic authorization placed near the beginning can invalidate all stable content after them.

Prefer:

Stable system rules
→ stable tool definitions
→ stable documents
→ user/session variables
→ current question

The prompt is below the model minimum

A request can return HTTP 200 while caching zero tokens. Inspect usage, not merely status codes.

The warm-up was sent concurrently

A first response may need to begin before later requests can hit. A burst of ten cold requests is not equivalent to one write plus nine reads.

Tools, images, or schemas changed

OpenAI explicitly includes images and tool definitions in prefix matching. Reordering tools or regenerating schemas every turn can destroy reuse.

Gateway routing breaks cache affinity

This sits below the MCP and A2A collaboration layer. Protocol correctness does not guarantee an efficient cost path. A multi-channel gateway that ignores cache affinity may reduce hit rates through ordinary load balancing.

What a gateway must record

prompt_tokens alone is insufficient:

Normalized metric	OpenAI	Claude	Gemini
Regular input	uncached portion of prompt/input	`input_tokens`	prompt input fields
Cache read	`cached_tokens`	`cache_read_input_tokens`	`total_cached_tokens` or `cachedContentTokenCount`
Cache write	`cache_write_tokens`	`cache_creation_input_tokens`	implicit/explicit API-specific
TTL class	retention/model setting	5m / 1h	cache-object TTL
Hit rate	reads and request counts	reads and request counts	reads and request counts

Nbility's backend already distinguishes:

OpenAI cached_tokens and cache_write_tokens;
Claude creation and read tokens;
Claude 5-minute and 1-hour creation tokens;
Gemini cachedContentTokenCount;
overall and provider-specific hit counts, input, read, and write totals.

Billing applies separate ratios to ordinary input, cache reads, and cache creation. It also clamps the uncached remainder when overlapping upstream fields would otherwise make it negative. That is materially closer to a real multi-provider bill than multiplying every input token by one rate.

Executable replay

from dataclasses import dataclass

PREFIX = 12_000
SUFFIX = 80
REQUESTS = 10

@dataclass(frozen=True)
class Plan:
    name: str
    uncached: float
    write: float
    read: float

plans = [
    Plan("OpenAI gpt-5.6-terra", 2.50, 3.125, 0.25),
    Plan("Claude Sonnet 4.6", 3.00, 3.75, 0.30),
    Plan("Gemini 2.5 Flash", 0.30, 0.30, 0.03),
]

for p in plans:
    plain = REQUESTS * (PREFIX + SUFFIX) * p.uncached / 1_000_000
    cached = (
        PREFIX * p.write
        + (REQUESTS - 1) * PREFIX * p.read
        + REQUESTS * SUFFIX * p.uncached
    ) / 1_000_000
    print(p.name, round(plain, 6), round(cached, 6))

This formula was executed before publication and produced the table above. Replace token counts and rates with raw provider usage and current official prices to reconstruct your own workload.

How to run a live test correctly

Test each provider separately:

pin model version, region, tools, and generation parameters;
record a hash of the stable JSON prefix;
send a cold request and wait for response start;
send nine requests that change only the final question;
retain raw usage, total HTTP time, and TTFT;
modify one block in the middle of the prefix and send a miss;
rebuild input cost from native usage fields;
repeat multiple rounds and report medians and percentiles.

This article reports no TTFT numbers because three production credentials were unavailable. Caching can reduce prompt processing, but network, queueing, regional load, and model load still affect latency. Deriving TTFT from a pricing table would be fabricated evidence.

When not to cache

prompts are short;
a prefix is used once inside its TTL;
every user's prefix is highly personalized;
tools and permissions change every turn;
explicit storage costs exceed reuse savings;
retention or data policy disallows the chosen mode.

Prompt caching is not a universal “save 90%” switch. It depends on request layout, scheduling affinity, usage normalization, and billing semantics.

Production checklist

Conclusion

With a 12K stable prefix reused ten times, all three billing models reduced input cost by roughly 78%–80%. The savings came from repeated reuse of one stable prefix—not from the word “cache.”

The practical method is simple:

reconstruct reads, writes, ordinary input, and storage from raw usage;
put actual request count, TTL, and prefix-miss rate into the formula.

If you need one place to manage OpenAI, Claude, and Gemini channels and usage, Nbility provides a unified gateway and billing view. For a small test credit, open a request in the ticket center with the models and scenario you plan to test.