Use case · LLM response cache

An LLM cache should save you money, not add a second meter.

Caching model responses is the highest-value cache you run: every hit skips a slow, paid API call. So you want a high hit rate and a generous cache — which means lots of lookups over larger payloads. On a per-command bill that becomes a tax on the exact behaviour you are trying to encourage. For a steady, high-lookup cache, compare flat-rate managed Valkey with PAYG and Fixed plans. Here is the monthly math, computed from source-checked rates.

Worked monthly cost (2 ops/request, 0.75 GiB)

Steada figures are launch pricing inputs, not an SLA-backed guarantee. Assumes2 Redis ops per cache lookup (GET on read, SET on miss) and 0.75 GiB of cached completions. Upstash: $0.20/100,000 commands +$0.25/GB above the free first GB; Steada live plan: $149/mo with 20% memory headroom and no command charge. Model your own lookup rate in the calculator.

The cache is supposed to save the expensive call

This example is an exact-key response cache, not a vector search service. Upstash Fixed plans may cost less than Steada. These PAYG-only examples exclude tax, transfer and add-ons; prices reviewed September 11, 2026. Check your client commands against the supported command surface.

A response cache exists to avoid the model call — the slow, metered, dollar-a-thousand-tokens part. The cache layer underneath it should be the cheap, boring part of the stack. When that layer is itself billed per command, you have re-introduced a meter on the path you built specifically to take off the meter. Worse, raising your hit rate — adding semantic lookups, widening the key space, caching more aggressively — increases lookups, so the better your cache works, the more the per-command layer charges. A flat tier removes that incentive conflict: cache as hard as you like at a fixed price.

Frequently asked questions

Why use Redis or Valkey to cache LLM responses?

A response cache keys on the prompt (or its hash/embedding) and returns a stored completion on a hit, so you skip a slow, paid model call entirely. Every cache hit saves real model spend and shaves seconds off latency — which is why the cache layer itself should be cheap and predictable, not a second meter that grows with traffic.

How much does an LLM response cache cost per month?

It scales with how often you check the cache, and cached completions are large. At 50 lookups/second and ~2 ops per request over 0.75 GiB, that is roughly 259M commands a month. On Upstash pay-as-you-go that runs about $518; on Steada's selected size tier it is about $149 for the same workload. Model your own lookup rate in the calculator.

Why does per-command pricing hurt an LLM cache specifically?

A response cache is double-taxed on a per-command meter: you pay per cache lookup and for storing the larger completion payloads. Semantic caching makes it worse, because a single request can fan out to several candidate lookups. The whole point of the cache is to drive your hit rate up — but a per-command bill punishes exactly the high lookup volume you are trying to encourage.

Can I move an LLM cache to Valkey without rewriting it?

Plain GET/SET exact-match caches can use a standard TCP Redis client after validating Steada’s compatibility list. Do not assume semantic or vector-cache integrations work: Steada does not offer Redis Stack search/vector modules. Test your library’s exact commands, TTLs and eviction settings. Upstash REST clients need a TCP-client adaptation.