You already run Valkey as a cache. Then a feature ships that calls an LLM, and you are suddenly paying seconds of latency and real money per request- behind a cache that never hits, because no two prompts are ever byte-identical.

Semantic caching fixes the key, not the cache. Embed the incoming prompt, find the nearest prompt you have already answered, and serve the stored response when similarity clears a threshold.

Valkey Search makes that a single FT.SEARCH- vector similarity, TAG scope and NUMERIC recency in one query, with no second datastore to run.

This session builds it in production terms:

1. the index schema, and the embed to search to threshold to serve loop
2. threshold tuning, where a false hit costs you more than a miss ever did
3. invalidation with per-field TTLs from 9.0, instead of blanket expiry
4. what it actually costs

We will walk hit rate, latency and spend before and after, including why the embedding step and not Valkey is usually the bottleneck.

You will leave able to cut LLM spend using the Valkey you already run.