Mem0 With Ollama: Give Your AI Agent Long-Term Memory Fully Locally (Windows, Mac, Kali), the Vector-Size Trap, Tencent Hy-Memory-30B-A3B and Mem0 on Amazon Bedrock

Mem0 is an open-source memory layer for AI agents (Apache 2.0, about 67,400 stars on GitHub): it lets a chatbot or agent remember facts about a user across conversations, so it stops asking the same questions every time. You can run it completely on your own computer with Ollama, no API key and no data leaving the machine: pip install mem0ai, then point it at an Ollama chat model for deciding what to remember, an Ollama embedding model such as nomic-embed-text, and a local Qdrant folder. The one setting almost everyone gets wrong is the vector size: Mem0's local store expects 1,536 numbers per memory by default, while nomic-embed-text produces 768, so you must set embedding_model_dims to match or the first save fails. And there is now a model built for exactly this job: Tencent's Hy-Memory-30B-A3B (Apache 2.0, 3B active parameters), which scored above Anthropic's Opus 5 inside the Mem0 harness on Tencent's tests and runs locally from a 16.9 GB file. Below: what agent memory is, the full local setup for Windows 11, Mac and Kali Linux, the Hy-Memory route, Mem0 on Amazon Bedrock, and the fixes for the errors people hit first.

Jake's computer shop runs a small chat assistant on its website: it answers "is my laptop ready?", books repairs and quotes prices. Customers like it, with one complaint. Every visit starts from zero. A customer who said last week that she has a 2019 MacBook Air with a swollen battery has to say it all again, and the assistant asks for her phone number every single time. Ethan, Jake's developer friend, wanted the assistant to remember, but Jake had one rule: customer details stay in the shop. This page is how Ethan gave the assistant a memory without sending a byte to anyone else's cloud.

New to running models on your own machine? Our free plain-English series covers Ollama, model sizes and memory in an hour. This page assumes you can already run one model in Ollama.

What Mem0 is, in plain English

A language model has no memory between conversations. Everything it "knows" about you in a chat sits in the conversation itself, and when the chat ends, it is gone. Apps that seem to remember you are doing it outside the model: they save notes about you somewhere and slip the relevant ones back into the next conversation.

Mem0 is a ready-made version of that "somewhere." You hand it a conversation, and it pulls out the facts worth keeping ("drives a 2019 MacBook Air", "battery is swollen", "prefers text messages to calls"), stores them, and later, when the same person asks something, it finds the memories that matter and gives them back to you to add to the prompt. It is a library, so it slots into whatever assistant or agent you already have: a support bot, a coding agent, a personal assistant.

The project is open source under Apache 2.0, which means you can use it at work without license fees, and it is one of the most popular projects of its kind, at about 67,400 stars on GitHub. It comes in three forms:

This page is about the first two, the ones you run yourself. The library is the quickest start, and everything on it carries over to the server later.

Jake: "So the AI does not actually remember anything? Mem0 keeps notes for it?"

Ethan: "Exactly. Mem0 writes the notes, files them, and hands the right ones back before the assistant answers."

How agent memory works: short-term, long-term and the three parts

People who build agents usually split memory in two. Short-term memory is the current conversation: what was said five messages ago. The model handles that itself, inside its context window. Long-term memory is what should survive after the conversation ends: preferences, facts about the person, decisions made, things that went wrong last time. Long-term memory is the part Mem0 handles.

Under the hood, Mem0 uses three parts, and knowing them makes every setting on this page make sense:

1. A language model (the LLM) reads the conversation and decides what is worth remembering, and whether a new fact updates or replaces an old one. In the default setup this is OpenAI's gpt-5-mini; on this page it is a model in Ollama.
2. An embedding model turns each memory into a list of numbers that captures its meaning, so "my laptop battery is puffy" and "swollen battery" end up close together. Our EmbeddingGemma 2 guide explains embeddings with examples.
3. A vector store keeps those number lists and finds the nearest ones when you search. The default is Qdrant saved in a folder on disk, which needs no server at all.

Mem0 also keeps a small SQLite history file (~/.mem0/history.db by default) recording how memories changed over time, which is useful when you want to know why the assistant believes something.

When your assistant gets a message, the flow is simple: search Mem0 for memories about this person, add the best few to the prompt, let the model answer, then hand the new exchange to Mem0 so it can learn from it. Two calls, search before and add after.

The types of agent memory, and which ones Mem0 covers

When you read about AI agent memory, you will see the same handful of terms, borrowed loosely from how people describe human memory. Knowing them helps you decide what to store and what to leave in the conversation.

• Working memory is what the agent is thinking about right now: the current conversation and the task in hand. It lives in the model's context window and disappears when the session ends.
• Semantic memory is facts: "Priya has a 2019 MacBook Air," "the shop closes at 6 on Saturdays." This is Mem0's main job, and the kind of memory most assistants need first.
• Episodic memory is what happened: "last Tuesday the battery replacement was delayed because the part came in wrong." It is useful when the history of a relationship matters, such as a customer who had a bad experience.
• Procedural memory is how to do things: "for this customer, always confirm by text before ordering parts." In practice, much of this belongs in your system prompt or your code, not in a memory store.

Mem0 stores whatever the memory model decides is worth keeping, so in practice it holds a mix of semantic and episodic memories, phrased as short statements. You steer that mix by how you write your assistant's prompts and which parts of the conversation you hand to add. A simple rule that works for most small businesses: give Mem0 the customer's own messages and the assistant's confirmations, and leave out long internal reasoning or tool output.

Memory vs RAG: two different kinds of looking things up

Memory and retrieval-augmented generation (RAG) both search a vector store and add what they find to the prompt, so they are easy to confuse. The difference is where the knowledge comes from and who it is about.

Most good assistants use both: RAG for what the business knows, memory for what it knows about each customer. On AWS, Bedrock Knowledge Bases is the managed RAG side; our Bedrock Knowledge Bases guide covers it. Locally, you can run a second Qdrant collection for documents next to Mem0's memory collection, with the same embedding model.

Jake: "So the warranty policy goes in one place and Priya's laptop goes in the other?"

Ethan: "Yes. The policy is the same for every customer. Priya's laptop is only Priya's."

What you need: hardware and models

The memory layer itself is light. What costs memory on your computer is the language model Mem0 uses to decide what to remember. Because Mem0 asks that model to return structured results (it uses tool calling), a model that handles tool calls reliably matters more than a huge one.

In plain terms: with 16 GB of RAM, use a small tool-calling model and expect the occasional bad memory; with 32 GB, Hy-Memory's 4-bit file fits and is the better choice for this job; with a graphics card of 16 GB or more, everything gets faster. Our hardware tiers page shows which machines land where.

Install Mem0 and the models (Windows 11, Mac, Kali)

You need Python 3.10 or newer and Ollama. The steps are the same on every system, with small differences in how you open a terminal.

1. Install Ollama from ollama.com (Windows and Mac), or on Kali run curl -fsSL https://ollama.com/install.sh | sh. Check it with ollama --version.
2. Pull the embedding model and a chat model. Swap the second line for whatever tool-calling model you prefer.

ollama pull nomic-embed-text
ollama pull hf.co/rapatsky/Hy-Memory-30B-A3B-GGUF:Q4_K_M

3. Make a project folder and a virtual environment, so Mem0's packages stay separate from the rest of your Python:

# Windows 11 (PowerShell)
mkdir C:\shop-memory; cd C:\shop-memory
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install mem0ai

# Mac and Kali Linux
mkdir ~/shop-memory && cd ~/shop-memory
python3 -m venv .venv
source .venv/bin/activate
pip install mem0ai

On Kali, if python3 -m venv complains that ensurepip is missing, install the venv package first with sudo apt install python3-venv. On Windows, if PowerShell refuses to run the activate script, run Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once and try again.

For the optional hybrid search (keyword plus meaning), install the extra and its language model too: pip install mem0ai[nlp] followed by python -m spacy download en_core_web_sm. You can skip this to start.

The fully local setup: Ollama, nomic-embed-text and Qdrant on disk

Here is a complete script that gives an assistant memory with nothing leaving your computer. Save it as memory_test.py in your project folder and run it with python memory_test.py (or python3 on Mac and Kali).

from mem0 import Memory

config = {
    "llm": {
        "provider": "ollama",
        "config": {
            "model": "hf.co/rapatsky/Hy-Memory-30B-A3B-GGUF:Q4_K_M",
            "temperature": 0.1,
            "max_tokens": 2000,
            "ollama_base_url": "http://localhost:11434",
        },
    },
    "embedder": {
        "provider": "ollama",
        "config": {
            "model": "nomic-embed-text",
            "ollama_base_url": "http://localhost:11434",
        },
    },
    "vector_store": {
        "provider": "qdrant",
        "config": {
            "collection_name": "shop_customers",
            "path": "./memory_db",          # a real folder, not /tmp
            "embedding_model_dims": 768,    # must match nomic-embed-text
        },
    },
}

m = Memory.from_config(config)

conversation = [
    {"role": "user", "content": "Hi, it's Priya. My 2019 MacBook Air battery is swollen. Text me, please don't call."},
    {"role": "assistant", "content": "Got it, Priya. We can replace it this week. I'll text you."},
]
m.add(conversation, user_id="priya")

results = m.search("What laptop does this customer have?", filters={"user_id": "priya"})
hits = results["results"] if isinstance(results, dict) else results
for h in hits:
    print(h.get("memory"))

The first run is slow, because Ollama loads both models; after that, each add takes as long as one short answer from your chat model, and each search is fast. If everything works, the search prints memories along the lines of the laptop model, the battery problem and the texting preference.

Three choices in that script matter more than they look:

• "path": "./memory_db" keeps the memories in your project folder. The default is /tmp/qdrant, and on Linux, files in /tmp can disappear when the computer restarts, taking your assistant's memory with them.
• "embedding_model_dims": 768 matches the embedding model. The next section explains why this one line causes most first-day failures.
• user_id keeps each person's memories separate. Search with the same ID you saved with, or the assistant finds nothing.

Jake: "That's it? Two lines in the chatbot?"

Ethan: "Two calls: search before it answers, add after. The rest is choosing where the memories live."

The trap: vector sizes that do not match

Every embedding model turns text into a list of a fixed length. OpenAI's text-embedding-3-small, Mem0's default, makes 1,536 numbers. nomic-embed-text makes 768, and mxbai-embed-large makes 1,024. The vector store has to be created for one length, and Mem0's Qdrant setting embedding_model_dims defaults to 1,536, because it assumes the default OpenAI embedder.

Switch the embedder to Ollama without changing that setting, and the store expects 1,536 numbers but receives 768. Saving or searching then fails with a dimension mismatch error. The fix is to set embedding_model_dims to your model's size:

One more catch: if you already ran Mem0 once with the wrong size, the collection was created at that size. Changing the setting afterward is not enough. Delete the memory folder (or use a new collection_name) so Qdrant creates the collection again at the right size. Do this before you have real memories in it, or export them first.

Choosing the model that decides what to remember

Mem0 asks its language model to do structured work: read a conversation, list the facts, and decide for each one whether it is new, an update to something already stored, or a duplicate. It does this through tool calling, so the model must support tools. In Ollama, you can see that on the model's library page, where tool-capable models carry a "tools" tag.

Small models are where people run into trouble. A model that is good at chatting can still be sloppy at structured output: it may wrap its answer in extra text, skip a field, or return something that is not valid JSON. When that happens, Mem0 cannot read the result, and the add call fails or saves nothing. If you see errors that mention JSON or parsing during add, the model is the first suspect, not Mem0.

Three settings help:

• A low temperature, 0.1 as in the script above, or 0 for the most predictable output. You want the same facts out of the same conversation every time.
• Enough output room, max_tokens of about 2,000, so a long list of facts is not cut off halfway.
• A model built for the job. That is what the next section is about.

Hy-Memory-30B-A3B: a local model made for memory

In October 2026, Tencent released Hy-Memory-30B-A3B, a model that does one thing: write long-term memory. It is not a general chatbot. It decides what to keep, how to phrase it, and how new information should update what is already stored, and it is designed to replace the general-purpose language model inside memory frameworks, Mem0 included. It is a mixture-of-experts model with 30 billion parameters, about 3 billion active per token, under the Apache 2.0 license, and it was trained on English and Chinese.

Tencent tested it inside four memory frameworks, on samples of the LoCoMo and LongMemEval benchmarks and four others. Inside the Mem0 framework, it averaged 54.02, ahead of Anthropic's Opus 5 (53.43), DeepSeek V4.1 Flash (49.73) and the general Qwen3.6-35B-A3B (47.51). Across all four frameworks it averaged 55.49, also the top score in Tencent's table. These are the maker's numbers on 20% samples of each benchmark, so treat them as a strong hint rather than a final word, but the point stands: a 3B-active model that fits on a desk can write memories about as well as the biggest models.

Because only about 3 billion parameters work per token, it is quick even when part of it sits in system RAM. The file needs a llama.cpp build with Tencent's hy_v3 architecture, so update Ollama or llama.cpp before you pull it. Mac users can also find MLX builds from the community.

Using it through Ollama is the easiest route, as in the script above: pull hf.co/rapatsky/Hy-Memory-30B-A3B-GGUF:Q4_K_M and put that name in Mem0's LLM config.

Using it through llama-server gives you one extra control. Hy-Memory can think before it answers, and for memory extraction you want it to skip that step. llama-server lets you switch thinking off for every request, and Mem0 can then talk to llama-server through its OpenAI provider:

llama-server -hf rapatsky/Hy-Memory-30B-A3B-GGUF:Q4_K_M --jinja -c 32768 \
  --chat-template-kwargs '{"reasoning_effort":"no_think"}'

"llm": {
    "provider": "openai",
    "config": {
        "model": "hy-memory",
        "api_key": "local",
        "openai_base_url": "http://127.0.0.1:9931/v1",
        "temperature": 0,
        "max_tokens": 2000,
    },
},

llama.cpp builds from v0.7.0 on listen on port 9931 by default (older builds used 8080). On Windows PowerShell, the quotes around the JSON in --chat-template-kwargs work differently; if PowerShell mangles them, put the whole command in a .bat file or run it from Command Prompt. Tencent's own quickstart serves the model with vLLM instead, as vllm serve tencent/Hy-Memory-30B-A3B --served-model-name hy-memory, which suits a Linux server with a large GPU.

Jake: "A whole model just for remembering things?"

Ethan: "A small one, and it is better at that one job than the big general models. It's like hiring a good filing clerk instead of asking the manager to file."

Putting it together: an assistant that remembers

Here is the shape of the loop inside a chatbot, using any local chat model through Ollama's Python package (pip install ollama). The chat model and the memory model can be the same model or different ones; many people use a strong general model for answers and Hy-Memory for memory.

import ollama
from mem0 import Memory

m = Memory.from_config(config)   # the config from the script above
CHAT_MODEL = "qwen3.8"           # your everyday chat model in Ollama

def reply(user_id, text):
    found = m.search(text, filters={"user_id": user_id})
    hits = found["results"] if isinstance(found, dict) else found
    notes = "\n".join("- " + h.get("memory", "") for h in hits[:5])
    messages = [
        {"role": "system", "content": "You are the repair shop assistant. What you know about this customer:\n" + notes},
        {"role": "user", "content": text},
    ]
    answer = ollama.chat(model=CHAT_MODEL, messages=messages)["message"]["content"]
    m.add(messages[1:] + [{"role": "assistant", "content": answer}], user_id=user_id)
    return answer

print(reply("priya", "Is my laptop ready?"))

Notice the order: search first, answer second, add last. The add can also run in the background after you have already shown the answer, so the customer never waits for the memory step. Keep the number of memories you put in the prompt small (five is plenty for a support chat), because every note costs context and can distract the model.

The library also has methods to list all memories for a user, update or delete one, and show a memory's history, which you will want for a "forget me" button. People increasingly expect to be able to see and delete what an assistant remembers about them, and in many places privacy law requires it.

Running Qdrant as a server instead of a folder

The folder setup is perfect for one app. When two programs need the same memories, for example your website assistant and a staff tool, they should not open the same Qdrant folder at the same time. Run Qdrant as a small server instead, and point both programs at it. With Docker installed, one command starts it:

docker run -d --name qdrant -p 6333:6333 -v qdrant_data:/qdrant/storage qdrant/qdrant

Then change the vector store section of your config from a path to a host and port:

"vector_store": {
    "provider": "qdrant",
    "config": {
        "collection_name": "shop_customers",
        "host": "localhost",
        "port": 6333,
        "embedding_model_dims": 768,
    },
},

The -v qdrant_data:/qdrant/storage part keeps the data in a Docker volume, so it survives when the container is recreated. If the server runs on another machine on your network, use its address instead of localhost, and keep port 6333 closed to the internet; a memory store full of customer facts is not something to expose. For a hosted Qdrant, the config also takes a url and an api_key.

Testing memory quality before customers see it

A memory layer can fail quietly: it saves the wrong fact, keeps an old address after the customer moved, or saves nothing at all. Spend an hour testing before you switch it on for real customers. A small, repeatable test set is enough:

1. Write ten short test conversations that look like your real ones: a booking, a complaint, a change of phone number, a customer who mentions two devices.
2. Run each through add with a test user ID, then search for what should be there. Check that the facts are right and phrased in a way your assistant can use.
3. Test updates. Add a second conversation where the customer changes something ("I've switched to a new number"). Search again and check that the new fact replaced the old one instead of sitting next to it.
4. Test the noise. Add a conversation with small talk ("lovely weather today") and check that it did not create useless memories.
5. Test separation. Search one test user's ID for another user's facts. The answer must be nothing.

Run the same set whenever you change the memory model, the embedding model or the prompt, and compare. This is also how you choose between models fairly: Hy-Memory against your general chat model, on your own conversations, is a better test than any public benchmark for your shop.

Jake: "An hour of testing for a chatbot?"

Ethan: "An hour now, or a customer told her repair is ready when it isn't. The hour is cheaper."

See, correct and delete what the assistant remembers

Sooner or later a memory will be wrong, out of date, or something a customer asks you to forget. Mem0 gives you five calls for looking after memories by hand, and they are worth trying on your test user before you need them for real:

# 1. Everything remembered about one customer, with each memory's ID
everything = m.get_all(filters={"user_id": "priya"})
items = everything["results"] if isinstance(everything, dict) else everything
for mem in items:
    print(mem["id"], "|", mem["memory"])

# 2. Correct one memory (paste an ID from the list above)
m.update(memory_id="PASTE-ID-HERE", text="Prefers text messages; never call before 10 a.m.")

# 3. See how that memory changed over time
for change in m.history(memory_id="PASTE-ID-HERE"):
    print(change.get("event"), "|", change.get("old_memory"), "->", change.get("new_memory"))

# 4. Forget one memory, or 5. everything about one customer
m.delete(memory_id="PASTE-ID-HERE")
m.delete_all(user_id="priya")

Two of these trip people up. get_all and search take the user inside filters; passing user_id= to them directly raises a ValueError in current versions, while add and delete_all take user_id as a plain argument. And update takes the new wording as text; the older data argument still works but logs a warning.

The history file remembers deletions. Every add, update and delete writes a line to Mem0's history database, and a delete records the old text alongside the deletion. So after delete_all for a customer who asked to be forgotten, their old memories are gone from the vector store but still readable in the history file. For a real "forget me" request, delete the matching rows from that SQLite file too, or keep history in the project folder (the history_db_path setting in the config) so it is easy to find and clear. m.reset() wipes everything, memories and history together, which is right for a test setup and almost never for a live one.

A small admin script with these calls, run from a terminal, is all most shops need. The self-hosted Mem0 server described below adds a web dashboard for the same jobs when someone without Python skills has to do them.

A simple memory policy for a small business

Before an assistant remembers customers, decide what it should remember and for how long. Writing it down takes ten minutes and saves awkward conversations later.

• What to keep: devices, the problem and its status, contact preferences, and anything the customer asked you to remember.
• What never to keep: payment details, passwords, ID numbers, and health or other sensitive details that the job does not need. Remove them from the text before add.
• How long: for a repair shop, a year after the last visit is a sensible starting point; schedule a cleanup that deletes older memories.
• How customers see it: a line in your privacy notice that the assistant remembers past conversations, and an easy way to ask for those memories to be deleted.

Local storage makes this easier, not harder: you know exactly where the memories are, and deleting a customer's data means deleting it from one folder and one history file on your own machine.

Memories that expire, and memories you add directly

Some facts are only true for a while: "laptop is in for repair until Friday," "waiting for a replacement screen," "on holiday until the 3rd." Left alone, the assistant would keep repeating them for months. Mem0 can attach an expiry date to a memory, either when you add it or later with update:

# A temporary fact that should stop showing up after the repair is done
m.add(
    [{"role": "user", "content": "My laptop is with you until the screen arrives."}],
    user_id="priya",
    expiration_date="2026-11-15",
)

# Give an existing memory an end date (passing None clears it)
m.update(memory_id="PASTE-ID-HERE", expiration_date="2026-11-15")

Expired memories stay stored but drop out of search and get_all results by default; both accept show_expired=True when you want to see them, for example when checking a customer's full record. That is a gentler tool than deletion for facts that are merely out of date, and it makes the "how long" line in your memory policy something the software enforces.

For the yearly cleanup itself, a short monthly script does the job: list each customer's memories with get_all, read each memory's created_at date, and call delete on anything older than your limit. Run it on your test user first and print what it would delete before letting it delete anything.

Jake: "So the 'waiting for a screen' note won't still be there at Christmas?"

Ethan: "It switches itself off on the date we give it. And the cleanup script takes care of anyone we haven't seen in a year."

Adding facts without the model. Normally add asks your chat model to pick out the facts worth keeping. With infer=False, Mem0 skips that step and stores each message as it is, with no model call at all. That is handy for importing notes you have already written as clean facts, such as a spreadsheet of customer preferences, because it is fast and exact. It is the wrong choice for raw conversations: every "thanks, see you Friday" would become a memory. System messages are skipped either way.

Privacy: where your memories actually live

With the setup on this page, everything stays on your machine: the conversations go to Ollama on localhost, the memories sit in the ./memory_db folder, and the history sits in ~/.mem0/history.db. Nothing is sent to Mem0's company or to OpenAI. That is the whole point of the local setup, and it is what let Jake say yes.

Three habits keep it that way:

• Set every part explicitly. If you leave out the embedder section, Mem0 falls back to its default, OpenAI, and asks for an OPENAI_API_KEY. An error is the good outcome there; the bad one is someone adding a key to "fix" it and sending memories to the cloud.
• Back up the memory folder and the history file like any other database. They are the assistant's knowledge of your customers.
• Store facts, not secrets. Card numbers, passwords and ID numbers do not belong in an assistant's memory. Filter them out of the conversation before you call add.

When to move to the self-hosted Mem0 server

The library is perfect for one app on one machine. When several apps or several people need the same memories, or you want a dashboard to see and edit them, Mem0's self-hosted server is the next step. It runs with Docker Compose, adds a web dashboard and logins with API keys, and keeps your data on your infrastructure. The project's server folder includes a make bootstrap command to set it up.

The hosted Mem0 Cloud Platform is the third option: no servers to run, and it includes advanced features the open-source versions only preview. Mem0 reports big gains from a new memory algorithm on its platform in April 2026: 92.5 on LoCoMo (up from 71.4) and 94.4 on LongMemEval (up from 67.8), at around 7,000 tokens and about a second per lookup. Those numbers come from the platform, which includes optimizations not in the open-source library, so a local setup should improve in the same direction but will not match them exactly.

Mem0 on AWS: Amazon Bedrock as the memory model

If your assistant runs on AWS, Mem0 can use a model in Amazon Bedrock as its memory LLM, so the decision about what to remember stays inside your AWS account. The provider name is aws_bedrock:

import os
os.environ["AWS_REGION"] = "us-east-1"

config = {
    "llm": {
        "provider": "aws_bedrock",
        "config": {
            "model": "amazon.nova-pro-v1:0",
            "temperature": 0.2,
            "max_tokens": 2000,
        },
    },
    # embedder and vector_store as in the local script, or your own choices
}

You need model access turned on for that model in the Bedrock console and the boto3 package installed. Credentials come from the normal AWS chain, so on an EC2 instance, ECS task or Lambda function, the instance or task role works and you do not put keys in code. Where the model is not available on demand in your Region, use its cross-Region inference profile ID instead, for example us.amazon.nova-pro-v1:0. Any other Bedrock model you have access to works the same way, by changing the model ID.

AWS also offers a managed alternative. Amazon Bedrock AgentCore Memory gives agents short-term memory for the current conversation and long-term memory across sessions, without running Mem0 yourself. Our AgentCore explainer covers what it includes. Pick Mem0 when you want the same memory code locally and in the cloud; pick AgentCore Memory when you want AWS to run all of it.

Errors and fixes

Dimension mismatch when saving or searching

The vector store was created for a different embedding size. Set embedding_model_dims to match your embedder (768 for nomic-embed-text, 1,024 for mxbai-embed-large), then delete the memory folder or use a new collection_name so the collection is recreated.

"OPENAI_API_KEY" error when you only use Ollama

A part of the config is missing, so Mem0 fell back to its OpenAI default. Make sure you have all three sections (llm, embedder and vector_store) and that you create the memory with Memory.from_config(config), not Memory().

Connection refused to localhost:11434

Ollama is not running. Start the Ollama app on Windows or Mac, or run ollama serve on Kali. If Ollama runs on another machine, put its address in ollama_base_url for both the LLM and the embedder.

"model not found"

The model name in the config does not match a pulled model. Run ollama list and copy the exact name, including any hf.co/ prefix and tag.

JSON or parsing errors during add, or nothing gets saved

The memory model returned output Mem0 could not read. Use a tool-capable model, lower the temperature, raise max_tokens, or switch to Hy-Memory-30B-A3B, which was trained for this job.

Memories disappear after a restart

The vector store was in /tmp/qdrant, the default, which Linux can clear on reboot. Set path to a permanent folder.

Search returns nothing

Check that you search with the same user_id you saved with, and that the add actually stored something (the add returns what it saved). A search right after the first add can come back empty if the add failed quietly because of the model.

Hy-Memory will not load

Your Ollama or llama.cpp is too old for the hy_v3 architecture. Update it, then pull the model again. If memory runs out, use the 16.9 GB IQ4_XS file.

Adds are slow

Each add runs the memory model once. Use a smaller or faster model, make sure Ollama is using your graphics card, and run adds in the background after the reply is shown.

Frequently asked questions

A week later, Priya messaged the shop's assistant to ask about her laptop. It greeted her by name, said the battery had been replaced, and asked whether a text at five would suit her, because she prefers texts. Nothing about her had left the shop's computer. "It remembered her," Jake said. "It remembered what she told us," said Ethan, "and that's the right kind of remembering."

Revision note. Written October 19, 2026. "An elephant never forgets," the saying goes; with Mem0, your assistant can remember too, and still keep it all in the shop.