Coding agents often send some of the same instructions and repository context over several turns. Prompt caching can let a supported model reuse eligible input instead of processing all of it as new input. The exact rules and prices depend on the provider and product. A cache hit rate is useful evidence, but it is only one part of the cost calculation.
What a cache hit rate measures
A cache hit rate should state which tokens are in its denominator and which cached tokens are in its numerator. It may describe cached input divided by total input, or it may use only the input eligible for caching. Those are not interchangeable. Ask for the raw cached input, uncached input, cache writes, output tokens, and the measurement period before interpreting a percentage.
A result such as 98 percent can mean that most eligible input was served from cache during one measured workload. It does not prove that every request, model, or coding CLI will see the same rate. It also does not mean that the total bill fell by 98 percent because cache reads are only one part of total usage.
Use the provider’s actual rates
For token billed usage, a simple estimate is: uncached input tokens multiplied by the uncached input rate, plus cached input tokens multiplied by the cache read rate, plus any cache write charge, plus output tokens multiplied by the output rate. Use the provider’s published pricing units and the usage fields from the product. If a product does not expose cache reads or writes, you cannot calculate that part precisely from the user interface alone.
A subscription or credit based product may not charge each field directly. In that case, treat cache metrics as technical telemetry, not as a promised cash saving. Check whether the product says cached input changes its usage meter. Do not assume that API pricing and a subscription allowance share the same accounting.
| Field | Why it matters |
|---|---|
| Uncached input | Shows how much input was processed as new context |
| Cached input | Shows the reused context counted by the provider |
| Cache writes | May have a separate charge or retention rule |
| Output tokens | Can remain a meaningful share of the task cost |
| Task outcome | Shows whether the same work was completed and accepted |
Benchmark warm and cold sessions separately
A cold run begins without reusable context. A warm run repeats a compatible prefix under the provider’s cache rules. Keep the prompt structure, model, repository, task, and timing comparable. Record whether the cache was expected to be warm, how long the test waited, and what the provider reported.
Do not compare one warmed run with another product’s cold run. Repeat each condition and publish the number of attempts. If the tool changes the prompt prefix, model, or context order between turns, it may change what can be reused. Follow the provider documentation for the actual cache behavior rather than guessing from the CLI interface.
Report the result without turning it into a slogan
A useful report gives the product and model version, account path, task, run count, cache fields, total cost method, and failures. If you publish a cache percentage, name the numerator and denominator. If you claim a savings amount, include the rates and the comparison baseline so a reader can reproduce it.
LucentraCode’s cache rate article explains how to interpret a result such as 98 percent. Use it together with the benchmark guide when comparing agents. A well defined cache measurement helps explain a workload; it does not establish a universal winner by itself.