Every SerpApi call, cache decision and credit, live.
Each lookup is an exact Redis hit, a semantic hit, or a SerpApi call that costs one credit. Run it twice: the second run is free.
How a query decides whether to spend a credit
Every SerpApi request goes through serpapi_cache: a drop-in replacement for serpapi.Client.search(). Similar questions reuse answers; different doses never do.
Lowercase, collapse spaces, glue units to numbers.
SHA-256 of the params. One Redis GET, no model: under 5 ms.
MiniLM turns the query into 384 numbers; cosine similarity against every cached query.
Close meaning but different numbers? Never reuse. A wrong dose is worse than a credit.
Only now is a credit spent. The result is written to Redis on a background thread, so the user never waits for it.
Ask the cache what it would do
Type any query. It runs the same decision on the live Redis contents and shows the nearest cached queries with their similarity scores. Nothing is sent to SerpApi.
What is cached right now
Raw SerpApi responses, product-page lookups and Gemini spelling decisions, each with its own TTL.
| cached query | type | expires in | size |
|---|
What the cache has saved since this server started
Every number is measured from real calls on this machine, not estimated from a formula.