Memory, self-tuning caching, and retrieval for your AI agents

Durable memory with scoped, ranked recall; multi-tier caching that answers repeat work in under a millisecond; typed retrieval over your own data.
One SDK, observable at every layer, deployed anywhere you run Valkey.

Sub-ms cache hitsRedis-compatibleTypeScript + PythonNo vendor lock-in

Install the unified SDK:

Memory, caching, and retrieval in one install - one import root for the whole stack.

@betterdb/ai
npm install @betterdb/ai iovalkey

Docs →

One SDK, four capabilities

Memory, semantic caching, exact-match caching, and typed retrieval - bundled behind a single install and a single connection.

ONE INSTALL, ONE IMPORT ROOT
recall
Agent Memory
remember() · recall()
SCOPEagent:sess:*
RANKhybrid rerank
0.075
Semantic Cache
similarity ≥ 0.075
INDEXvector · HNSW
HITnear-duplicate
llmtoolsession
Agent Cache
llm · tool · session
TTLself-tuning
HIT RATE75%
0.940.710.550.380.22
Retrieval
search(typed)
MODELtext-embed-3-sm
K10 · reranked
One Valkey / Redis connection1connection4capabilities0extra services

Install everything, or pull in just the piece you need - the individual @betterdb/* packages ship on their own too.

Measured, not asserted

Recall barely drops as the haystack grows 10× on the same benchmark the category is measured by, while lookups stay sub-millisecond on infrastructure you control.

~93%

Recall at scale

holds from the small split (~98%) to LongMemEval-M — a ~10× larger haystack, 500 questions, ~475 sessions each — with hybrid rerank
0.7ms

p50 cache lookup

semantic-cache hit latency, roughly 100× faster than a hosted cache
Anywhere

deploy on any Valkey

run it on a Valkey you already operate, or let us provision a managed one — open core, built on open-source Valkey, no lock-in

Retrieval measured on the public LongMemEval-M split (k=10, hybrid rerank, text-embedding-3-small); cache latency from our Upstash comparison. Read the benchmarks →

The cache tunes itself

The agent reads live cache metrics, proposes a config change with its reasoning, and a human approves it. No other Valkey or Redis cache library does this.

CLOSED-LOOP SELF-TUNING
1Agent (via MCP)
mcp.callTool()
Reads hit rate, similarity distribution, tool effectiveness
2Proposal queue
status: pending
Threshold, TTL adjust, or targeted invalidation
3Human approves
BetterDB Monitor
Reviews the reasoning before anything ships
4Valkey
HSET :__config
Config written to the keyspace, atomically
5Cache library
polls, applies
Picks up the change in seconds, no restart
observes new behavior
AFTER APPROVALcache library
// Library picks up the change
// within seconds. No restart.
 
config poll production-semantic
threshold 0.075 (was 0.085)
applied atomically
 
hit rate 28% → 75%
SIMILARITY THRESHOLD
0.075applied
Tighter threshold, live in the library within seconds.
EFFECT
LLM hit rate75%
Saved / 150 hits$12.50
Cache lookup<1ms

The cache library polls its config key in Valkey and swaps the policy atomically - no restart, no redeploy. See the full closed-loop example

Dive into the details

Everything the SDK does - open a section when you want it, out of the way when you don't.

Add memory and caching to your agents

Install the SDK and get agent memory, semantic caching, and retrieval in one library. Self-host on a Valkey you already run — or let us provision a managed Valkey with the search module, no setup required.

BetterDB - Agent Memory, Caching & Retrieval on Open Valkey