Skip to main content

Memory & Personalization

Chat & Conversations map with the Memory cell highlightedChat & Conversations map with the Memory cell highlighted
Model-dependent quality

How well memories are stored and recalled depends heavily on the model. Frontier models manage memory well; small local models may store or retrieve information inconsistently.

Open WebUI includes a sophisticated memory system that allows models to remember facts, preferences, and context across different conversations. With the introduction of Native Tool Calling, this system has been upgraded from a passive injection mechanism to an active, model-managed "long-term memory."

How it Works​

The memory system stores snippets of information about you (e.g., "I prefer Python for backend tasks" or "I live in Vienna"). There are two ways these memories are used:

1. Manual Management (Settings)​

Users can manually add, edit, or delete memories by navigating to: Settings > Personalization > Memory

2. Native Memory Tools (Agentic Mode)​

When using a model with Native Function Calling (Agentic Mode) enabled, quality models can manage your memory autonomously using built-in tools. For a detailed breakdown of how administrators can configure and manage these system-level tools, see the Central Tool Calling Guide.

Minimum model tier (not a maintained list)

Autonomous memory management needs a model that can decide what facts are worth saving and when to recall them. That does not require a frontier model — GPT-5.6 Luna, Gemini 3.5 Flash-Lite, MiniMax M3, or locally Qwen 3.6 27B or Muse Glimmer 30B all do this well and are the minimum, each verified working at the time of writing. Only very small models struggle with appropriate memory selection.

This list is not continuously updated — chasing every model release is impossible and adds no value. Use whatever current model your provider offers; you don't need the latest and greatest, just something recent.

Each memory carries a type and an optional path (see Memory Types & Paths below). The model manages memory through these tools:

  • add_memory: Save a new fact, preference, or instruction, tagged as user or context, optionally under a path.
  • update_memory: Apply a batch of changes (add / replace / move / remove) in a single call.
  • replace_memory_content: Update or correct a specific existing memory using its id.
  • delete_memory: Remove a memory that is no longer relevant or correct, using its id.
  • search_memories: Search or browse the memory bank by content, path, type, or exact id. Results include a unique id per snippet (default returns 5).
  • list_memories: Retrieve all stored memories for the user, including content and timestamps.
  • list_memory_paths: List the saved memory paths (groups), so the model can find where related memories already live before writing.
  • read_memory_path: Read the memories stored at a given path, including nearby parent and child paths.

Memory Types & Paths​

Each memory has a type and an optional path:

  • Type — user memories are facts, preferences, or instructions about you (e.g. "prefers Python for backend"); context memories are other durable context worth carrying between chats. The two are budgeted separately when injected into the prompt (see Background Review & Limits).
  • Path — an optional stable "address" used to group related memories (e.g. work/projects), so the model can organize and browse them hierarchically with list_memory_paths / read_memory_path instead of one flat list.

These are set automatically by the memory tools; you do not need to assign them manually.

Benefits of the New Memory System​

  • Proactive Learning: Instead of you manually typing preferences, a model can say: "I'll remember that you prefer dark mode for your UI projects" and call add_memory behind the scenes.
  • Contextual Retrieval: If a conversation drifts into a topic mentioned months ago, the model can "search its brain" using search_memories to find those past details.
  • Dynamic Correction: If the model remembers something incorrectly, it can use replace_memory_content to fix the fact rather than creating a duplicate.
  • Cleanup: The model can use delete_memory to remove outdated or irrelevant facts, keeping your memory bank clean.
  • Full Visibility: Using list_memories, the model can review everything it knows about you and identify gaps or contradictions.
  • User Control: Even though models can add memories, users retain full control. Every memory added by a model can be reviewed and deleted in the Personalization settings.

Enabling Memory Tools​

  1. Administrative Enablement: Ensure the Memory feature is enabled globally by an administrator and that you have the required permissions.
  2. Native Mode (Agentic Mode): Enable Native Function Calling in the model's advanced parameters (Settings > Admin > AI > Models > Edit the model > Advanced Params).
  3. Minimum Model Tier: Use a current model with solid tool calling — at minimum GPT-5.6 Luna, Gemini 3.5 Flash-Lite, MiniMax M3, or Muse Glimmer 30B locally. Very small models may not manage memories reliably.
  4. Per-Model Category Toggle: Ensure the Memory category is enabled for the model in Workspace > Models > Edit > Builtin Tools (enabled by default).
Blank replies instead of memory operations

Memory runs as a native tool call, so it only works on a connection whose streaming output follows the OpenAI schema. On an endpoint that omits the index field on streamed tool calls, notably Google's OpenAI compatibility layer, the call is dropped and the turn returns an empty assistant message with nothing in the logs. Because the model decides on its own when to call list_memories or add_memory, this shows up as occasional blank replies rather than an obvious memory failure. See Blank Replies When the Model Uses a Tool.

Central Tool Documentation

For complete details on all built-in agentic tools (including memory, web search, and knowledge bases) and how to configure them, see the Native/Agentic Mode Tools Guide.

Administrative Controls​

Administrators have full control over the Memory feature, including the ability to disable it globally or restrict it to specific user groups.

Global Toggle​

The Memory feature can be toggled on or off for the entire instance. When disabled, the "Personalization" tab is hidden from all users, and the memory-related API endpoints are blocked.

  • Admin UI: Settings > Admin > System > General > Features > Memories
  • Environment Variable: ENABLE_MEMORIES (Default: True)

Granular Permissions​

Administrators can also control Memory access on a per-role or per-group basis from the Permissions interface.

Background Review & Limits​

Memory System Context​

By default Open WebUI injects the user's stored memories into the model's system context so the model is aware of them on every turn. This injection can be turned off independently of the memory tools: when disabled, the model can still add, update and delete memories on request, but remembered information is no longer added to the prompt automatically.

  • Admin UI: Settings > Admin > System > General > Memory System Context (shown when Memories is enabled)
  • Environment Variable: ENABLE_MEMORY_SYSTEM_CONTEXT (Default: True)

Privacy & Security​

Memories are stored locally in your Open WebUI database and are scoped to your user account. They are not shared with other users by default, and you can clear your entire memory bank at any time.

This content is for informational purposes only and does not constitute a warranty, guarantee, or contractual commitment. Open WebUI is provided "as is." See your license for applicable terms.