hckrnws

Congrats on the launch. Adding a memory layer to LLMs is a real painpoint. I've been experimenting with mem0 and it solves a real problem that I failed to solve myself, and we're going to use it in production.

One question that I've heard a few times now: will you support the open source version as a first class citizen for the long term? A lot of open source projects with a paid version follow a similar strategy. They use the open source repo to get traction, but then the open source version gets neglected and users are eventually pushed to the paid version. How committed are you to supporting the open source version long term?

Over time, I can imagine there's going to be a lot of sensitive information being stored. How are you handling privacy?

We already support the feature of inclusion and exclusion of memories where the developer can control what things to remember vs not remember for their AI app/agent. For example, you can specify something like this:

- Inclusion prompt: User's travel preferences and food choices - Exclusion prompt: Credit card details, passport number, SSN etc.

Although we definitely think that there is scope to make it better and we are actively working on it. Please let us know if you have feedback/suggestions. Thanks!

An exclusion... prompt? Do you just rely on the LLM to follow instructions perfectly?

It looks great! Utilizing Knowledge Graph to store long term memory is probably the most accurate solution compared to using only Vector Store (same as with GraphRAG vs Vector RAG). I think an important thing to point here that long term memory vs RAG doesn't represent the organizational knowledge but the chat history which should be private to the end user and shouldn't be kept in a completely isolated graph than the rest of the users

Congrats on the launch!

I messed around with the playground onboarding...here's the output:

With Memory Mem0.ai I know that you like to collect records from New Orleans artists, and you enjoy running.

Relevancy: 9/10

Without Memory I don’t have any personal information about you. I don’t have the ability to know or remember individual users. My main function is to provide information and answer questions to the best of my knowledge and training. How can I assist you today?

Relevancy: 4/10

--

It's interesting that "With Memory" is 9/10 Relevancy even though it is 100% duplication of what I had said. It feels like that would be 10/10.

It's also interesting that "Without Memory" is 4/10 — it seems to be closer to 0/10?

Curious how you thinking about calculating relevancy.

This is why in my system I have more specific, falsifiable metrics: freshness, confidence, etc. which come together to create a fitness score at the surface-level, while still exposing individual metrics in the API.

How does Mem0 handle the potential for outdated or irrelevant memories over time? Is there a mechanism for "forgetting" or deprioritizing older information that may no longer be applicable?

Mem0 currently handles outdated or irrelevant memories by:

1. Automatically deprioritizing older memories when new, contradictory information is added. 2. Adjusting memory relevance based on changing contexts.

We're working on improving this system to give developers more control. Future plans include:

1. Time-based decay of unused memories 2. Customizable relevance scoring 3. Manual removal options for obsolete information

These improvements aim to create a more flexible "forgetting" mechanism, allowing AI applications to maintain up-to-date and relevant knowledge bases over time.

We're open to user feedback on how to best implement these features in practical applications.

Not sure if I’m seeing a clear value prop here. Why is this something that model provider’s won’t build themselves? Can you link some clear use-cases/killer apps that leverage mem0?

I believe AI memory is a very important problem to solve. Our AI tools should get better and more personalised over time.

(I hope it's ok to share something I've built along a similar vein here.)

I wanted to get long-term memory with Claude, and as different tools excel at different use cases, I wanted to share this memory across the different tools.

So I created MemoryPlugin (https://www.memoryplugin.com). It's a very simple tool that provides your AI tools with a list of memories, and instructs them on how to add new memories. It's available as a Chrome extension that works with ChatGPT, Claude, Gemini, and LibreChat, a Custom GPT for ChatGPT on mobile, and a plugin for TypingMind. Think of it as the ChatGPT memory feature, but for all your AI tools, and your memories aren't locked into any one tool but shared across all of them.

This is meant for end-users instead of developers looking to add long-term memory to their own apps.

Looks nice. Would the open-source version work from within an Electron app used for local LLM chats? I.e. can I run the memory management, retrieval, and database locally in javascript?

I believe the answer is "no, you can only run the memory management code in Python, the javascript code is only a client SDK for interacting with the managed solution". In which case, no worries, still looks awesome!

Check out https://github.com/Airstrip-AI/mem0-rest.

Disclaimer: I built it.

Context: We are using mem0 in another open-source project of ours (Typescript) and had the same questions. So we went ahead and built a small api server for ourselves.

Congrats Taranjeet and Deshraj!

So after using Mem0 a bit for a hackathon project, I have sort of two thoughts: 1. Memory is extremely useful and almost a requirement when it comes to building next level agents and Mem0 is probably the best designed/easiest way to get there. 2. I think the interface between structured and unstructured memory still needs some thinking.

What I mean by that is when I look at the memory feature of OpenAI it's obviously completely unstructured, free form text, and that makes sense when it's a general use product.

At the same time, when I'm thinking about more vertical specific use cases up until now, there are very specific things generally that we want to remember about our customers (for example, for advertising, age range, location, etc.) However, as the use of LLMs in chatbots increases, we may want to also remember less structured details.

So the killer app here would be something that can remember and synthesize both structured and unstructured information about the user in a way that's natural for a developer.

I think the graph integration is a step in this direction but still more on the unstructured side for now. Look forward to seeing how it develops.

Thanks yding! Definitely agree with the feedback here. We have seen similar things when talking to developers where they want:

- Control over what to remember/forget - Ability to set how detailed memories should be (some want more detailed vs less detailed) - Different structure of the memories based on the use case

Great product, thanks for releasing it for the opensource community. Have you considered replacing Neo4j with something more cost-effective like Memgraph?

When I worked as a consultant in the knowledge graph area I ran into clients over and over against who had failed with Neo4J, which I'd never done because I read the Neo4J manual and understood it just wasn't an industrial strength tool.

Can you recommend any graph db's in particular, preferably with some discussion of why?

There is no perfect product because of the high diversity of graph workloads.

I am inclined to like SPARQL databases because of their multiscale nature. You can have a tiny SPARQL database in RAM that you use like a hashtable and also have a big one with a few billion triples. It is a common situation that you want to gather all the facts to make a decision about a case (such as handling a customer at a call center) and it reasonable to fetch all of that and get it in RAM.

Two major problems w/ SPARQL databases are:

(1) even though RDF has two official ways to represent ordered collections and there is an unofficial one that works very well, SPARQL does not have facilities to work with ordered collections like you would have in N1QL or AQL or similar document-oriented query languages. This could be added but it hasn't been done.

(2) If you are writing transactional or agentic systems in SQL you have a lot of help in that a "row" is a unit to do inserts, deletes, and updates in. It is not so easy to get it right if you are updating a triple at a time, there are algorithms to define a part of a graph that form a "record" (e.g. go to the right from a starting node, passing through blank nodes, not passing through URIs) but this is all stuff you have to implement yourself.

---

Salesforce.com has a patent which has recently expired that covers a triple store that automatically profiles itself and builds indexes for very efficient query execution, if this was built into graph database products it could be game changing but so far it isn't.

---

There is "graph as a universal data structure" as in "the graph of pointers in a C program" and then there are the "graph algorithms" that Mark Newman writes about. The later are much less interesting than the former (go bomb the #1 centrality node in a terrorist network -- did you win the war?)

If you are doing the latter or any kind of really intensive job you may be better doing it as a batch job, in fact back in the day I developed Hadoop-based pipelines to do things like reconstruct the relationships inside the Freebase data dump.

----

For quite a few projects I've used Arangodb which is a great product but the license really sucks. I have something I have been working on for a while that uses it and if I am going to either open source or commercialize it I'm going to have to switch to something else.

Thanks for the feedback! Yes, we are definitely planning to add support for other graph datastores including Memgraph and others.

Does the structure of data & query patterns required demand a graph store for acceptable performance? Would a Postgres-based triplestore & recursive CTE’s suck badly?

Yes, it won't scale well. I have used postgres exactly the way you specified in my past job and it didn't scale well after a certain point.

Could you speak to more about what the pricing is? With the current pricing page, it's hard to model costs against potential use cases.

Looks interesting but curious to know how is it different from using traditional databases or vector databases? Is that the graph element?

Thanks for your question!

Vector databases are typically used for storing embeddings and are great for tasks like similarity search. However, they are generally read-only and don't natively support the concept of time or state transitions. Let's take an example of tracking state of a tasks from your todo list in a vector database:

You might store the task's states like:

Task 1 in backlog Task 1 in progress Task 1 in canceled

But there's no concept of "latest state" or memory of how the task evolved over time. You'd have to store multiple versions and manually track changes.

With a memory-enabled system like Mem0, you could track: Task 1 (current state: in progress) with a memory of previous states (backlog, canceled, etc). This gives your AI app more stateful understanding of the world, allowing it to update and reflect the current context automatically.

Traditional databases, on the other hand, are designed for structured, relational data with fixed schemas, like customer information in a table. These are great for handling transactional data but aren't optimal for cases where the data is unstructured.

As mentioned in the post, we use a hybrid datastore approach that handles these cases effectively and that's where the graph aspect comes into picture.

> However, they are generally read-only

What??

Hi this looks interesting. From your description it looks like mem0 remembers details and context of previous chats but not the actual text of chats. Is this a correct assumption?

Hey, yes. It remembers whatever is important from the previous chats.

I'm looking to use, or build, a system that memorizes conversations and stores them in the RAG system. Example conversation:

==== Bot: wassup?

Me: I have some more thoughts on Project X. They will be rambly so please also create an edited version as well as the usual synopsis. I will say 'I'm finished' when I've finished.

Bot: ok hit me

Me: bla bla bla bla etc etc. I'm finished.

Bot: this looks like part of the introduction text of Project X, is that correct?

Me: yes. What meta tags do you suggest? Etc ====

I'm assuming that a custom GPT or equivalent is necessary to set out the 'terms of engagement' and agent objectives. Can you offer any advice about building such a system, and how mem0 could help?

Thanks for the lucid and detailed post and responses. I'm curious whether you imagine this thing developing as a general-purpose scaffolding or something that is more geared towards one form-factor eg. chat-bot, voice-bot

Congrats! API looks easy to use. Graph memory feature is interesting, seems powerful. Curious if it works well in practice and if it can handle fuzzy/contradictory facts (which is a general problem for symbolic AI).

Is there any way to change what "user" I am chatting as in the playground? I created some memories in the onboarding process under a specific user, but it seems like my chats in the playground are using a different user.

Hey, Deshraj from Mem0 team. Right now you cannot change the “user” you are chatting as yet but we can definitely make it happen. Will ship this update later today. :)

@staranjeet we should get you plugged in as part of persistence with https://github.com/dagworks-inc/burr !

Hey, that would be great. Lets chat

why a graph db, can you please illustrate how it helps

When using a graph database you can build a knowledge Graph out of the long term memory. Storing it only in a vector database means that you'll only find things that are similar to the user question and miss a lot of information that is an aggregation of different memories.

It's a very similar reason on why using Graph for RAG can help you get much more accurate responses than with Vector RAG. See a blog I wrote about it https://www.falkordb.com/blog/knowledge-graph-vs-vector-data...

Congrats on the launch!

The only AI memory solution I work with every day is ChatGPT memory feature. How does mem0 compares to it?

Thanks for the question. Here's how Mem0 differs from ChatGPT memory:

1. LLM Compatibility: Mem0 works with various AI providers (OpenAI, Anthropic, Groq, etc.), while ChatGPT memory is tied to OpenAI's models only.

2. Target Audience: Mem0 is built for developers creating AI applications, whereas ChatGPT memory is for ChatGPT users.

3. Quality and Performance: Our evaluations show Mem0 outperforms ChatGPT memory in several areas:

    - Consistency: Mem0 updates memories more reliably across multiple instances.

    - Reliability: ChatGPT memory can be inconsistent with the same prompts, while Mem0 aims for more consistent performance.

    - Speed: Mem0 typically creates memories in about 2 seconds, compared to ChatGPT's 30-40 seconds to reflect new memories.

These differences make Mem0 a better choice for developers building AI apps that need efficient memory capabilities.

Looks very over engineered to me.

the hybrid datastore (graph, vector, key-value) seems like a smart way to handle different types of information. But as it scales, how do you plan to manage issues like memory bloat or outdated context? Is there a strategy for pruning irrelevant data to keep the system efficient?

Exciting work overall!

10/10 name

makes me nostalgic for ChatScript's fact triples

thanks

Where do you process your data? Do you have a Europe region? Are you GDPR compliant?

This is my main concern with most AI providers. They are based in the US, with unclear GDPR compliancy, making most of them a non-starter for me.

Thanks for your question! Currently, we process data in the US and are not yet fully GDPR-compliant, but we're actively working on it. We also plan to offer a Europe-based data processing option soon. Your feedback on this is welcome!

Solves a key need to make AI Agents useful!

Fantastic launch :)

how it is different from Calude prompt caching ?

Thanks for your question!

Claude Prompt Caching and Mem0's memory system have several key differences:

1. Purpose and duration: Claude's cache is designed for short-term memory, clearing every 5 minutes. In contrast, Mem0 is built for long-term information storage, retaining data indefinitely unless instructed otherwise. 2. Flexibility and control: Mem0 offers more flexibility, allowing developers to update, delete, or modify stored information as needed. Claude's cache is more static - new information creates additional entries rather than updating existing ones. 3. Content management: Claude has minimum length requirements for caching (1024 characters for Sonnet, 2048 for Haiku). Mem0 can handle information of any length, from short facts to longer contexts. 4. Customization: Developers have greater control over Mem0's memory management, including options for prioritizing or deprioritizing information based on relevance or time. Claude's caching system offers less direct control. 5. Information retrieval: Mem0 is designed for more precise and targeted information retrieval, while Claude's cache works with broader contextual blocks.

These differences reflect the distinct purposes of each system. Claude's cache aims to maintain recent context in ongoing conversations, while Mem0 is built to serve as a flexible, long-term knowledge base for AI applications.

Because this doesn't prompt cache? Prompt caching is dumping out the calculated values from vRAM onto disk and reloading them back into memory as necessary.

Congratulations to the Mem0 team on your launch! As LLMs continue to advance, with newer models featuring larger context windows and better context retention, how does Mem0 distinguish itself from the memory capabilities that future LLMs might inherently possess?

What's up with all the flagged comments?

I flagged some (most? not sure) of them as booster comments, presumably by friends trying to help the submitters out. HN users aren't supposed to do that and YC founders are given strict instructions not to do it (and scoldings when it happens), but it's impossible to prevent completely. People's friends try to "help" them and don't realize that it's actually the opposite of helping.

See the "Comments" section of the Launch HN instructions for YC startups (https://news.ycombinator.com/yli.html) for an example of how strongly we emphasize this.

If I see this many questions that could have been taken straight from an FAQ, all followed up with “great question, we do so and so..”, my alarm bells go off. Shady marketing indeed.

There was even more before. Some has been removed completely.

If you turn on 'showdead' in your profile you can see all killed comments. (This is in the FAQ: https://news.ycombinator.com/newsfaq.html.)

There's only one level of removal beyond that ("[deleted]") but we never do that as moderators. "[deleted]" always means either that the author deleted the post themselves or asked us to do it for them.

Thanks. I have it on but I had the window open for a while and went into the profile of one which then longer had any comments so I guess they removed it themselves.

I'm also confused. They seem positive and constructive. Do mods detect that these are some kind of automated bots?

I observed at least two brand new accounts posting some variety of “kudos”, not flagged into oblivion (yet). Gives me the ick, i guess it’s better to know mem0 is a shady marketer (maybe they are also a shady operator).

[dead]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

I enjoyed our collaboration to integrate with our MultiOn agent platform. Try it our if you are building AI Agents for the web.

This is an impressive innovation! Mem0 directly addresses a big problem that many of us have had with present large language models. It seems to me that the addition of a stateful memory layer potentially allows for LLMs that are not only more intelligent but also more efficient and user-friendly, because they can be tailored to individual users. And your design for an open-source, hybrid memory system also seems like a big step forward for the developer community both for the inventiveness of the system itself and for the potential it has for serving as a model for whatever comes next after LLMs.