PMB

Stop re-explaining your project to AI coding agents

Open Source

Developer Tools

Artificial Intelligence

GitHub

Visit WebsiteSee on Product HuntGithub ⧉

The local SQLite memory feels like the right call for keeping project context off the cloud, but I'm curious what stops an old decision you reversed two sessions ago from still surfacing as if it's current when the agent reads back?

Love that the whole pitch is just "stop re-explaining your project" repeated like a mantra. That repetition actually sells it, because re-feeding context every session is the exact pain I feel daily with our coding agents.

Local-first memory for coding agents is interesting because context drift is usually where my sessions go sideways. I like that it avoids another hosted workspace. Curious how you handle stale project assumptions after a big refactor?

Love the local SQLite take. The staleness thing Dipankar raised kept biting me with Claude Code. Old assumptions resurfacing two refactors later, no way to tell whether the agent pulled them from memory or made them up. When a newer event reverses an older one without a clean key, does the dashboard surface "skipped because of X" or do I dig into events myself?

Every new Claude Code session I spend the first few minutes re-explaining the same architecture decisions. The local-first + MCP approach is the right call, once project memory lives in a third-party cloud it becomes a security conversation for any serious team. The part I'd want most is the impact tracking that shows which memories actually influenced agent suggestions. Context without attribution is just noise. Look forward to hearing from you.

this solves a real problem. the context re-explanation tax is probably the single biggest friction point in AI-assisted coding right now — you lose 10-15 minutes at the start of every session just getting the agent back up to speed on decisions you already made.

curious about the memory graph structure. how does it handle conflicting decisions? like if you stored "never use ORM" as a lesson but then later decided to add one for a specific service?

So if I have a session in Claude, it will have the memory to store the chat from claude and when I switch to chatgpt or others llms it wil pick up the left over work from claude?

the "no cloud, on your disk" call is the whole thing for me — local-first genuinely changes what people will put in their memory. building healthos on the same constraint. how's retrieval holding up as the graph grows into thousands of entities?

Love the local-first SQLite approach here; keeping project memory on-disk instead of a hosted service is a smart trust boundary, because sensitive architecture decisions and lessons learned never leave your machine.

Everything staying right here on my own machine is the part that lands for me, Oleksii. Repeating myself over and over has quietly been one of my least favorite parts of the day, so this feels like a real relief.

Keeping agent memory in one local SQLite file is a clean approach. Re-explaining project decisions across Claude Code, Cursor, and Codex gets old fast, so shared MCP memory could make coding sessions feel much less repetitive.

Persistent memory for coding agents is one of those features where “what not to remember” matters as much as what to store.

The part I’d be most curious to see is a small memory diff after each session: new lesson added, old assumption updated, and which memory actually influenced a suggestion.

That would make it easier to trust local memory instead of treating it like a hidden second prompt. Also helps catch stale project decisions before an agent keeps repeating them.

How do you decide what gets written into memory, like is it automatic from chats or only explicit saves?

But remembering also has a cost. Your front loading context. aka using a lot of the available context before solving a problem. That means your runway to solve it is smaller. How do you get around that? some times you need all the context runway you have 😅

the "no LLM call on the read" part is a nice detail. most memory solutions make an API call every time the agent needs context, which adds latency and cost to every single interaction. storing it in local SQLite and letting the agent pull what it needs without a round trip makes way more sense for coding workflows where speed matters. does it handle memory conflicts though? like when two sessions produce contradicting decisions about the same part of the codebase.

This is exactly the problem that makes AI coding feel like a conversation reset every 5 minutes. You paste context, it forgets, you paste again. The local-first memory angle is smart - keeping it in the project rather than some cloud sync feels like the right call for sensitive codebases. Does it handle monorepos where different agents might need different context scopes?

We run agents across multiple client projects simultaneously, so stale memory leaking into the wrong context is a real operational risk. The keyed fact system handling latest-wins with old value archived covers simple attribute updates, but I'm curious how it handles decisions that don't have a clean key (for exmaple, an architectural direction that got reversed mid-project without an explicit "we switched from X to Y"). Does the conflict surface in the dashboard, or does the old decision just keep scoring well on BM25 until someone manually archives it?

Boring demo video could have been much much better. Fix it if you want to onboard more customers! Still good product so upvoting :)