What is prompt caching? How a repeated prompt is reused

Prompt caching means the API remembers the beginning of your request and reuses it the next time you send the same beginning. You still send the full text every call, but the provider can skip the work of reading the repeated part again, and some providers bill that part at a lower rate. It only works on the start of the request, and only if that start is identical.

The support bot that keeps rereading the same page#

Say you run a support bot with 2,000 tickets a day. Every request starts with the same 3,000 tokens: tone of voice, refund rules, shipping policy. After that comes the one-line customer message, something like "Where is my order?" (If tokens are still fuzzy, start with what a token is.)

Without caching, the provider reads all 3,000 tokens of rules again for ticket number 1, ticket number 2, and ticket number 2,000. Same page, read 2,000 times. With caching, the first request pays the full price of reading it, and later requests that begin with the same text can reuse the work.

DeepSeek's API guide (checked 24 October 2026) describes exactly this: context caching is on by default, needs no code changes, and a later request with an overlapping prefix counts as a "cache hit". Only the input is cached. The answer is generated fresh every time.

What counts as "the same": the prefix rule#

The cache matches from the first character onward. The moment your request differs from the cached one, everything after that point is new. That is why the order of your request matters more than its length.

Here is the mistake that quietly kills caching. A developer wants the bot to know the time and puts it at the top:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

The time changes every second, so the very first line differs on every request, and nothing after it can match. The fix is to move whatever changes to the end:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

Now the 3,000 tokens of rules come first and stay identical. The same logic covers the other two common cases: a long chat resends its whole history on each turn, so the old messages are a ready-made repeating start (more on that in why a long chat costs more), and an agent repeats its tool definitions and instructions on every step.

Caching is also best-effort. DeepSeek says the cache takes a few seconds to build, a hit needs a full match of an existing cache prefix unit, there is no guaranteed hit rate, and unused caches are cleared, usually within hours to days. So a second request fired half a second after the first may not hit yet, and the hit may cover less than your whole prefix.

How to see it: the cache fields in usage#

You do not have to guess whether it worked. Each provider reports it in the usage part of the response, under its own field names.

DeepSeek uses two fields:

• prompt_cache_hit_tokens — input tokens that were found in the cache
• prompt_cache_miss_tokens — input tokens that were not

Say your first support ticket comes back with prompt_cache_hit_tokens: 0 and prompt_cache_miss_tokens: 3200, and a ticket a minute later shows prompt_cache_hit_tokens: 3000 and prompt_cache_miss_tokens: 200. The 3,000 tokens of rules were reused; only the new customer message and a few tokens were read from scratch. If the hit number stays at zero on every call, look at the start of your request: something in there is changing.

Anthropic works differently, because you mark what to cache. You add cache_control with type ephemeral to the request or to a content block:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

According to Anthropic's prompt caching documentation (checked 24 October 2026), the answer reports three numbers: cache_creation_input_tokens (written to the cache now), cache_read_input_tokens (read from it), and input_tokens (what came after the last cache breakpoint). Say the first call shows cache_creation_input_tokens: 10000, cache_read_input_tokens: 0; the second shows 0 and 10000. That is a cache write followed by a cache read.

There is one trap on screen. Prompts shorter than the model's minimum (512, 1,024 or 4,096 tokens, depending on the model) are processed without caching and without an error. You will see zeros in both cache fields and no warning. The default lifetime is 5 minutes, refreshed for free on every use; an optional ttl of 1h keeps it longer.

What it does to your bill#

Caching changes the price of the repeated part, so it is worth counting once. Anthropic lists multipliers on the base input price: a cache write with the 5-minute lifetime costs 1.25×, a read costs 0.1× (0.05× for Opus 5.5 and Sonnet 5.5). Take a 10,000-token prefix reused in 20 requests inside the 5-minute window, using the standard 0.1× read:

10,000 × 20 = 200,000 tokens at the base price without caching

10,000 × 1.25 = 12,500 for the first request that writes the cache

19 × 10,000 × 0.1 = 19,000 for the 19 requests that read it

12,500 + 19,000 = 31,500 token-equivalents with caching

So the repeated part costs well under a fifth of the uncached amount. The catch: if the 5 minutes lapse between requests, the next one writes the cache again at 1.25×, and a rarely used prefix can end up costing more than no caching at all.

Now the bot from the start, as a plain full-price baseline. 2,000 requests a day, 3,000 input tokens and about 300 output tokens each:

2,000 × 3,000 = 6,000,000 input tokens a day

2,000 × 300 = 600,000 output tokens a day

The table prices that day's workload on every available CheapTokens model next to OpenRouter:

DeepSeek-V4-Flash is cheaper than OpenRouter in total, with input and output counted together, and the workload fits easily: 380K context and up to 32,768 output tokens per answer. This is the full-price cost of the workload: input tokens × price per token. A long stable prefix is where that input share is biggest.

Try it yourself in five minutes#

The plan: send the same long system prompt twice with different questions and look at usage. Put your own rules text in support_rules.txt (a page or two of text is enough). The endpoint is the OpenAI-compatible CheapTokens API, and you can take the key from your account.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

What to check in the printout: prompt_tokens tells you how big your request is. Both requests carry the same SYSTEM text, so most of that number repeats from one request to the next — roughly the size of your rules file. That repeated start is the part a provider with caching, like the DeepSeek API or Anthropic above, can reuse. Now an exercise on order: add a line with the current time (datetime.now()) at the top of SYSTEM and run again. The two requests no longer share a start, because they differ from the very first line. Put the same line at the end of the prompt and the shared start is back.

A short checklist for your own prompts:

1. Stable text first: instructions, rules, tool definitions, examples.
2. Changing text last: date, user name, the latest message.
3. Keep the prefix byte-for-byte identical — even an extra space counts.
4. Check the provider's minimum size before wondering why nothing is cached.
5. Look at the usage fields after a change, not before.

To price your own workload, open the pricing page and plug in your input and output sizes, or start from the DeepSeek page. Once the first request works, the same estimate takes a minute for any prompt you write. For what the two sides of a request cost, see input vs output tokens.