Live data from Hacker News

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

github.com

41–43 of 43 posts

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

#41
post #38

Earlier quoted context omitted.

We support MCP server which you can use to connect to claude https://github.com/RedPlanetHQ/core/blob/main/README.md You can check in our readme on how to use mcp server

Tried this, no joy. I created a CORE API key from my workspace->API page, configured MCP with Claude Desktop, I get this: "You didn't provide an API key...You can obtain an API key from https://platform.openai.com/account/api-keys " Other memory MCP servers do not require access to OpenAI - and not even sure why I would want any of my data going there when I use a paid Claude subscription. I like the idea here, but d…

hey thanks for the feedback, agreed there are a lot to get right

1. If you have self hosted it yes then we need OpenAI api key, we are also working to get things working with llama so should be available soon (but if from cloud you shouldn't have got this error)

2. We also have moved away from openAI embedding (BGE-M3) to our own hosted in the cloud.

In self host we already have claude code support happy to help there

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

#42
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.

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

#43
post #25
post #8

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…

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 filt…

This is helpful. Love to see a demo of how tight you got the context window injection against a query. Thats where theres always 70% bloat in my previous systems.

I solved this by building holonically, same structure as you have it seems roughly, so I actually, through a ui can grab a holon and inject it into context including its children ( holon ~ nested heirarchy ), And I usually use semantic search so Ill add that in as well.

I have not added agentic memory flows yet, like when a model asks itself if it has what it needs and allows itself to look deeper.. have you?

I have agentic flows with other things, about 15 cascading steps between user and ai response, but have not done so with memory yet.

Im appreciating what you put together here.

Jonathan - Next AI Labs and IX Coach

Post reply on HN