What does prompt caching save?

Suppose an embedded support assistant answers three questions about the same product handbook. One customer asks how to invite a teammate, another asks which roles can export data, and a third asks where to change a billing address. Each request includes the handbook. Each needs a different answer.

Prompt caching can reuse processing of the shared input while the model generates each answer separately. The reusable part is a matching beginning of the request, often called a prompt prefix. An answer cache, by comparison, would store a finished response for later retrieval. That would be a separate application feature.

The example here uses Anthropic’s Claude Messages API, with documentation checked on November 4, 2026. Tokens are the units into which a model divides input and output. Cache controls, minimum lengths and billing rules depend on the provider and model.

The same document, three new questions

In this hypothetical assistant, each request starts with the same support instructions followed by the same handbook. The question comes last. A cache boundary after the handbook separates the reusable prefix from the changing question:

Request 1: [support instructions + handbook] | How do I invite a teammate?
Request 2: [support instructions + handbook] | Which roles can export data?
Request 3: [support instructions + handbook] | Where do I change my billing address?
           identical prefix                 new input

For the worked example, assume that the prefix meets the selected model’s minimum cache length, the first request creates an entry, and the next two arrive while it remains available. The different questions can then follow the same cached prefix. Each question still needs a generated answer based on the handbook.

The distinction changes how a support team should interpret a cache hit. The second customer has not received the first customer’s invitation instructions. The system has reused processing for material both requests already included. Answer quality still depends on whether the handbook contains the requested information and whether the assistant uses it correctly.

Where a change lands matters

In the Claude Messages API, caching is enabled with cache_control. A top-level setting chooses the last cacheable block automatically; an explicit marker chooses a block. Cached prefixes must match, and entries have a lifetime and a model-dependent minimum length. The prompt-caching guide documents those rules.

An explicit marker after the handbook suits this particular arrangement. Putting the marker after each changing question would write a different whole prefix each time. Looking backward would not create a handbook-only entry that the earlier request never wrote. A growing conversation is different: appending turns can preserve a prefix that an earlier request did cache.

This explains why a timestamp at the start of each request can undermine reuse. In this arrangement, even an unchanged handbook follows a different beginning. Placing stable material before request-specific material gives this example a reusable boundary after the handbook.

The usage fields show what happened

The API response reports cache_creation_input_tokens for cache writes and cache_read_input_tokens for cache reads. input_tokens covers input outside those categories; output_tokens records generated output. These fields are part of the Messages API reference.

Suppose the shared prefix contains 6,000 tokens. The following counts are invented accounting examples, not measurements or a promise that three calls will hit the cache:

The second request’s total input is 6,160 tokens: 6,000 read from cache plus 160 regular input tokens. Reading only input_tokens would hide most of the material the model received. Cached input also occupies context capacity; the context-window documentation explicitly includes cache reads and writes in that count.

A cache write has a price

Anthropic prices cache writes, reads, ordinary input and output separately. Its current pricing reference lists five-minute writes at 1.25 times ordinary input pricing and one-hour writes at twice that input price. Read prices vary by model. Enabling caching does not establish a saving by itself.

In the invented example, processing the shared prefix three times without caching would bill 18,000 ordinary input tokens. With the assumed hits, that portion becomes 6,000 write tokens plus 12,000 read tokens. The 420 tokens of changing input and 730 output tokens remain separate in either calculation. Applying the selected model’s rates to those categories gives a comparison that includes the initial write.

If the prefix is used once, there are no later reads to offset its write cost. If each request changes the handbook, this example’s marked prefix needs repeated writes. Observed read and write counts are therefore more useful than assuming that repeated use of a feature produces repeated use of its cache.

Caching and conversation memory do different jobs

The three support requests are independent. Each supplies the handbook and its own question. A continuing conversation would also need the relevant earlier turns supplied through the application’s conversation mechanism. Prompt caching changes how repeated material is processed; it does not choose which facts belong in the next request.

For an initial check, compare requests that differ only after the intended boundary, then inspect their usage. Next change the handbook and inspect the new counts. The result should explain which input was reused and what the application paid to create it. For this support assistant, that is enough to distinguish cheaper repeated handbook processing from saving an answer or remembering a customer.