Prompt caching can make repeated AI coding requests less expensive and faster to process. A number such as “98% cached” sounds simple, but it can describe only one part of a request. To understand the result, ask what counted as input, which tokens were eligible for reuse, how the provider priced cache reads and writes, and whether the number came from a real coding workload.
A cache hit rate is not a savings rate
A cache hit happens when a request can reuse a matching part of an earlier prompt. Coding agents often repeat stable instructions, tool definitions, and repository context across turns. The user’s latest request, changed files, new tool output, and test results may still be new input that must be processed.
A cache hit rate usually compares cached input tokens with a stated total of input tokens. Vendors can expose different fields and boundaries, so use the provider’s definition. OpenAI documents cache read tokens and recommends calculating hit rate from cached tokens divided by total input tokens. Anthropic reports cache reads, cache creation, and uncached input separately. Google documents implicit caching for supported Gemini API models. These are provider features; a CLI’s prompt structure can affect reuse, but the CLI name alone does not establish a cache rate.
| Measure | What it tells you | What it does not prove |
|---|---|---|
| Cache hit rate | How much measured input was read from cache under the provider’s definition | The discount on the full request or monthly plan |
| Cached input price | What a reused input token costs for that model and cache period | The cost of new input, output, tools, or retries |
| Input cost change | The difference between cached and uncached input charges | The same percentage change in the complete coding task bill |
| Time to first output | How long the request took to begin returning a result | That the agent completed correct code faster |
What a 98% example could mean
Consider one million measured input tokens. If 980,000 are cache reads and the provider charges five percent of its normal input price for those reads, the cached input portion costs 69,000 normal price units: 980,000 multiplied by 0.05, plus 20,000 uncached tokens. In that simplified example, input spending is 93.1 percent lower than sending all one million tokens at the regular input rate.
That calculation assumes cache writes cost nothing and looks only at input. A real request can have cache creation charges, output tokens, uncached context, tool calls, and retries. Those costs remain. The 98 percent figure also depends on the workload: a stable, repeated task can produce a different result from a new feature request that changes the repository context every turn.
- Write down the provider, model, and cache lifetime.
- Record cache reads, cache writes, uncached input, and output separately.
- Apply the price for each token type instead of one blended rate.
- Compare total request cost and completion time with a cold run.
Why coding agent cache results vary
Prompt caching generally depends on a reusable prefix. If a changing timestamp, selected file list, or tool result appears before the stable context, a later request may no longer match the earlier prefix. Changing the model, instructions, tools, or project state can also affect eligibility. Providers set their own minimum prompt sizes, cache lifetime, and pricing rules.
A useful report separates cold requests from warm requests and repeats the same task several times. Include the CLI version, model identifier, provider, repository commit, prompt, settings, timing between turns, and the usage fields used in the calculation. Report a typical result and the range, not only the single best run.
How to evaluate a 98 percent claim
Ask whether the percentage is a cache hit rate, an input price discount, a reduction in total bill, or a reduction in latency. Ask for the model and provider, sample size, denominator, date range, and workload. A number without those details cannot tell you whether it applies to your repository or plan.
OpenAI, Anthropic, and Google publish prompt or context caching documentation for their model APIs. That means it is inaccurate to describe caching itself as exclusive to one coding CLI. A fair product comparison should test the actual agent and model configuration, then publish the method and limits alongside the result.
LucentraCode’s supported model list and plan page are the right places to confirm current model availability and usage terms. This article does not assign LucentraCode a cache hit percentage because the public product information reviewed here does not include a reproducible cache benchmark.
Make the number useful for your own work
Choose a task that resembles your normal coding sessions, such as a focused bug fix followed by a test failure and a correction. Keep the project state and model fixed, run both cold and warm sessions, and compare accepted changes, input cost, total cost, and review time. That turns a headline percentage into information you can use to choose a tool.