Show HN: Core – open source memory graph for LLMs – shareable, user owned (github.com)

I don't see the advantage over a simple text file accessible by MCP. Could you elaborate?

It certainly looks interesting, how does this differ from a plan.md?

For those asking how this is different from a simple text based memory archive, I think that is answered here:

--- Unlike most memory systems—which act like basic sticky notes, only showing what’s true right now. C.O.R.E is built as a dynamic, living temporal knowledge graph:

Every fact is a first-class “Statement” with full history, not just a static edge between entities. Each statement includes what was said, who said it, when it happened, and why it matters. You get full transparency: you can always trace the source, see what changed, and explore why the system “believes” something. ---

how would you say you compare to graphiti from zep?

I've been building a memory system myself, so I have some thoughts...

Why use a knowledge graph/triples? I have not been able to come up with any use for the predicate or reason to make these associations. Simple flat statements seem entirely sufficient and more accurate to the source material.

... OK, looking a little more, I'm guessing it is a way to see when a memory should be updated; you can match on the first two items of the predicate. In a sense you are normalizing the input and hoping that shows an update or duplicate memory.

I would be curious how well this works in practice. I've spent a fair amount of effort trying to merge and deduplicate memories in a more ad hoc way, generally using the LLM for this process (giving it a new memory and a list of old memories). It would feel much more deterministic and understandable to do this in a structured way. On the other hand I'm not sure how stable these triples would be. Would they all end up attached to the user? And will the predicate be helpful to establish meaningful relationships, or could the memories simply be attached to an entity?

For instance I could list a bunch of facts related to my house: the address, which room I sleep in, upcoming and past repairs, observations on the yard, etc. Many (but not all) of these could be best represented as one "about my house" memory, with all the details embedded in one string of natural language text. It would be great to structure repairs... but how will that work? (my house, needs repair, attic bath)? Or (my house, has room, attic bathroom) and (attic bathroom, needs repair, bath)? Will the system pick one somewhat arbitrarily then, being able to see that past memory, replicate its structure?

Another representation that occurs to for detecting duplicates and updates is simply "is related to entities". This creates a flatter database where there's less ambiguity in how memories are represented.

Anyway, that's one area that stuck out to me. It wasn't clear to me where the schema for memories is in the codebase, I think that would be very useful to understanding the system.

So, this is cool and a per-user memory is obviously relevant for effective LLM use. And major props for the temporal focus.

However, keeping a tight, constrained context turns out to actually be pretty important for correct LLM results (https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-ho...).

Do you have a take on how we reconcile the tension between these objectives? How to make sure the model has access to relevant info, while explicitly excluding irrelevant or confounding factors from the context?

> Local Setup > Prerequisites > OpenAI API Key

This does not seem to be local and additionally appears to be tied to one SaaS LLM provider?

I love how we have come full circle. Anybody remembers the "semantic web" (RDF-based knowledge graph)? It didn't take off because building and maintaining such a graph requires extensive knowledge engineering work and tools. Fast forward a couple of decades and we have LLMs, which is basically auto-complete on steroids based on general knowledge, with the downside that it doesn't "remember" any facts unless you spoon-feed it with the right context. We're now back to: "let's encode context knowledge as a graph and plug it into LLMs". Fun times :)

Why do open source projects do not version control their CLAUDE.md?

I’ve been thinking about how to do this well, how my memory actually works. I think what is happening is I’ve either got the facts now (that is easy to repro w/ a system like this) or I’ve got an idea that I could have the facts after working on retrieval. It’s like I’ve got a feeling or sense that somewhere in cold storage is the info I need so I kick off a background process to get it. Sometimes it works.

That second system, the “I know this…” system is I think what is missing from these LLMs. They have the first one, they KNOW things they’ve seen during training, but what I think is missing is the ability to build up the working set as they are doing things, then get the “feeling” that they could know this if they did a little retrieval work. I’ve been thinking about how to repro that in a computer where knowledge is 0|1, but could be slow to fetch

Does this work with Claude?

Cool!

Hey, we should talk. If your project is stable might have a collaboration that would align us both.

I have a functional UI for storing the knowledge base between my AI agents and can have an MCP server functional within a couple of days.

Right now it accesses personal instances of AI engines or the cloud, but Builds my private local knowledge base in the process. I can import in 1s from other systems as well.

Instant, navigable, lighting fast, local ui for managing my ais memory. I use semantic search for the lookups as of the moment.

Sounds like perhaps the 2 tools together would add to each other.