Tokens Saved — the same output, a smaller bill

The problem

A broken cache throws no error.

It doesn't crash. It doesn't warn. cache_read_input_tokens quietly goes to zero and your bill goes up. One dynamic field in the wrong place is enough.

// healthy — the prefix is being reused
"usage": {
  "input_tokens":              1,204
  "cache_read_input_tokens":   847,392   ← billed at 0.1x
}

// broken — same code, one field moved
"usage": {
  "input_tokens":            848,596   ← full price, every turn
  "cache_read_input_tokens":       0   ← no error, no warning
}

breakpoints, max

Anthropic allows four cache_control markers per request. Place them wrong and you pay to write a cache nothing reads.

block lookback

A breakpoint searches back only twenty content blocks. Eight parallel tool calls can overshoot that in one turn.

512

token minimum

Below the model's minimum cacheable prefix, caching silently does nothing at all.

Three stacked translucent panes; the two beneath glow, the one on top is clear.

The mechanism

Pay once for the part that never changes.

Your system prompt, your tool definitions, your reference documents — identical on every call. A cache breakpoint marks where that stable prefix ends. Anthropic keeps the computed state and charges 0.1× to reuse it.

The model still runs a full forward pass on everything after the breakpoint. That is why the output cannot change: it is the same model reading the same tokens.

See where it breaks →

It happens to good teams

ProjectDiscovery ran at a 7% hit rate.

A security agent on Opus 4.5 with 2,500-line system prompts — over 20,000 tokens each. Caching was on. It was working at 7% because working memory sat inside the cached prefix and changed on nearly every step.

“Working memory changes on nearly every step. This was silently killing our cache hits.”
Moving it to the tail took them 7% → 74% in one change, then 84% with follow-ups — cutting cost 59%, later 70%, across 9.8 billion cached tokens. — their write-up →

And the longer the agent runs, the more it saves.

Their own production data, by task length. This is the shape that matters: the agentic work everyone is scaling into is exactly the work caching pays off hardest on.

Task length	Streams	Avg cache rate	Avg input tokens
1 step	2,801	35.5%	47,518
2–3 steps	794	30.0%	161,442
4–5 steps	620	42.8%	253,880
6–10 steps	1,284	53.6%	379,818
11–20 steps	1,729	63.9%	745,685
20+ steps	3,139	74.0%	3,763,263

At the extreme they measured tasks of 57–68M input tokens running at 83–93% cache rates. A comparable task before the fix ran at 3.2% — roughly a 60× cost difference on the same work. All figures are ProjectDiscovery's own, published and linked above.

What we ship

Only levers that can't change your output.

Same model, same tokens — so there's nothing to A/B, nothing to eval, and no quality argument to have in procurement.

Measure, then decide

The audit reads token counts from your usage — never prompt text. You get your real hit rate and dollar headroom before you change anything or sign anything.

Then keep it working

Caching breaks silently as prompts, tools and models churn through a growing team. We watch the hit rate and tell you the day it drops.

Caching discounts input only — output always bills full rate. And inference isn't bit-deterministic, so we claim zero quality change by construction (same model, same input), not identical bytes. Only an exact-match cache hit is literally byte-for-byte. See every method →

The same output.
A smaller bill.