No cache-hit-rate instrumentation found
PrefixAudit rule no-cache-metric · v0.1.0
Why it breaks your cache
Caching failures are invisible until the invoice arrives. A hit rate that starts at 72% and decays to 18% pages nobody. Every provider returns the fields you need, and a 10-point drop in a 24h window almost always means a deploy changed the prefix.
How to fix it
Log cache_read_input_tokens (Anthropic), cached_tokens (OpenAI) or total_cached_tokens (Gemini) on every call. Alert on N consecutive zeros after warm-up, and on a >10pt drop in a rolling 24h window.
How common is it?
This rule needs request or runtime context that an extracted prompt cannot supply, so it is excluded from the corpus study. It still runs in the auditor when you supply that context.
Estimated impact
Modelled as invalidating 0% of the cached prefix.
Is your prompt affected?
Paste it and find out. Static analysis, in-browser, nothing leaves the page.
Run the audit →