The repeated prefix on a smaller token bill
A coding assistant may send the same repository instructions dozens of times while the actual question changes. A document workflow may repeatedly attach the same reference material. Prompt caching can reduce the cost of that repeated input, but the saving depends on which tokens qualify, whether the cache survives between requests, and how the underlying provider prices it.
The useful comparison is not a shorter prompt against a longer one. It is the same workload with ordinary input billing on one side and eligible cached input on the other.
§ The same request, two billing paths
- Without a cache hit: Repeated instructions and reference material are billed as ordinary input tokens. Each request pays the applicable input rate, even when much of its content matches earlier requests.
- With a cache hit: An eligible, previously cached prefix can receive a different input rate. New instructions, the changing question, and other uncached content remain ordinary input. Generated output is still billed separately.
Caching is not a stored answer. The model still generates a response to the current request. It also does not create extra context-window capacity: cached material remains part of the request context.
§ A worked bill, with hypothetical rates
Suppose each of 20 requests contains a stable 10,000-token prefix and 1,000 tokens of changing input. Assume ordinary input costs $2 per million tokens and cache reads cost $0.20 per million. These are illustrative figures, not Vana API prices.
- Without caching: All 220,000 input tokens are billed at the ordinary rate. Input cost: $0.44.
- With caching: Assume the first request establishes the cache at the ordinary rate, with no additional write charge, and all 19 later requests hit it. The bill includes 31,000 ordinary input tokens and 190,000 cached input tokens. Input cost: $0.10.
That is roughly a 77% reduction in input cost, not necessarily in the total bill. Output charges are unchanged in this comparison. A provider that charges extra for cache creation, requires a minimum prefix length, or expires the entry before reuse produces a different result.
§ Stable context beside changing context
- Cache-friendly layout: Put stable instructions, tool definitions, and reusable reference material first. Place the changing question later. Keep the reusable prefix consistent across requests.
- Cache-unfriendly layout: Put a fresh timestamp, random identifier, or changing summary before the reference material. Even a small early change can prevent reuse of the otherwise identical content that follows.
Providers differ in how they recognize eligible prefixes. Some support automatic caching; others expose explicit cache controls or separate cache resources. Message order, tool definitions, and content changes can affect matching. OpenAI-compatible request formatting alone does not guarantee identical caching behavior across providers.
§ Repeated sessions beside occasional requests
- Frequent reuse: A substantial shared prefix sent repeatedly within the applicable cache lifetime is a promising candidate. More successful reads can spread any cache-creation cost across more requests.
- Sparse reuse: A short prompt sent once, or repeated only after its cache expires, may save little or nothing. Explicit cache storage or write charges can make low-reuse workloads less economical.
Do not add irrelevant text merely to reach a caching threshold. Compare the complete cost of the useful workload, including cache creation, reads, storage where applicable, ordinary input, and output.
§ Estimated savings beside measured savings
Vana API provides one OpenAI-compatible endpoint at https://api.vanaapi.com and also speaks Anthropic Messages and Gemini native protocols. That makes request integration convenient, but caching remains a model-, provider-, and route-specific capability. Before relying on it, check the supported cache controls, applicable prices, and available usage reporting for your chosen route.
Vana API bills per real token with no monthly fee. Create an account to test a representative repeated-prefix workload, then compare reported cached usage and actual charges with an uncached baseline. Keep output length and task mix comparable. A smaller measured bill is stronger evidence than a prompt that merely looks cacheable.