September 2026 Summaries

Supermemory’s comparison post argues that Mem0’s competing comparison page contains incomplete or misleading claims about benchmarks, pricing, token use, and product capabilities, while acknowledging that the post is published by Supermemory and should be read with that bias in mind. It says Supermemory achieved 95% Recall@15 on LongMemEval_s with aggregation and leads on LoCoMo, whereas Mem0 cited a lower non-aggregated Supermemory result and left other benchmark entries blank; it also notes that BEAM is Mem0’s proprietary benchmark. The post contrasts Mem0’s Apache 2.0 core library, large community, broad framework integrations, and SOC 2 and HIPAA-supported managed offering with Supermemory’s MIT-licensed full engine, offline single-binary self-hosting, multimodal ingestion, managed data connectors, automatic user profiles, versioning, contradiction resolution, and forgetting. It describes Mem0 as using manually managed memory objects and memory-count pricing, while Supermemory emphasizes usage-based pricing, published retrieval and token metrics, and broader lifecycle automation. It concludes that Mem0 may suit users seeking a lightweight embeddable library and established integrations, while Supermemory may better suit those needing managed ingestion, automatic memory maintenance, profiles, reproducible benchmark results, or simplified self-hosting.

Migrating from Mem0 Platform v3 to Supermemory requires redesigning application integration rather than simply renaming APIs, because the systems differ in isolation boundaries, ingestion, retrieval scoring, lifecycle behavior, and identifiers. The key architectural decision is mapping Mem0’s user, agent, app, and run scopes into Supermemory’s single deterministic containerTag authorization boundary while preserving other dimensions as metadata, with careful validation to prevent tenant data exposure. The process calls for an immutable, deduplicated Mem0 export; separate handling of extracted facts through direct memory creation and raw content through normal ingestion; metadata flattening; source-to-destination ID ledgers; and retry-safe checkpoints. Teams should dual-write production events, retain Mem0 as the read authority while backfilling, compare retrieval quality using a golden query set, and tune Supermemory limits and similarity thresholds independently rather than transferring Mem0 scores. Validation should test fact recall, isolation, expiration, duplicate handling, asynchronous indexing, latency, and lifecycle operations, since updates, deletion, forgetting, and expiration do not map directly between providers. A reversible rollout using shadow reads, feature flags, an append-only write log, and a representative pilot tenant is recommended, while Mem0 data should remain intact until rollback risks and production behavior have been fully verified.

A founder of Supermemory presents a competitor-biased comparison of Mem0 and several memory-management alternatives for AI agents, arguing that users often seek broader document ingestion, user profiles, connectors, managed infrastructure, and scalable retrieval beyond conversational fact extraction. The piece cites Scira AI’s reported migration from Mem0 to Supermemory, claiming improvements in latency and usage, while characterizing Mem0 as better suited to scoped chat memory when document retrieval is already handled elsewhere. It positions Supermemory as a managed and open-source memory engine with profiles, graph-based retrieval, connectors, local deployment, and multi-tenant controls; Zep as a temporal conversation-memory graph; Letta as a stateful autonomous-agent runtime; OpenMemory as a privacy-focused local MCP option; and Postgres with pgvector as a practical but more labor-intensive choice for early prototypes. It also contrasts pricing approaches, claiming Mem0’s request caps offer predictability while Supermemory’s usage-based model can be cheaper for high retrieval volumes, and outlines an export-and-import migration path from Mem0.

Supermemory is a Claude Code plugin designed to provide persistent, evolving memory across coding sessions, addressing the need to repeatedly supply project details, technical constraints, and personal preferences. Installed through Claude Code’s plugin marketplace, it automatically captures relevant conversations and tool activity, selectively recalls information before prompts, separates shared project knowledge from personal memory, and offers commands for indexing codebases, configuring projects, and managing sessions. Its approach complements rather than replaces CLAUDE.md files, which remain useful for fixed rules while persistent memory records changing decisions, work context, coding style, and past solutions. The system uses “hybrid memory” to extract and update facts over time rather than relying only on similarity-based retrieval, and it claims a 95% score with aggregation on the LongMemEval benchmark. Unlike the Supermemory MCP integration, the plugin can automatically inject a user profile at session start and capture interactions without depending on Claude to invoke tools, while also supporting self-hosted local operation for users who want data to remain on their own machines.

Hermes offers a native Supermemory provider intended to give agents persistent, cross-platform memory across channels such as Telegram, Discord, Slack, WhatsApp, Signal, and the CLI, addressing the limitations of large flat MEMORY.md files. After installation and API-key configuration, the provider automatically retrieves relevant context before conversations, captures cleaned turns after responses, ingests full sessions for richer updates, and supplies tools to save, search, forget, and retrieve profile information. Supermemory maintains evolving user profiles containing stable details and current priorities, supports separate memory containers for work, personal, and project contexts, and provides hybrid memory and document search, versioned updates, and deletion capabilities. It also preserves salient information before context-window compression, can mirror local MEMORY.md and USER.md files rather than replace them, and offers configurable recall, capture, search, and profile-refresh settings. The system can additionally be self-hosted through its MIT-licensed implementation so memory data can remain within an organization’s infrastructure.

Cognee and Supermemory are presented as differing approaches to AI memory systems: Cognee is described as an open-source framework that combines relational, vector, and graph databases operated by the user, while Supermemory is positioned as a managed or self-hosted memory engine with a unified API. The comparison, published by Supermemory and stated to have been reviewed against documentation in September 2026, argues that Cognee emphasizes infrastructure flexibility and requires users to configure storage backends, extraction pipelines, integrations, and retrieval behavior, whereas Supermemory includes built-in ingestion, profiles, memory versioning and expiration, multimodal processing, connectors, hybrid retrieval, and SDK integrations. It also contrasts Cognee’s manual deletion and temporal querying with Supermemory’s claimed lifecycle features for updating, resolving, and expiring memories, and cites Supermemory’s published benchmark results and latency figures while noting Cognee’s separate BEAM benchmark. The piece suggests Cognee may suit developers interested in assembling and operating their own memory infrastructure, while portraying Supermemory as better suited to production applications that require managed memory, user profiles, data-source connectors, tenant isolation, and measured retrieval performance.

OpenCode Supermemory is an open-source plugin designed to give OpenCode persistent memory across sessions by automatically injecting relevant user, project, and prior-session context, selectively recalling memories, capturing completed conversations, recognizing custom “remember” prompts, and preserving knowledge during context compaction. Installed through Bun commands or by having OpenCode process its README, the plugin stores configuration in the user’s OpenCode settings and includes an initialization command that explores a codebase to record its architecture and conventions. Its central feature is repository-based shared memory: OpenCode, Claude Code, and Codex plugins can access the same memory container derived from a repository’s Git origin, while separating personal and shared project memories and preserving compatibility with legacy containers. Agents use a Supermemory tool to add, search, view, list, and delete categorized memories, with configurable retrieval thresholds, capture schedules, compaction behavior, and keyword triggers. The plugin supports privacy through redaction of content inside private tags and can run fully offline through a self-hosted, MIT-licensed Supermemory instance. Unlike the Supermemory MCP alone, which depends on an agent choosing to invoke memory tools, the plugin ensures automatic context injection, capture, and compaction integration.

Supermemory discontinued its Company Brain product and Nova personal knowledge platform on September 9, refunding all charged users and ending access to the Company Brain dashboard and Slack bot. Its MCP integrations and plugins, including support for Claude Code, will remain available through the developer platform, while Nova’s underlying capabilities are being shifted to the company console. The company says the decision reflects a need to focus on its core mission of building memory systems for AI agents, avoid competing with customers that use its memory engine, and position itself as infrastructure for other organizations developing company-brain and agent products. Supermemory plans to concentrate on its memory API, which it describes as a frontier system for adding persistent, unified memory to commercial and personal agents.