PMB

Stop re-explaining your project to AI coding agents

Open Source

Developer Tools

Artificial Intelligence

GitHub

Visit WebsiteSee on Product HuntGithub ⧉

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 :)

PMB’s local SQLite + no read-path LLM claim is the part I’d test first. The hard bit with project memory is not storing more facts; it’s deciding when an old fact should lose authority.

Do you track expiry or conflict per memory item? For example, if a repo switches from REST to GraphQL, I’d want the old REST decision preserved as history but not injected into a fresh coding-agent context unless the current file still touches that path. The dashboard would be more useful if it shows not just “this memory helped”, but “this memory was skipped because it conflicted with newer evidence.”

@oleksiijko - Very nice. Definitely beats managing multiple .md files locally with skill integration. Will review in more detail, but looks very promising.

Local-first append-only is the right base. The thing that actually bit us running a file-based memory like this for our own agents was staleness: the agent confidently acted on a decision that had been reversed two sessions back, because the old event was still sitting on the read path. Append-only sharpens that, since both the decision and its reversal live as events. Does the read path collapse to current state, or can the agent pull a superseded decision and treat it as live?

The core problem is real. Every new context window means re-explaining architecture decisions, naming conventions, the reason you made that weird choice in the auth layer three months ago. Curious whether PMB is basically a structured prompt file that lives in the repo, or whether there's something more dynamic happening, like the context getting selectively injected based on what part of the codebase the agent is touching. Also wondering how you handle drift, because the project memory that was accurate at week two is often wrong or incomplete by month six, and a stale context file might be worse than no context file.

Curious how PMB handles context boundaries in practice — is it meant to store high-level project docs, repo-specific conventions, current tasks, or some mix of those?

The re-explaining loop between sessions is exactly what drives me nuts with Cursor and Claude Code, so local SQLite memory over MCP feels like the right call. How are you deciding what gets stored automatically vs what I have to tell it to remember? congrats on shipping.