Claude Memory: How It Works, Its Limits, and How to Extend It

Claude memory now spans two distinct surfaces, and this guide covers both. On the consumer side, Anthropic's Claude app memory saves short facts like a user's role, projects, people and preferences, then reuses them in new chats; it ships on by default for Free, Pro and Max plans and stays off for Team and Enterprise until an owner enables it. On the developer side, the Claude API exposes a separate memory tool, currently in beta behind the context-management-2025-06-27 header, that runs client-side so the application decides where state lives. The sections ahead map how each surface works, where the limits sit, and how teams add persistent memory through an external layer. Cognee appears later as one such memory engine, a knowledge graph plus vector store that connects to Claude Code over MCP.

What is Claude memory?

Claude memory refers to two distinct surfaces. The first is the consumer feature in Anthropic's Claude apps, which saves short topics about the user, such as role, projects, people and preferences, and reuses them in new chats. It is on by default on Free, Pro and Max plans and off by default on Team and Enterprise until an owner enables it. The second is the Claude API memory tool, currently in beta behind the context-management-2025-06-27 header, which runs client-side so the developer's application controls storage. Cognee is a separate memory engine for AI agents that builds a searchable knowledge graph combining vector, graph and relational stores, acting as a persistent layer alongside Claude.

Why Claude memory matters in 2026

Claude memory is now a default-on behavior on Free, Pro, and Max plans, saving short facts about a user's role, projects, and preferences for reuse in new chats. Each Claude project keeps a separate memory and summary, so a single user can hold several isolated stores. For API builders, the memory tool runs in beta behind the context-management-2025-06-27 header and operates client-side, putting storage decisions in the application's hands. When agents carry state across sessions and tools, teams need control over what is remembered and where it lives, which is why external, graph-backed layers like Cognee enter the picture.

How Claude memory works across the app and API

Claude memory behaves differently depending on whether a user is in the Claude app or calling the API. In the app, memory is built on extractive summarization: Claude decides whether a given detail is worth remembering before anything enters persistent storage, instead of retrieving across full past transcripts at query time. What gets saved is additive, short facts, roles, projects, people and preferences, not a running log of every message. The API exposes a separate memory tool that Claude can call, but the actual storage lives on the application side, which keeps control over where memory data goes.

Claude app memory

In the consumer apps, memory is on by default for Free, Pro and Max accounts and off by default for Team and Enterprise until a workspace owner enables it. When active, Claude extracts short topics such as a user's role, ongoing projects, collaborators and stated preferences, then reuses them in new chats. Users manage this under Settings > Memory, where saved items can be viewed, edited or deleted. Because the mechanism is extractive summarization rather than retrieval over every past conversation, the stored set stays small and specific, and anything Claude judged not worth remembering simply never enters persistent memory.

The Claude API memory tool

On the API, memory is exposed through a tool that is currently in beta and enabled by sending the context-management-2025-06-27 beta header. The design is client-side: Claude only requests memory operations such as reads, writes or deletions, and the application executes each request against storage it controls, then returns the outcome in a tool_result block. Paths under /memories are a logical prefix that the application maps onto real storage, whether that is a local filesystem, an object store, a database or a dedicated memory service. The model never touches storage directly, which keeps data placement and retention in the developer's hands.

Projects and separation

Each Claude project maintains its own memory and running summary, isolated from other projects and from chats that live outside any project. A detail captured while working inside a client project does not leak into an unrelated one, and app memory stays on Anthropic's servers rather than syncing outward. It also does not follow the user into ChatGPT, Cursor or Gemini, each of those tools builds its own separate picture from its own interactions. For teams spanning multiple assistants, this per-project, per-tool scoping is the baseline to design around when planning any shared memory layer.

Limits of Claude's built-in memory

Claude's built-in memory works well for individual recall inside a single app surface, but it was not designed to serve as a shared, portable knowledge base for teams or multi-tool agent stacks. Memory is scoped per user and per project, it stays locked to Anthropic's servers, and the extraction logic is opaque to the person using it. For developers assembling agent workflows across Claude Code, Cursor, Codex, and other MCP clients, these constraints quickly become blockers. The gaps are where an external memory layer like Cognee becomes relevant, especially when deterministic recall and auditability matter.

Common limitations users and developers hit

• Scope is per-user and per-project, no shared team memory. Each Claude project keeps its own memory and summary, separate from other projects and from non-project chats, so teammates cannot pool what Claude has learned across their work.
• No cross-tool portability. Claude memory lives on Anthropic's servers and does not follow the user to ChatGPT, Cursor, or Gemini; each tool builds its own separate picture of the user and the project.
• Extractive and opaque. Claude app memory uses extractive summarization rather than retrieval over all conversations, and Claude itself decides whether something is "worth remembering" before it enters persistent memory, so recall is not deterministic.
• Deleting a chat does not delete the memories made from it. Memory can be viewed, edited, paused, or reset from Settings > Memory, but removing a conversation leaves derived memories in place, which complicates audit trails and cleanup.

A graph-based memory layer closes these gaps. Cognee builds a knowledge graph from the underlying data and makes it searchable through combined vector, graph, and relational stores, so recall is driven by explicit relationships rather than a hidden "worth remembering" judgment. Pluggable backends across Neo4j, Amazon Neptune, PostgreSQL, Kuzu, Redis, LanceDB, and pgvector let teams keep memory in storage they already control, which addresses both portability and audit. The Cognee MCP server then exposes that same graph to any MCP client, Claude Code, Cursor, or Codex, through remember, recall, and forget tools, so one shared memory follows the work across tools instead of fragmenting per app.

What to look for in an external memory layer for Claude

Pairing Claude with a persistent memory layer is a long-term decision, so the evaluation should go beyond "does it store text." The right system has to speak the same protocols Claude Code and other assistants already use, model relationships between facts instead of only similarity, keep track of when information was true, fit into the storage stack a team already runs, and respect the boundaries between projects and squads. The five criteria below cover the capabilities that matter most when the memory layer is expected to serve both interactive chats in Claude and automated runs through the Claude API or Agent SDK.

Must-have capabilities

• MCP-native integration so Claude Code, Cursor, and Codex can read and write to the same memory store without a bespoke adapter for each client.
• Knowledge-graph plus vector retrieval, not embeddings alone, so answers include the entities and relationships behind a fact rather than just nearby text chunks.
• Time-aware facts with validity windows, so retrieval can be constrained to a period and superseded assertions do not resurface as current truth.
• Pluggable storage backends that reuse existing graph, vector, and relational infrastructure instead of forcing a new database into the stack.
• Workspace and dataset-level access control so multiple teams can share one deployment without seeing each other's data.

Cognee maps to each of these criteria. Its MCP server exposes remember, recall, and forget tools over HTTP, SSE, and stdio transports, which lets Claude Code and Cursor hit the same store. Retrieval runs over a knowledge graph combined with vector and relational stores rather than embeddings alone. Temporal metadata records when an assertion became valid, when it ended, and when another record superseded it. Backends are pluggable across Neo4j, Amazon Neptune, PostgreSQL, Kuzu, Redis, LanceDB, and pgvector. Workspaces act as the unit of separation, and datasets within a workspace carry their own access rules.

How teams extend Claude memory using Cognee

Engineering and research teams attach Cognee to Claude Code and Claude Desktop through MCP to give Claude persistent, graph-backed memory that outlives any single conversation. The Cognee MCP server speaks HTTP, SSE, and stdio, so the same memory store can sit behind a desktop chat, a terminal coding agent, or a background pipeline. A dedicated Claude Code plugin captures tool calls into session memory via lifecycle hooks and syncs that session into the permanent knowledge graph when work wraps, letting Claude recall architectural decisions, prior reasoning, and project facts on the next prompt without manual re-pasting.

• Capturing coding sessions: Cognee Claude Code plugin with SessionStart, PostToolUse, UserPromptSubmit, PreCompact, and SessionEnd hooks that initialize memory, log significant actions, inject graph context into prompts, preserve state before context resets, and bridge the session into the permanent graph.
• Sharing context across tools: a single Cognee store read and written by Claude Code and Cursor over MCP, so a decision captured in one client is retrievable from the other.
• Building a research memory: the ECL pipeline ingesting from 38+ sources into a knowledge graph, following the pattern Bayer uses to compress 10,000 scientific papers into a research memory that supports hypothesis generation.
• Running the cognify pipeline: a six-stage flow that classifies documents, checks permissions, extracts chunks, uses an LLM to pull out entities and relationships, generates summaries, then embeds and commits edges to the graph, re-processing only new or updated files.
• Time-constrained recall: temporal metadata recording when an assertion became valid, when it ended, or when a later record superseded it, so Claude can answer questions scoped to a specific period.
• Separating squads: workspaces as the unit of isolation, with datasets inside each workspace carrying their own access rules for multi-team deployments.

The shape of this integration is what sets Cognee apart from adjacent tools. Zep Cloud focuses on hosted conversational memory with Flex at $125/month and Flex Plus at $375/month, and reserves SOC 2 Type II and HIPAA BAA coverage for Enterprise contracts. Graphiti, an open-source temporal knowledge graph library, concentrates on modeling how facts change over time but offers narrower MCP coverage for Claude clients. Cognee combines the temporal graph model, a Claude-native plugin, cross-client MCP transport, and workspace-level tenancy in one open-source stack that teams can self-host or run on Cognee Cloud.

Best practices for working with Claude memory

Claude's memory behaves differently in the consumer apps, the API memory tool, and in developer setups that route memory through MCP. That means the right habits depend on where the memory actually lives and who controls the underlying storage. The practices below cover both sides: tidy use of the built-in features in the Claude apps and projects, and the operational hygiene teams need when they wire Claude to an external memory layer through the API memory tool or an MCP server. Each one maps to a concrete control surface rather than a general guideline.

• Audit and reset from Settings: Open Settings > Memory to view, edit, pause, or reset what Claude remembers whenever a role, client, or project changes. Deleting a chat does not delete the memories it generated, so prune the memory list directly.
• Isolate work in Claude projects: Each project keeps its own memory and summary, separate from other projects and non-project chats. Use a dedicated project per client or codebase so unrelated context does not leak between workstreams.
• Treat /memories as storage you own: With the Claude API memory tool, Claude only requests operations and the application executes them against storage it controls, returning results in a tool_result block. Keep audit logs of those tool_result operations and version the real backend behind the /memories prefix.
• Automate capture for codebases: Install the Cognee Claude Code plugin so SessionStart initializes memory, PostToolUse captures significant actions, UserPromptSubmit injects graph context, PreCompact preserves state before context resets, and SessionEnd syncs the session into the permanent knowledge graph.
• Give each MCP client its own dataset: Cursor defaults to cursor_vscode_memory and Claude Code to claude_code_memory, so different agents do not share memory by accident. Point clients at a shared dataset only when shared recall is the goal.
• Harden regulated deployments: For sensitive workloads, run Cognee air-gapped or in a bring-your-own-cloud configuration, with encryption at rest and in transit and GDPR compliance in place before any production data enters the memory layer.

Benefits of extending Claude with a dedicated memory layer

Pairing Claude with Cognee turns short-lived chat context into a persistent, queryable knowledge layer that both the Claude apps and developer tools can share. Instead of relying on opaque in-app summaries, teams get a knowledge graph plus vector index, temporal metadata on every assertion, and workspaces that keep squads separated inside one deployment. The result is measurable: continuity across clients like Claude Code and Cursor, retrieval that can be inspected and tuned across 20 search types, and backends that slot into whatever graph and vector stores a team already runs.

• Continuity across tools: Claude Code and Cursor can read and write the same Cognee memory store over MCP, which supports HTTP, SSE, and stdio transports, so a decision captured in one client is available in the next session from another.
• Deterministic retrieval: Cognee's ECL pipeline builds a knowledge graph with embeddings and relationships and exposes 20 search types, from classic RAG to chain-of-thought graph traversal, replacing opaque extractive summaries with results whose graph context is visible.
• Time-aware answers: temporal metadata records when an assertion became valid, when it ended, and when another record superseded it, so Claude can answer questions constrained to a specific period instead of blending stale and current facts.
• Reuse of existing infrastructure: backends are pluggable across Neo4j, Amazon Neptune, PostgreSQL, Kuzu, Redis, LanceDB, and pgvector, so Claude memory can sit on top of storage a team already operates.
• Team separation: the workspace is the unit of isolation, and datasets inside a workspace carry their own access rules, letting multiple squads share one Cognee deployment without crossing data boundaries.

How Cognee extends Claude memory in practice

Cognee adds a persistent memory layer on top of Claude in three complementary pieces. The core is an Apache-licensed Python engine, installable with pip install cognee from the topoteretes/cognee repository, that builds a knowledge graph plus vector index from conversations, documents, and code. On top of that engine, Cognee ships an MCP server that exposes remember, recall, and forget tools to any MCP client, including Claude Code, Cursor, and Codex. A dedicated Claude Code plugin complements the MCP server by capturing tool calls into session memory through hooks and syncing them to the permanent knowledge graph at session end.

Install and connect

The fastest path is Cognee Cloud's hosted MCP server at https://mcp.aws.cognee.ai/mcp. From a terminal with Claude Code installed, run:

claude mcp add --scope user --transport http cognee https://mcp.aws.cognee.ai/mcp

Cognee MCP supports HTTP, SSE, and stdio transports, so the same server works for local processes and remote agents. Each client receives an auto-named dataset by default: Claude Code connects to claude_code_memory, while Cursor connects to cursor_vscode_memory. Different agents therefore do not share memory unintentionally, but they can be pointed at the same dataset when continuity across tools is the goal.

Pricing

Cognee Cloud is usage-based and priced at $1.00 per 1M tokens processed, plus $5 per additional workspace. A free tier includes 1M tokens and one workspace, which is enough to connect Claude Code, Codex, and other MCP clients with unlimited users and unlimited API calls, and no card is required at sign-up. Teams that outgrow a single workspace pay per extra workspace and per million tokens actually processed by the memory pipeline. Enterprise adds dedicated support, SLAs, and bring-your-own-cloud deployment for organizations that need to keep the knowledge graph and vector store inside their own infrastructure.

Final thoughts and next steps

Claude memory is useful for personal continuity inside the Claude app and controllable through the API, but its scope stays narrow. Memory lives on Anthropic's servers and does not follow users to other tools, and each project keeps its own separate summary. Teams that need persistent, portable, graph-structured memory for Claude Code and Claude Desktop can attach Cognee over MCP. The free Cognee workspace covers Claude Code, Codex, and MCP with unlimited users and API calls, and the Standard plan is $1.00 per 1M tokens processed, plus $5 per additional workspace. Try Cognee Cloud to get started.

Related guides

• Claude Code Memory: CLAUDE.md, Auto Memory, and Persistent Memory Across Sessions
• MCP Memory: What It Is and How to Give Any MCP Client Persistent Memory
• Claude Agent SDK: Persistent Memory with the Cognee Integration
• LLM Memory Explained: Types, Architectures, and How to Add It
• AI Agent Memory: What It Is and How It Works

Frequently Asked Questions

What is Claude memory and how does it work in the Claude app?+

Claude memory is Anthropic's feature that saves short topics from conversations, such as a user's role, projects, people and preferences, and reuses them in new chats. It is on by default on Free, Pro and Max plans and off by default on Team and Enterprise until an owner enables it. Memories can be viewed, edited, paused or reset from Settings > Memory, and each Claude project keeps its own memory separate from other projects. For graph-based persistence that spans tools and sessions, teams add Cognee as an external memory layer.

Does Claude have memory in the API by default?+

The Claude API has no persistent memory by default. Anthropic offers a memory tool in beta, enabled via the context-management-2025-06-27 beta header. The tool runs client-side: Claude only requests memory operations, and the application executes each request against storage it controls, returning results in a tool_result block. The /memories path is a prefix mapped onto real storage chosen by the developer. Cognee works as a ready backing store for this pattern, exposing a knowledge graph and vector index that the application calls when fulfilling Claude's memory tool requests.

What are the limits of Claude's built-in memory?+

Claude's built-in memory is scoped per user and per project, with each project keeping its own separate summary. Memory lives on Anthropic's servers and does not follow the user to ChatGPT, Cursor, or Gemini, so each tool builds its own picture. The app uses extractive summarization rather than retrieval across all conversations, with Claude deciding what is worth remembering. Deleting a chat does not delete the memories made from it. Cognee addresses these gaps with deterministic graph plus vector retrieval and a shared store that multiple clients can query.

How can developers add persistent memory to Claude Code over MCP?+

Cognee MCP is a Model Context Protocol server that gives AI assistants persistent memory backed by a Cognee knowledge graph. Claude Code, Cursor and Codex can store and recall memories through the remember, recall and forget tools, and the server supports HTTP, SSE and stdio transports. Cognee also ships a dedicated Claude Code plugin that hooks into SessionStart to initialize memory, PostToolUse to capture significant agent actions, UserPromptSubmit to inject relevant graph context, PreCompact to preserve memory before context resets, and SessionEnd to bridge session data into the permanent graph.

How much does Cognee cost to use with Claude Code?+

Cognee Cloud is usage-based. The free tier includes 1M tokens and one workspace, with no card required at sign-up, and supports agentic integrations including Claude Code, Codex and MCP, plus unlimited users and unlimited API calls. Beyond the free tier, pricing is $1.00 per 1M tokens processed, plus $5 per additional workspace on the Standard plan. Enterprise adds dedicated support, SLAs and bring-your-own-cloud deployment. Teams can connect Claude Code to the hosted MCP server using: claude mcp add --scope user --transport http cognee https://mcp.aws.cognee.ai/mcp.

Can Cognee share memory between Claude Code, Cursor, and Codex?+

Yes. Claude Code and Cursor can read and write to the same Cognee memory store, giving context continuity across tools. By default, each MCP client receives an auto-named dataset so agents do not unintentionally share memory: Claude Code connects to claude_code_memory and Cursor connects to cursor_vscode_memory. Sharing is opt-in, configured by pointing clients at a common dataset. Because Cognee MCP supports HTTP, SSE and stdio transports, the same knowledge graph can back a local developer setup or a hosted deployment used across an entire team.