Skip to main content
Cache-Pot provides three ready-to-use building blocks for AI-powered applications: semantic caching to cut LLM costs by reusing answers to similar questions, vector search for similarity-based retrieval in RAG pipelines, and agent memory for stateful sessions that survive across turns. All three are exposed over the same RESP2 connection your existing Redis client already speaks — no extra services, no SDKs to install.

Pattern 1: Semantic response caching

Save LLM responses keyed by meaning, not by exact text. When a user asks something semantically equivalent to a question you have already answered — even if the wording is completely different — Cache-Pot returns the stored response instead of making another model call.
SCACHE.GET and SCACHE.SET require an embeddings provider. Set CACHEPOT_EMBED_URL and CACHEPOT_EMBED_KEY on the Cache-Pot server before using these commands. A free local Ollama instance or an OpenAI API key both work.
You can tune how closely a new question must match a stored one by passing an explicit THRESHOLD:
Cache-Pot tracks hit and miss counts and surfaces a running hit ratio on the dashboard at http://localhost:8080 — every hit is a model call you did not pay for. Store document embeddings and retrieve the most relevant ones for retrieval-augmented generation (RAG). Your application produces the embeddings; Cache-Pot stores and searches them with cosine similarity.
All vectors in a collection must share the same dimension, fixed by the first VSET call. VDIM documents returns the dimension of an existing collection. VCARD documents returns the number of stored vectors.
A full RAG loop — index at write time, search at query time, inject top results into the prompt — needs only these two functions plus your LLM call:

Pattern 3: Agent session memory

Store per-user or per-session state that persists across agent turns. REMEMBER writes a named field into a session namespace; RECALL reads one field or the entire session back.
Recall a single field instead of the whole session by passing the field name:
REMEMBER and RECALL are backed by a per-session hash named mem:<session>. You can inspect or edit session memory directly with HGETALL mem:<session> using any Redis client or the Cache-Pot dashboard.

Putting it all together

Combine all three patterns in a single agent pipeline: check the semantic cache → recall session memory → search the vector store for context → generate a response → update the cache and memory. The entire loop runs over one RESP2 connection with no extra services.