Show HN: Core – open source memory graph for LLMs – shareable, user owned

hey, thanks for the article reference. i read it.

that's the exact problem we've been solving! Context bloat vs. memory depth is the core challenge.

our approach tackles this by being selective, not comprehensive. We don't dump everything into context - instead, we:

- use graph structure to identify truly relevant facts (not just keyword matches) - leverage temporal tracking to prioritize current information and filter out outdated beliefs - structure memories as discrete statements that can be included/excluded individually the big advantage? Instead of retrieving entire conversations or documents, we can pull just the specific facts and relevant episodes needed for a given query.

it's like having a good assistant who knows when to remind you about something relevant without overwhelming you with every tangentially related memory.

the graph structure also gives users more transparency - they can see exactly which memories are influencing responses and why, rather than a black-box retrieval system.

ps: one of the authors of CORE

You've identified a fundamental gap - that meta-cognitive "I could retrieve this" intuition that humans have but LLMs lack.

Our graph approach addresses this: - Structure knowledge with visible relationship patterns before loading details

- Retrieval system "senses" related information without fetching everything

- Temporal tracking prioritizes recent/relevant information

- Planning recall frequency tracking for higher weightage on accessed facts

In SOL(personal assistant), we guide LLMs to use memory more effectively by providing structured knowledge boundaries. This creates that "I could know this if I looked" capability.

I'm not sure the graph offers any clear advantage in the demonstrated use case.

It's overhead in coding.

The source is the doc. Raw text is as much of a fact as an abstracted data structure derived from that text (which is done by an external LLM - provenance seems to break here btw, what other context is used to support that transcription, why is it more reliable than a doc within the actual codebase?).

Hey we are actively working on improving support for Llama models. At the moment, CORE does not provide optimal results with Llama-based models, but we are making progress to ensure better compatibility and output in the near future.

Also we build core first internally for our main project SOL - AI personal assistant. Along the journey of building a better memory for our assistant we realised it's importance and are of the opinion that memory should not be vendor locked. It should be pluggable and belong to the user. Hence build it as a separate service.

You can run OpenAI compatible servers locally. vLLM, ollama, LMStudio and others.

Hey - agreed that for basic fact recall, a simple text file + MCP works fine.

We designed CORE for complex, evolving memory where text files break down.

Example: Health conversations across ChatGPT, Claude, etc. where your parameters change over time.

A text file can't give you: "What medications have I tried, why did I stop each one, and when?" or "Show me how my symptoms evolved over 6 months."

For timeline and relational memory, CORE wins. For static facts, text files are enough i guess.

I don't know this project, but the is probably simplicity/performance benefits to using a proxy over MCP as in theory there is less overhead.

Hey plan.md mostly will be a static file that you manually have to maintain. It won't be relational and not be able to form connections between info. You can't recall or query intelligently? (When did my preference change?)

CORE lets you - Automatically extracts and stores facts from conversations - Builds intelligent connections between related information - Answers complex queries ("What did I say about something and when?") - Detects contradictions and explains changes with full context

For simple fact recall, plan.md should work but for complex systems a relational memory should be able to help better.

I built a graph memory MCP tool as well. I don't use triplets, instead I generate nodes. The node is composed of (id, title, text) and text can contain links inlined, like @45, referencing past nodes. So it can create both a node and its relations in one tool call.

My MCP has two tools - a search tool and a node adding tool. The search tool uses embedding similarity to retrieve K nodes, then expands on links and fetches another P nodes. By controlling K and P the LLM can choose to use the graph as a simple RAG or as a pure linked graph, or anywhere in-between. In practice I use Claude which is able to do deep searches. What it does not find in one call it locates in 4-5 calls.

The LLM will only add new ideas not already in the KB. It does the searching, filtering and writing. I am just directing this process. The KB can grow unbounded because when I need to add new nodes I first search the KB and find relevant nodes to link to without loading every node.

But one problem I see with these memory systems is that they can reduce interest on a topic once we put it in the KB.

Hey, another co-founder of CORE. Great question about triples vs. fact statements! Your house example actually highlights why we went with a reified graph:

With fact statements, you'd need to decide upfront: is this one "about my house" memory or separate facts? Our approach lets you do both:

Representation flexibility: For your house example, we can model (house, needs repair, attic bath) AND connect it to (attic bathroom, has fixture, bath). The LLM extraction helps maintain consistency, but the graph structure allows both high-level and detailed representations simultaneously.

Updating and deduplication: - We identify potential duplicates/updates by matching subject-predicate patterns - When new information contradicts old (e.g., repair completed), we don't delete - we mark the old statement invalid at timestamp X and create a new valid statement - This maintains a complete history while still showing the current state - The structured format makes conflicts explicit rather than buried in text

The schema isn't rigid - we have predefined types (Person, Place, etc.), but relationships form dynamically. This gives structure where helpful, but flexibility where needed.

In practice, we've found this approach more deterministic for tracking knowledge evolution while still preserving the context and nuance of natural language through provenance links.

The problem with semantic web was deeper, people had to agree on the semantics that would be formalized as triples and getting people to agree on an ongoing basis is not an easy task.

My question is, what’s the value of explicitly storing semantics as triples when the LLM can infer the semantics on runtime?

Hey - well put!

I guess "semantic web" folks were right about the destination, just few years early :P

Hi,

There are 3 major differences between Zep and CORE 1. Market: Zep is B2B focused, CORE indvidual users 2. Portablity: Zep is locked to their platform , CORE works across claude, cursor, windsurf 3. Architecture: Zep is Temporal based vs CORE is Reified + Temporal based graph

What this means:

Zep remembers what happened when CORE remembers what happened when + why we should believe it + how facts relate

Example: You say "I love Thai food" → Later: "Actually, I hate Thai food"

Zep: "You hate Thai food" (old preference vanishes) CORE: "You currently hate Thai food. This contradicts your earlier statement from [date/source]. The change came from your correction today."

Bottom line: CORE provides full explainability and audit trails that Zep cannot.