A cache-hit badge is not a savings report. It can describe a reused prefix, one reused action in a long workflow, or an entire reused result. To understand the economics, record what was reused and what work still happened.
Request hit rate and token hit rate answer different questions
Request hit rate is the number of requests with a hit divided by eligible requests. Token hit rate is the number of input tokens read from cache divided by total input tokens, using your provider’s definitions.
Consider a hypothetical ten requests containing 10,000 input tokens each. Assume the reused prefixes meet the selected model’s cache requirements. If nine requests reuse 2,000 tokens apiece, request hit rate is 90%, but just 18,000 of 100,000 input tokens were reused: an 18% token hit rate. Both figures are correct. Only one describes the share of input covered by the cache.
Keep provider usage categories separate
The Claude Messages API reports ordinary input, cache creation and cache reads separately. Its documentation explains that total input combines those categories; ordinary input_tokens alone is not the entire prompt size. Use each category’s applicable rate when calculating spend.
Normalize your application’s records carefully when comparing providers. Do not add a cached-token detail field to a total that already includes it. Preserve the original usage response so you can audit a billing calculation later.
A cache can have an up-front cost
Use this simple application-cache model: S is an extra one-time setup cost, separate from per-task execution; U is the uncached cost per task; and H is the all-in cost of a valid warm hit. Across N equivalent tasks, uncached cost is N × U; cached cost is S + N × H. Costs are equal when N × (U − H) = S. Net savings begin only when N × (U − H) > S. This comparison assumes U > H; otherwise reuse never repays a positive setup cost.
For a hypothetical example, let setup cost $0.40, uncached execution cost $0.10, and validated warm execution cost $0.02. Each reuse saves $0.08, so five tasks recover setup cost and six tasks produce a net saving. These are made-up application costs, not provider prices or Frugent benchmark results.
The example assumes every task is a valid warm hit and success rates stay equal. Expiry, invalidation, failed lookups and repairs make the real calculation less favorable. Count those paths instead of excluding them.
Separate cold, warm and repaired runs
Label first-time setup, valid reuse, cache misses and repair attempts. Compare similar task types and website states. A warm run should not be compared with a much harder cold task just because their titles look similar.
For browser workflows, record model tokens and inference time separately from page loading, browser execution and human waits. A faster model response does not necessarily mean the whole task finished sooner.
Use a quality gate before claiming savings
Define success before the experiment: the correct report, the correct account, the expected record, or another observable result. Include all attempt costs, then divide by successful completions. A cheaper failed run should not count as a win.
When reporting a result, name the workload and sample size, explain the baseline, separate measured usage from estimates, and disclose missing data. Prefer “these runs used fewer recorded input tokens” to an unsupported claim about total dollars saved.
What to track next
A useful report includes eligible requests, request hits, cached input tokens, ordinary input tokens, cache writes, output tokens, retries, successful tasks, total charges and end-to-end duration. Add cache age and invalidation reason if maintenance is important to the workload.
Frugent treats reused browser actions and recorded model usage as separate signals. That distinction matters: an action hit is evidence of reuse, while a cost claim needs a complete, comparable baseline.