BetterDB, MIT Valkey-native context layer for AI agents
Today we released an open, Valkey-native context layer for AI agents as part of our packages at BetterDB (agent memory, semantic + multi-tier caching, typed retrieval) that run on a Valkey instance no matter where it is - no vendor lock-in. We even started provisioning Valkey instances starting today. Packages are shipped on npm and PyPi. Why we made it: BetterDB originally started as a monitoring and observability platform for Valkey, Redis and any RESP compatible db. This is still the core of the product, but in the process of building this, we kept seeing that one of the fastest-growing…
What it does
In the maker’s words, at launch
Today we released an open, Valkey-native context layer for AI agents as part of our packages at BetterDB (agent memory, semantic + multi-tier caching, typed retrieval) that run on a Valkey instance no matter where it is - no vendor lock-in. We even started provisioning Valkey instances starting today. Packages are shipped on npm and PyPi. Why we made it: BetterDB originally started as a monitoring and observability platform for Valkey, Redis and any RESP compatible db. This is still the core of the product, but in the process of building this, we kept seeing that one of the fastest-growing uses of Valkey was AI - vector store and cache behind agents and RAG. So about a month and half ago we published MIT semantic and agent cache libraries for that, with the agent cache library not even requiring any modules and being able to run on vanilla Valkey. Today we are extending this to agent memory. Because we started with observability, it also runs everywhere - every cache, memory and retrieval emits OTel and Prometheus, plus it integrates well with our own monitoring and mcp server, exposing it to the agent. What we actually shipped: - agent memory: short-term tiers (session/LLM/tool, exact-match) plus a semantic long-term layer - semantic caching over valkey-search, with per-category thresholds and confidence bands - typed retrieval over valkey-search - a self-tuning loop and OTel/Prometheus observability (more below) What's not done yet: a Helm chart for one-command self-hosting, and a detailed benchmark writeup. Both next week. Self-tuning cache. The cache logs similarity scores, and a separate service reads the distribution and proposes threshold/TTL changes (with reasoning, weighted by cost). A human approves the change, and the running cache picks it up in under a second with no restart. An agent can read the live cache state and propose changes over MCP. I haven't found another cache library that closes this loop; most use a static, hand-tuned threshold, which is the documented failure mode for semantic caches. Observability at the operation level. OTel spans and Prometheus metrics on each cache/memory/retrieval operation, not just request-level LLM tracing. So you can actually see per-lookup similarity distributions and whether your threshold is wrong, rather than guessing. On benchmarks, the number isn't a flex: I ran LongMemEval on the memory layer. In the process of building our harness I found multiple things surpressing the scores. Even tweaking the prompt to the reader (the reader was told to answer only from literal excerpts so it abstained on whole question types), on a matched gpt-4o config the improvement was over 5 points. We'll be actively working on QA next week. Re-run everything and then publish a comprehensive write up. Retrieval recall is near-perfect at 98.4%, so the gap is reader/reasoning-side, not retrieval. The best part is ofc latency as Valkey's performance is great. What I'd genuinely like feedback on: does the Valkey-native bet make sense to you, or would you rather a context layer be storage-agnostic? And for those running agents in prod, would you trust automated self tuning recommendations, or prefer to keep it manual? Is cost or latency a bigger issue to be solved? We have a public unscripted demo at chat.betterdb.com btw, if anyone wants to see these libraries in action.
Does the same job
all alternatives →
- AAAn agent that tunes its own cacheMay 2026 · ▲7
The weekend of last week I built chat.betterdb.com as a RAG over Valkey/Redis/Dragonfly docs. The goal was to eat our own dogfood and test publicly our caching libraries. It also saved me from having to come up with various demo/test scenarios, as I could extend the building in public to the demo. There is a tool-result cache sitting between the SDK and tools. Each call is normalized and then checked before executing. If it hits we return from the cache, and if not, we check the semantic cache, which embeds the prompt and checks with KNN via valkey-search. If the cosine…
- BOBetterDB – OSS Valkey/Redis monitoring with historical dataJan 2026 · ▲6
Hey HN, I'm Kristiyan, former Engineering Manager for Redis' Visual Developer Tools (including Redis Insight). I built BetterDB because Valkey is growing fast but lacks proper observability tooling. BetterDB is a monitoring platform for Valkey (and Redis) that focuses on what existing tools miss: Historical persistence – Slowlog entries disappear when the buffer fills. BetterDB persists them so you can see what queries were running at 3am, which clients were connected, and what anomalies were detected — not just current state. Pattern analysis – Stop scrolling through raw slowlog entries.…
More ai this month
the category →
I trained a 125M-parameter transformer to autocomplete piano performances in real time (~108 notes/sec on an iPhone 15). The idea is basically GitHub Copilot or Tabnine, except instead of prompting it with code, you prompt it by playing a few notes on a MIDI piano. The model then continues what you played, entirely on-device. The app is free if anyone wants to try it. Happy to answer questions about the model, training, Core ML, or the many things that didn't work.
AI · 17d ago · simedw.com
Astute▲585Automate your B2B brand going viral, with new media creators
AI · 18d ago · company-app.joinastute.com
Hey HN, Henry from Cactus here! We previously released Cactus Needle, a 14MB agentic LLM for tool call, device use, and structured extraction for phones, wearables, smart homes, small robots and microcontrollers. We got really great feedback here, and have now incorporated the suggestions to release Needle 2. The whole model is a single 14MB binary that runs a full session in 28MB of RAM; 45m parameters at 2bit compression. Needle hits 500 tokens/sec decode speed on a Raspberry Pi 5, sits between 400-1,500 tokens/sec on VR devices like Meta Quest 3S and Apple Vision Pro, and ranges…
AI · 26d ago · cactuscompute.com
Launched alongside, June 2026
the whole month →
Fundraisly▲1,544AI fundraising agent that finds investors and books meetings
AI · Jun 2026 · fundraisly.com
- H6Homebrew 6.0.0▲1,481
Today, I’m proud to announce Homebrew 6.0.0. The most significant changes since 5.1.0 are a new tap trust security mechanism, the new faster, smaller, default internal Homebrew JSON API, sandboxing on Linux, better defaults informed by our user survey, many brew bundle improvements, improved performance and initial support for macOS 27 (Golden Gate). Happy to discuss any questions here!
Dev tools · Jun 2026 · brew.sh
- PU
hope you enjoy
Life & fun · Jun 2026 · vorpus.github.io
- IM
Life & fun · Jun 2026 · hackernewstrends.com