Prompt Caching in Claude and GPT-6: Real Cost Savings and How to Use It

Prices updated November 6, 2026.

Anthropic and OpenAI both cache the parts of your prompt that don't change between calls (a system prompt, a large document you're repeatedly asking questions about, a set of few-shot examples) and charge a fraction of the standard rate for the cached portion on every subsequent call within the cache's lifetime. For workloads with a large, stable prefix and a small, changing suffix (RAG over a fixed document set, an agent with a long system prompt, a chatbot with persistent context), the savings are substantial and require no model or quality tradeoff.

How caching actually works

Both providers cache at the token level based on a shared prefix: the beginning portion of your prompt, up to the point where it starts to differ from a previous call, gets served from cache instead of reprocessed. This means cache hits depend entirely on prompt structure. Static content (system instructions, reference documents, tool definitions) needs to come first, and the part that changes per-request (the user's actual message) needs to come last. Put the changing content first and the cache never matches, because the "shared prefix" is empty from the first token.

On the first call you see cache_creation_input_tokens populated (you paid the write surcharge: caching costs slightly more than a normal call the first time, since the provider has to actually build the cache). On Anthropic a 5-minute cache write costs 1.25x the input rate, and OpenAI now charges the same 1.25x on GPT-5.6 and later models for its default 30-minute cache. GPT-5.5 and earlier OpenAI models have no write charge. On every call within the TTL you see cache_read_input_tokens, billed at a tenth of the standard input rate or less: 0.1x as standard on Anthropic and on OpenAI's GPT-5.6 and later, 0.05x on Claude Opus 5.5, Claude Sonnet 5.5 and GPT-6.1 Sol and Terra, and 0.025x on Claude Fable 5.1. If cache_read_input_tokens stays at zero across repeated calls, your prefix is changing between requests and the cache never matches. This is the most common implementation bug, usually caused by including a timestamp, request ID, or other per-call variable near the start of the prompt instead of the end.

There is also a size floor. OpenAI only caches prompts of at least 1,024 tokens on GPT-5.6 and later, so a short system prompt never qualifies.

Structuring prompts to maximize cache hits

The pattern is the same across both providers even though the API mechanics differ slightly: static content declared and ordered first, variable content last. Anthropic lets you mark the cache boundary explicitly with cache_control breakpoints, as above, or turn on automatic caching with a single top-level cache_control field. OpenAI caches the prefix automatically by default, and on GPT-5.6 and later you can switch to explicit-only breakpoints. Either way, the savings still depend on prefix stability.

Extending cache lifetime

To extend the lifetime of an Anthropic cache from the default 5 minutes to 1 hour, set the TTL explicitly:

The tradeoff is cost: the 1-hour cache costs 2x the input rate to write, against 1.25x for the 5-minute default, so it only pays off if your call pattern has gaps longer than 5 minutes between requests that share the same prefix. OpenAI's equivalent on GPT-5.6 and later is a choice between the default 30-minute retention and a 12-hour retention (Responses API only) that costs 2.5x the input rate to write. For a chatbot with continuous traffic, the default TTL refreshes on every call and never expires in practice; for a background job that runs every 20 minutes against the same reference document, the 1-hour TTL on Claude is the difference between a cache hit and a full-price rebuild each run.

Where the savings actually land

Caching only pays off proportional to how much of your token cost is in the static prefix versus the variable suffix. A RAG pipeline pasting a 10,000-token document ahead of a 50-token question sees most of its cost disappear on repeat calls: on Claude Sonnet 5.5 or GPT-6.1 Sol ($2 input, $0.10 cached), the input side drops from 10,050 × $2/1M = $0.0201 to 10,000 × $0.10/1M + 50 × $2/1M = $0.0011 per call once the cache is warm. A chatbot with a 200-token system prompt and a 2,000-token user message sees almost nothing, because the expensive part of the request was never cacheable in the first place. Measure the actual token split in your traffic before assuming caching will meaningfully move your bill. It's a structural fit for some workloads and close to irrelevant for others.

Where noburn fits

The tools discussed here handle observability, routing or evaluation, and all of them act once the LLM call has been made. noburn acts before it: one check() in your own code, placed before the provider call, returns allow or block against a project, per-user or per-run cap, so an over-budget call is never sent. It is not a proxy: your OpenAI or Anthropic client and its connection stay as they are. How the caps resolve, and the reason each one returns, is on the homepage.

Per-user caps and usage quotas keep one customer from spending another's budget, and Pro adds passthrough billing through Stripe. The Free plan covers 10,000 recorded calls a month with no card (current plans: pricing). Setup takes one install and one check: the quickstart, then per-user budgets and agent runs in the SDK reference.