Two Claude requests with the same long prefix

A long reference document goes into a Claude request. A short question follows it. On the next request, the document stays unchanged and the question changes. These two calls can look almost identical in your application, yet produce different cache usage. The useful comparison is not simply “first call, second call.” It is which tokens were written, which were read, and which were processed outside the cache.

Vana API provides one OpenAI-compatible endpoint at https://api.vanaapi.com and also speaks the Anthropic Messages and Gemini native protocols. For this notebook entry, the Anthropic Messages format makes the cache boundary and usage fields easiest to examine.

§ Line one: the reusable prefix

Cache write: Put stable instructions and reference material before the changing question. Add an explicit cache_control setting at a supported content-block boundary. The usual short-lived setting is an object whose type is ephemeral.

Cache read: Send the same prefix again, with the same cache boundary. A cache hit depends on a matching prefix, not on whether two documents mean roughly the same thing. Changed wording, reordered material, or a timestamp near the beginning can prevent reuse of the intended prefix.

Place variable information after the reusable material. Caching is not a substitute for sending the context: the request still contains the prefix that Claude can match against a cached entry.

§ Line two: the cache boundary

Cache write: The boundary marks the end of the prefix you want made reusable. It does not mean “cache only this paragraph.” Earlier eligible request content contributes to that prefix, including the relevant tools, system instructions, and messages.

Cache read: The matching cached prefix is reused, while the new question after it remains ordinary input. If you extend a reusable conversation, one request can both read an existing prefix and write additional cached content.

Cache eligibility also has model-dependent minimum lengths. A small marked block does not guarantee a cache write. Check the current requirements for the model and route rather than treating the marker as proof.

§ Line three: the usage fields

Cache write: In an Anthropic Messages response, cache_creation_input_tokens reports input tokens written to the cache. Ordinary input_tokens are reported separately.

Cache read: cache_read_input_tokens reports tokens served from the cache. These are also separate from ordinary input_tokens. output_tokens measures the generated answer in either case.

For a concrete side-by-side example, suppose the reusable prefix is 18,000 tokens and the changing portion is 2,000 tokens:

• Write request: input_tokens = 2,000; cache_creation_input_tokens = 18,000; cache_read_input_tokens = 0.
• Read request: input_tokens = 2,000; cache_creation_input_tokens = 0; cache_read_input_tokens = 18,000.

Both requests account for 20,000 input tokens across those categories. Neither makes the reference document disappear from the context window. Output tokens remain an additional category, and the answer length can differ between calls.

§ Line four: the cost calculation

Cache write: Multiply ordinary input tokens by the ordinary input rate, cache-creation tokens by the applicable write rate, and output tokens by the output rate.

Cache read: Replace the write component with cached-read tokens multiplied by the read rate. Do not charge the same cached tokens again as ordinary input when calculating from Anthropic’s separate usage fields.

The practical comparison is the full sequence: the initial write plus subsequent reads. A write can cost more than ordinary input, while a read can cost substantially less. Use the rates published for the actual model, cache duration, and Vana API route; do not assume direct-provider pricing automatically applies.

§ Line five: the next request

Cache write: A request after expiry may need to create the cache again. Claude’s standard ephemeral cache has a five-minute lifetime; a one-hour option exists where supported.

Cache read: Successful reuse refreshes the cache lifetime. Keep measuring the returned counters rather than assuming every later request hits.

If you switch to an OpenAI-compatible response format, verify its usage mapping before reusing an Anthropic-specific calculation. Cached-token details and cache-write reporting are not universally interchangeable.

Create a Vana API account to test this with two controlled requests. Keep the prefix fixed, change only the final question, and compare usage before comparing cost. Billing is per real token, with no monthly fee.