// cost-auditBlogMethodologyDashboardConnect the proxy →

Savings accounting methodology

A savings dashboard is only worth what its baseline is worth. Providers now cache automatically, so part of any workload's cache savings would have happened with no optimization layer at all. A dashboard that claims all of it is overclaiming to an audience that can read cache_read_input_tokens in their own API responses. This page defines exactly what our numbers mean, so you can audit any of them against your own provider invoice.

The six invariants

  1. Savings are reported net. Gross cache-read savings, minus cache-write premiums (Anthropic bills 1.25x the input rate for 5-minute-TTL writes and 2x for 1-hour writes; that is real money on your invoice), minus nothing hidden. When we report a monthly figure against a subscription, the subscription price is shown next to it.
  2. Savings are attributed in three buckets, shown separately: provider-automatic (what the provider's own automatic caching would have captured on your current prompt structure with no CacheGap), CacheGap optimization (what our restructuring and write decisions added beyond that counterfactual), and unrealized/available (the remaining gap to the achievable rate for your workload shape).
  3. The headline metric is the Realized Discount Rate (RDR): your effective input cost divided by list input cost, reported alongside the achievable rate our optimizer estimates for the same traffic. We sell the gap between those two numbers, so both must be computed honestly or the product is meaningless.
  4. Every number is auditable per request. For each request we persist the baseline cost (same request, same model, no optimization), the as-is counterfactual (provider-automatic caching alone), the actual cost, the savings split by bucket, the cache hit type, token counts (input, cached-read, cache-write, output), and the routing decision. Non-streaming responses carry x-cachegap-baseline-usd, x-cachegap-actual-usd, and x-cachegap-savings-usd headers; streaming savings are delivered at stream end and via the receipts endpoint, which is authoritative.
  5. All percentage claims are scoped to input tokens. Prompt caching discounts input only. Output and reasoning tokens, a growing share of agentic spend, are untouched, and every projection we show includes your input/output split so the scope is visible, not buried.
  6. Do no harm. A cache written and never re-read within its TTL costs more than not caching. We emit cache writes only when the observed within-TTL reuse rate clears the write-premium break-even with statistical confidence (we gate on the Wilson 95% lower bound, not the point estimate). New customers start in shadow mode: we observe and project before a single request is modified, and any internal error fails open to your raw, untouched request.

The baseline, precisely

The baseline for a request is the cost the exact same request would have incurred against the same model with no optimization: all input tokens at the list input rate, all output tokens at the list output rate. The as-is counterfactual then models what the provider's automatic caching alone would plausibly have captured given your current prompt structure. Only the difference between the as-is counterfactual and your actual cost is claimed as CacheGap-attributed savings. Requests below the provider's minimum cacheable prefix (about 1,024 tokens on Anthropic) are never claimed as optimized.

What we deliberately do not do

Auditing us

Compare any x-cachegap-baseline-usd figure against your provider's published per-MTok pricing and the usage block the provider returns on the same response. Compare monthly dashboard totals against your provider invoice. If you find a discrepancy, that is a bug, and we want it reported: the connect docs include the current contact route.