# OpenRouter prompt caching: verifying savings in usage data

Verify OpenRouter prompt-caching savings using comparable requests, cached-input usage, actual charges and the provider route that processed them.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/openrouter-cache-cost/
Language: en

OpenRouter prompt caching can reduce repeated processing of a supported prefix, but savings must be verified through actual usage and charges. Similar messages and lower latency do not prove caching. Rules depend on the model and provider, so start with the selected executor's documented behavior and the exact request format.

## Identify the repeatable prefix

Separate the stable instruction or document prefix from the changing question. Some routes use automatic caching; others require explicit marking. Preserve the exact request and any cache-related settings rather than assuming semantic similarity is enough for a hit.

Use non-sensitive test content and keep the model, route and generation settings fixed. An application that reorders messages, changes a timestamp or rewrites the prefix may create a different input even when the user sees the same document. Record that transformation as part of the test.

## Keep a control and a repeat

Send a bounded initial request, then an appropriate repeat under the documented conditions. Save input and output token counts, available cached-input information, route identity and actual cost. A comparable workload is necessary: a shorter second answer can cost less without any cache benefit.

Measure latency separately from accounting. Server load, network conditions and output length can all change the response time. If the platform exposes cache usage, interpret that field according to its documented meaning rather than deriving a hit solely from a stopwatch.

## Limit the conclusion to the observation

| Observation | Supported conclusion |
| --- | --- |
| The answer is faster | Latency changed; its cause remains unproven |
| Usage identifies cached input | There is evidence to inspect cache accounting |
| Comparable total task cost falls | Savings are observed under the test conditions |
| The provider changes | Prior cache state cannot be assumed at the new target |

Save provider-selection settings alongside the cache experiment. Routing influences where repeated context is processed. A fallback may change both cache availability and accounting, so identify it rather than combining all attempts into an unexplained average.

## Calculate the complete cycle

Include the initial request, repeats, outputs, retries and any applicable cache-related charges. The useful question is whether the complete representative workload costs less while preserving required quality and latency. One discounted repeat does not describe every future task or every provider.

For a GPU owner, caching also changes how a workload uses compute, so it should be part of a measured profile. For an operations funder, use the full cycle rather than a headline discount in the budget.

Official references: [openrouter.ai — prompt caching](https://openrouter.ai/docs/guides/best-practices/prompt-caching), [openrouter.ai — provider selection](https://openrouter.ai/docs/guides/routing/provider-selection).

Related guides: [OpenRouter usage: reconciling tokens and request cost](/journal/openrouter-usage-accounting/), [OpenRouter provider routing: the difference between only and order](/journal/openrouter-provider-only-order/).