Cache-Pot is a Redis-compatible in-memory data store, rebuilt for how AI apps and agents use a cache. Speak plain RESP2, your existing Redis client works untouched. On top: native vector search, a semantic cache (skip repeat LLM calls when a question means the same thing), a built-in MCP server so agents like Claude use it as a first-class tool, and a live web dashboard. All in one self-contained binary, no modules, no extra services.
Hey Product Hunt π
I built Cache-Pot because every AI project I touched ended up duct-taping the same three things onto Redis: a vector store, a semantic cache, and some bridge so an agent could actually use the cache as a tool. So I built them in.
What it is:
- **Redis-compatible core** β talks RESP2, so `redis-cli` and your existing Redis client work as-is. Point `REDIS_URL` at it and go.
- **Vector search** β `VSET` / `VSEARCH`, backed by a hybrid brute-force + HNSW index. No API key needed, you supply the vectors.
- **Semantic cache** β `SCACHE.SET` / `SCACHE.GET THRESHOLD 0.9`. Ask something close to a question you cached before, get the stored answer instead of paying for another model call.
- **Agent memory** β `REMEMBER` / `RECALL`, a simple key-value scratchpad scoped per session.
- **Native MCP server** β `cache-pot mcp` β Claude (or any MCP client) reads/writes/searches/remembers through it directly, no adapter layer.
- **Dashboard** β full web console baked into the binary: key browser, live profiler, slowlog, pub/sub, memory analysis, client list.
- **Single binary** β `go install` or Docker, nothing else to stand up.
Honest limits: no clustering/replication yet, and it's not chasing raw-throughput records against Redis/Valkey β it's built for single-node AI workloads, not to replace a Redis cluster in prod.
It's BSD-3-Clause, free, and open source, repo's linked above. Would love bug reports, "tried it with my client X" notes, and PRs, most open issues are scoped small with acceptance criteria already written, good for a first contribution.
Thanks for checking it out!
Report
One thing that would make this even more useful for me: built-in TTL policies tied to semantic similarity scores, so near-duplicate entries auto-expire before drifting too far from the original. Right now the semantic cache seems to grow forever unless I set a hard TTL manually, and that can lead to stale answers sneaking through.
CodeNearby
One thing that would make this even more useful for me: built-in TTL policies tied to semantic similarity scores, so near-duplicate entries auto-expire before drifting too far from the original. Right now the semantic cache seems to grow forever unless I set a hard TTL manually, and that can lead to stale answers sneaking through.