What prompt caching does
Many LLM applications send a large, unchanging block on every request — a long system prompt, a set of tool definitions, a reference document, or a batch of few-shot examples — followed by a small, variable user message. Without caching you pay full input price for that whole block every single call. Prompt caching lets the provider store the stable prefix after the first call and charge a fraction of the price to reuse it.
This analyzer tells you whether your prefix is big enough to cache and how much you would save.
How it works
Paste the stable portion of your prompt. The tool estimates its token count and checks it against Anthropic’s 1024-token minimum — blocks smaller than that cannot be cached, so it tells you how many more tokens of stable content you would need. If the prefix qualifies, it models the economics:
- First call writes the cache at about 1.25× the base input price.
- Every subsequent call reads it at about 0.1× the base input price.
It compares the total cost across your expected reuse count against paying full price every time, and reports the dollar saving and percentage. With a large prefix reused many times, the saving routinely lands above 80%.
Tips
- Put only the stable part before the cache breakpoint. Anything that changes per request — the user’s question, dynamic context — must come after the cached prefix, or the cache never hits.
- Order matters: caching works on a prefix, so structure your messages with the most stable content first (system, tools, documents) and the variable content last.
- Caching pays off with frequency. The cache lifetime is short (about five minutes, extended on each hit), so it shines for high-traffic endpoints and tight agent loops, not occasional one-off calls.
- These figures are estimates for planning. Confirm token counts with the provider’s tokenizer and current prices before committing to a budget.