Is Prompt Caching Paying Off?

The FinOps Framework names the KPI official

Searching the framework for “cache hit rate” finds one KPI in its library:

The record has no formula, no data sources and is not featured on any capability page yet. It says what to watch, not how to compute it. That is the gap the next server fills.

framework · search_framework {query: "cache hit rate"} · get_kpis {slug: "cache-hit-rate"}

Tokenomics supplies the published formula quoted

What good looks like, per the cache explainer: “climb toward your workload's ceiling … A live chat can never reach 100% because the conversation grows, so track the trend against the structural ceiling, not toward perfection.”

A hit rate alone can't tell you whether caching saves money, because cache writes usually cost more than plain input. The explainer pairs it with a second metric:

Source status: Release Candidate 1 (2026-09-22) · “AI Tokenomics Prompt Cache Explainer”.

tokenomics · get_metric {metric: "cache-hit-rate"} · list_metrics {}

Run the numbers on two workloads

Both runs use 1 million input tokens at a $3 per million base input price, a 0.1× cache-read rate and a 1.25× cache-write rate. Those rates match the provider snapshot the server also serves (Anthropic: write 1.25× base with a 5-minute TTL, read 0.1× base). Only the mix of tokens differs.

The server interprets each result. For workload B:

The tool computes only what you pass in: output tokens, batch or committed-use discounts and contracted rates sit outside this input-side ratio, and it says so in every response.

tokenomics · calculate_cache_metrics {cache_read_tokens: 800000, cache_write_tokens: 50000, uncached_input_tokens: 150000, base_input_price_per_mtok: 3, cache_read_multiplier: 0.1, cache_write_multiplier: 1.25}

tokenomics · calculate_cache_metrics {cache_read_tokens: 100000, cache_write_tokens: 400000, uncached_input_tokens: 500000, base_input_price_per_mtok: 3, cache_read_multiplier: 0.1, cache_write_multiplier: 1.25} · get_provider_cache_snapshot {}

Find the lever, and what breaks it

Caching is the primary lever at L3, the inference stack:

For workload B, the assess_prompt_caching prompt gives the agent its checklist: put stable content first, growing content next and per-request content last; then flag what silently breaks the prefix: “timestamps, re-serialized JSON, tool list churn, model switches, router spreading load.” The last two connect caching to the model-routing demo: a router that switches a long session to another model re-reads the whole prompt uncached.

tokenomics · get_lever {lever: "l3-prefix-kv-and-semantic-cache"} · prompts/get assess_prompt_caching {workload: "support chatbot with a 6k-token system prompt"}

Where the token data lives in FOCUS

To track this KPI from billing data rather than provider dashboards, you need cache reads, writes and uncached input labelled per price. In the ratified FOCUS 1.2 that information can only travel in a general-purpose column:

FOCUS 1.5 adds standard properties for exactly this, in the working draft and due for ratification on 3 Dec 2026:

The tokenomics server states that link with its evidence and returns focus://spec/1.2/columns/skupricedetails for the FOCUS server to read. The draft property names have no URI, because no ratified FOCUS release contains them yet.

focus · get_column {column: "SkuPriceDetails"} · tokenomics · get_focus_ai_tracker {identifier: "TokenCacheAction"} · get_crosslinks {entity_type: "focus-item", slug: "fr-2099"}

Close the loop UNOFFICIAL

No Foundation page links the framework's KPI to the tokenomics metric, so the default surface doesn't either. With FINOPS_MCP_EXPERIMENTAL=1, the server's curated crosswalk does, and labels itself:

_UNOFFICIAL: curated crosswalk entries are this server's own mappings; no Tokenomics
Foundation page states them._

- metric **cache-hit-rate** → framework kpi **cache-hit-rate**
  (`finops://framework/kpis/cache-hit-rate`): Same name. The framework KPI describes
  the percentage of tokens used from cache without a formula; the Tokenomics Foundation
  formula supplies the denominator (cache read + cache write + uncached input).
- metric **cache-hit-rate** → framework capability **usage-optimization**
  (`finops://framework/capabilities/usage-optimization`): Raising cache hit rate removes
  recomputed input tokens, which is consumption reduction rather than a rate change.

tokenomics (FINOPS_MCP_EXPERIMENTAL=1) · get_crosswalk {entity_type: "metric", slug: "cache-hit-rate"}