TEARDOWN Nº 1 / THE CACHE MINIMUM

The cache minimum: why your prompt cache silently does nothing

PUBLISHED 2026-08-12 · BY Llorenç Ballester — Chief Burn Officer

Prompt caching is the biggest discount in the price sheet, and the easiest to lose without noticing. Every Anthropic model publishes a minimum prompt length; under it, the cache simply does not engage. No error, no warning, no line in your bill saying so — just the full input price, on every single call, forever.

What the minimum actually is

Caching bills a repeated prefix — your system prompt, tool definitions, the documents you send every time — at a fraction of the input price. The discount is real and large: on Claude Sonnet 5 a cached read costs $0.20 per million tokens against $2.00 at list.

What the pricing pages mention once and nobody reads twice is that the discount has an entry fee. Below a published number of tokens, the provider does not cache at all. The request still succeeds. The answer is identical. The only visible difference is a counter in the response body that stays at zero — and a bill that never goes down.

The thresholds, and what missing them costs

Scenario, fixed for every row: a 2,000-token stable prefix, 150 tokens of varying input, 200 output tokens, 10,000 calls a day. Cache writes are charged once per five-minute TTL window (288 a day), which is what continuous traffic looks like.

Prices from the board, last confirmed 2026-08-12. Estimates at list prices, not invoices — the point is the ratio, not the absolute figure.

The worst row is Claude Haiku 4.5: the same workload that would cost $425 a month with a working cache costs $945 without one — $520 a month of pure threshold, bought by nobody and noticed by no one.

The cliff is one token wide

Thresholds do not taper. There is no partial caching, no proportional discount for getting close. On Claude Haiku 4.5:

This is the part worth internalising: a prompt sitting just under the line is the most expensive prompt you can write. It carries all the weight of a long prefix and earns none of the discount. Padding it — with genuinely useful context, not filler — can cut the bill by two thirds. It is the only situation in this entire site where we will tell you that a longer prompt is the cheaper one.

The routing trap

Now the failure mode that actually costs teams money, because it arrives disguised as an optimisation. You move a workload from Claude Sonnet 5 to Claude Haiku 4.5 to halve the token price. Your prefix is 2,000 tokens: comfortably over Claude Sonnet 5's 1,024, and well under Claude Haiku 4.5's 4,096. You did not change a line of the prompt, but the cache that was serving it just switched off.

Whether the downgrade actually saves you anything depends on how much the model writes back. Below roughly 263 output tokens per call, the more expensive model with a working cache is the cheaper option — the prefix dominates the bill and the discount on it outweighs the cheaper rates. Above that, output volume takes over and the cheap model wins as expected. Classification, extraction, routing and retrieval with short answers all live on the wrong side of that line.

The general lesson is not “never downgrade”. It is that a price-per-token comparison is not a cost comparison, and routing decisions made on the price sheet alone can quietly invert once caching is in the picture.

The models that publish nothing

12 of the 17 models we track publish no minimum in the public pricing data: GPT-5.6, GPT-5.5, GPT-5.4, GPT-5 Mini, Gemini 3.1 Pro, Gemini 3.6 Flash, Gemini 3.5 Flash, Gemini Omni Flash, Gemini 3 Flash, Gemini 3.5 Flash Lite, DeepSeek V4 Pro, DeepSeek V4 Flash. We are not going to tell you they have no threshold, because we cannot verify that from a price sheet — and the honest version of this teardown says so. What we can tell you is that you cannot rule the problem out for them from published pricing alone, so the response-level check below is the only way to know.

How to check yours in five minutes

1. Count the prefix, not the prompt. Only the stable, identical-every-time portion counts toward the threshold — system prompt plus tool definitions plus fixed documents. Paste it into the calculator for an exact count.
2. Compare it to your model's number in the table above, or on the model's pricing page.
3. Read the usage block of a real response. Anthropic returns cache_read_input_tokens; OpenAI reports cached tokens under prompt_tokens_details. Two identical calls in a row with reads still at zero means the cache never engaged.
4. If you are short, decide deliberately. Either lift the prefix over the line with context that earns its place — few-shot examples, the schema you keep re-explaining, the style guide — or accept that this workload does not cache and stop budgeting as if it did.
5. Re-check after any model change. The threshold travels with the model, not with your code. This is the step everyone skips.

Method and limits

Every figure here is computed at build time from the pricing board, so this page corrects itself when a price or a threshold moves. Thresholds and cache rates are the providers' published numbers, taken from the same dataset the board is cross-checked against daily — we do not estimate them. The scenario is one set of assumptions, stated above and held constant across models; your prefix, call volume and output length will differ, and the absolute numbers with them. The ratios are the durable part. Full rules at /methodology.

One limitation worth naming: we model a steady stream of traffic, one cache write per five-minute window. A bursty workload that goes quiet between calls re-pays the write more often and saves less than these numbers suggest. If your traffic is spiky, treat the savings column as a ceiling.

Frequently asked questions