Overview

The new Mem0 memory algorithm is a ground-up redesign of how memories are extracted, stored, and retrieved. It scores 91.6 on LoCoMo and 93.4 on LongMemEval — a +20 and +26 point improvement over the previous algorithm — while cutting extraction latency roughly in half.

What This Means for Your Application

Memories accumulate instead of being overwritten

The previous algorithm could UPDATE or DELETE existing memories during extraction. The new algorithm only adds new facts. When information changes (e.g., a user moves from New York to San Francisco), both facts are preserved with temporal context. This means:

• More memories over time — your memory count will grow rather than plateau
• Better temporal reasoning — the system can distinguish "used to live in New York" from "now lives in San Francisco"
• No information loss — facts that seemed contradictory but were actually complementary are preserved

Agent-generated facts are now captured

Previously, when an agent said something like "I've booked your flight for March 3rd," the system would often ignore it and only store what the user explicitly stated. The new algorithm treats agent-generated facts as first-class memories. If your application involves agents that confirm actions, provide recommendations, or share information, you'll see significantly better recall on those interactions.

Retrieval is hybrid now

Search now uses hybrid retrieval, which improves ranking quality — especially for queries involving exact keywords, proper nouns, or entities that appear across multiple memories. The response shape is unchanged:

{
  "results": [
    {
      "id": "mem-uuid",
      "memory": "User moved to San Francisco in January 2026",
      "score": 0.82,
      "metadata": {},
      "categories": ["location"]
    }
  ]
}

The top-level score remains a [0, 1] value. Relative ranking between results stays comparable to v2, but absolute numbers shift since the scoring method changed — retune any hard thresholds in your app against representative queries.

API Changes

New V3 Endpoints

The new algorithm is available through the V3 API. The endpoints split into per-operation paths:

client = MemoryClient(api_key="your-api-key")

Add memories (same interface, improved extraction)

result = client.add( messages=[ {"role": "user", "content": "I just moved to San Francisco from New York"}, {"role": "assistant", "content": "That's exciting! I'll update your location preferences."} ], user_id="alice" )

Search with multi-signal retrieval

results = client.search( query="where does the user live?", filters={"user_id": "alice"} )

List memories (paginated)

page = client.get_all(filters={"user_id": "alice"}, page=1, page_size=50)

page == {"count": 123, "next": "...", "previous": None, "results": [...]}

```bash cURL
# Add memories
curl -X POST https://api.mem0.ai/v3/memories/add/ \
  -H "Authorization: Token your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      {"role": "user", "content": "I just moved to San Francisco from New York"},
      {"role": "assistant", "content": "That'\''s exciting! I'\''ll update your location preferences."}
    ],
    "user_id": "alice"
  }'

# Search memories
curl -X POST https://api.mem0.ai/v3/memories/search/ \
  -H "Authorization: Token your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "where does the user live?",
    "filters": {"user_id": "alice"}
  }'

# List memories (paginated)
curl -X POST 'https://api.mem0.ai/v3/memories/?page=1&page_size=50' \
  -H "Authorization: Token your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"filters": {"user_id": "alice"}}'

Search Parameter Changes

Response Format

Add response — asynchronous, returns an event_id for polling:

{
  "message": "Memory processing has been queued for background execution",
  "status": "PENDING",
  "event_id": "evt-uuid"
}

Poll status via GET /v1/event/{event_id}/ — status will be SUCCEEDED or FAILED.

Search response — combined multi-signal score per result:

{
  "results": [
    {
      "id": "mem-uuid",
      "memory": "User moved to San Francisco from New York in January 2026",
      "score": 0.82,
      "metadata": {},
      "categories": ["location"],
      "created_at": "2026-01-15T10:30:00Z",
      "updated_at": "2026-01-15T10:30:00Z"
    }
  ]
}

List response — paginated envelope (new in V3):

{
  "count": 123,
  "next": "https://api.mem0.ai/v3/memories/?page=2&page_size=50",
  "previous": null,
  "results": [
    {
      "id": "mem-uuid",
      "memory": "...",
      "metadata": {},
      "categories": [],
      "created_at": "2026-01-15T10:30:00Z",
      "updated_at": "2026-01-15T10:30:00Z"
    }
  ]
}

SDK Breaking Changes

Alongside the algorithm update, the Python and TypeScript client SDKs have been cleaned up. These changes affect how you initialize and call the client.

Python Client SDK

from mem0 import MemoryClient

# Before
client = MemoryClient(
    api_key="...",
    org_id="org-1",       # [REMOVED] Removed
    project_id="proj-1"   # [REMOVED] Removed
)
client.add(messages, user_id="alice", async_mode=True, output_format="v1.1")

# After
client = MemoryClient(api_key="...")
client.add(messages, user_id="alice")
# async_mode and output_format removed (async by default, v1.1 always)

Removed parameters: org_id, project_id, api_version, output_format, async_mode, enable_graph, immutable, expiration_date, filter_memories, batch_size, force_add_only, includes, excludes, keyword_search, org_name, project_name

TypeScript Client SDK

All parameters now use camelCase (the SDK handles conversion to/from the API automatically):

// Before
const client = new MemoryClient({
  apiKey: "...",
  organizationId: "org-1",  // [REMOVED] Removed
  projectId: "proj-1"       // [REMOVED] Removed
});
await client.search("query", {
  user_id: "alice",          // [REMOVED] snake_case
  top_k: 20,                 // [REMOVED] snake_case
  enable_graph: true          // [REMOVED] Removed
});

// After
const client = new MemoryClient({ apiKey: "..." });
await client.search("query", {
  filters: { userId: "alice" },  // [OK] inside filters
  topK: 20                       // [OK] camelCase
});

Removed: OutputFormat enum, API_VERSION enum, organizationId, projectId, organizationName, projectName, enableGraph, asyncMode, outputFormat, immutable, expirationDate, filterMemories, batchSize, forceAddOnly, includes, excludes, keywordSearch

Graph Memory → Entity Linking

Graph memory has been replaced by built-in entity linking. The changes:

• Graph visualizations removed from the platform dashboard. The graph view in your project dashboard is no longer available.
• enable_graph project setting removed. The toggle is gone from the dashboard; the API parameter is ignored.
• No external graph store to configure. Previously graph memory required a separate Neo4j (or similar) deployment. Entity linking runs natively inside the platform — nothing to provision, no connection strings to manage.
• Entity linking is the native replacement. Entities (proper nouns, quoted text, compound noun phrases) are automatically extracted from every memory and linked across memories belonging to the same user. At search time, entities from the query are matched against this index and used to boost ranking. The boost is folded into the combined score returned on each result.

No migration work is required. Entity linking activates automatically for all projects on the new algorithm. Existing memories are not re-processed, but any new memories you add will be indexed for entity-based retrieval going forward.

Migration Checklist

Backward Compatibility

• V1 and V2 endpoints continue to work. There is no requirement to migrate to V3 endpoints immediately.
• Existing memories are preserved. The new algorithm does not modify or re-process previously stored memories.
• Search response shape is unchanged. The top-level score and results[] array are the same; existing code that reads score continues to work. What changed is the scoring method behind the number (multi-signal fusion instead of pure cosine), so the absolute values shift even when ranking stays comparable.
• List response shape changed. get_all now returns a paginated envelope ({count, next, previous, results}) instead of a bare {results: [...]}. Update code that reads response["results"] to continue working, or switch to the client SDKs which handle both shapes.

Performance Improvements

All benchmarks were run on a production-representative stack — deliberately avoiding frontier models to keep numbers representative of real production workloads.

FAQ

Need Help?

If you run into issues during migration or have questions about the new algorithm:

• Join our Discord community for real-time support
• Email us at [email protected]
• Check the API reference for detailed endpoint documentation