Context Window vs. Persistent Memory: Why Claude Needs Both
Claude's context window and persistent memory solve different problems. The context window is temporary working memory that holds everything in the current conversation — up to 1M tokens on models like Claude Sonnet 5 and Claude Opus 5 — and it resets, or gets summarized away, once a session ends. Persistent memory, built with Anthropic's memory tool or an MCP server like open-context, is what survives after that window closes: facts, preferences, and decisions Claude can read back in a future session that otherwise starts from nothing. A production Claude setup needs both — a large window to reason over what's in front of it right now, and a durable store to carry context forward.
Key takeaways
- A context window is Claude's "working memory" for one conversation — up to 1M tokens on Claude Sonnet 5 and Opus 5, 200K on Claude Haiku 4.5 — and it does not persist once the session ends.
- More tokens isn't automatically better: Anthropic documents "context rot," where accuracy and recall degrade as token count grows, even well inside the limit.
- Anthropic's own memory tool exists specifically so Claude can store and retrieve information across conversations "without keeping everything in the context window" — proof Anthropic treats these as two separate layers, not one bigger buffer.
- MCP (Model Context Protocol), the open standard Anthropic introduced in November 2024, is what lets a tool like open-context give Claude a persistent, queryable memory store outside any single conversation.
- open-context's MCP server implements this with six context tools —
save_context,recall_context,list_contexts,search_contexts,update_context,delete_context— backed by a store you control, from a local JSON file up to Postgres or Redis.
What a context window actually is
Anthropic's own documentation defines the context window plainly: it's "all the text a language model can reference when generating a response... a 'working memory' for the model," distinct from the training data baked into the weights. Every message, tool call, and document in a conversation accumulates inside it turn by turn, and current models can hold a lot — Claude Sonnet 5, Opus 5, and Fable 5 carry a 1M-token window by default at standard pricing, while Claude Haiku 4.5 carries 200K.
That capacity is real, but it's scoped to the conversation it belongs to. Close the chat, start a new one, or let a long agent session get compacted, and whatever lived only in that window is gone unless something wrote it down somewhere else first.
Why a bigger window doesn't solve the memory problem
It's tempting to treat a 1M-token window as "enough memory for anything" — a year of chat history can fit in a single prompt, after all. Two things get in the way of that.
Context rot
Anthropic's own guidance on long-context prompting warns that accuracy and recall degrade as token count grows, a pattern it calls context rot. Curating what's actually in context matters as much as how much room there is — dumping an entire history back into every new conversation makes Claude's job harder, not easier.
The window is still session-bound
No matter how large the limit, a new conversation starts empty. A 1M-token budget describes how much a single session can hold, not whether Claude remembers you were mid-project last Tuesday. Pasting old transcripts back in to compensate burns tokens re-establishing context every single time, instead of once.
What persistent memory adds
This is the layer Anthropic itself built to sit next to the context window rather than inside it.
The memory tool lets Claude create, read, update, and delete files in a /memories
directory that persists between sessions, so it can "build up knowledge over time without keeping
everything in the context window." Claude checks that directory before starting a task and writes
back what it learned — Anthropic calls this "just-in-time context retrieval," loading only what's
relevant instead of front-loading everything.
MCP
(Model Context Protocol) is the open standard, introduced by Anthropic in November 2024, that makes
this pattern portable across any client instead of tying it to one vendor's file format. An MCP
server exposes memory as tools any MCP-compatible client can call. open-context's MCP server is a
concrete implementation of that: save_context when you say "remember this,"
recall_context and search_contexts to pull it back later,
update_context and delete_context to keep it current, plus bubble tools
to group related contexts into project workspaces (see our post on
organizing memory with bubbles).
None of it depends on the context window at all — it's a database call, not a token.
How the two work together in one session
In practice, a well-built Claude Code or Claude Desktop setup runs both layers on every turn:
- Session starts. Claude checks what's already saved —
list_contexts,recall_context, or a memory-fileview— before doing anything else. - Relevant facts load into the context window. Only what's needed for the task at hand enters working memory, not the entire history.
- Claude works the problem inside the window it has for this turn.
- Before the session ends, anything worth keeping gets written back out —
save_contextorupdate_contextfor open-context, a memory-file edit for Anthropic's own tool.
The context window handles reasoning over what's active right now. The persistent store handles everything that needs to outlive the conversation. Skip the second layer, and every new chat starts from zero no matter how big the window is.
Setting this up with open-context
open-context ships this as a local-first MCP server: six context tools plus bubble tools for
project grouping, running against a store you pick — the default is a zero-config JSON file at
~/.opencontext/contexts.json, with SQLite, Postgres, MongoDB, Redis, and ten other
backends available through the same interface (see
choosing between SQLite and Postgres
for when that switch is worth it). Connect it to Claude Code or Claude Desktop by pointing at
dist/mcp/index.js, or run the bundled Docker image
(running an MCP server in Docker
walks through both). Nothing leaves your machine: the server only talks to the database you
configured, and credentials are redacted from every log line and API response.
Which one you actually need
For a single task inside one conversation — debug this function, review this document — the context window alone is enough; there's nothing to remember afterward. Persistent memory earns its keep the moment work spans more than one session: a multi-day project, a preference you want Claude to honor automatically from now on, or a team's shared context that shouldn't live in any one person's chat history. Most real Claude usage is a mix of both, which is exactly why Anthropic ships a memory tool at all instead of just shipping bigger windows.
Give Claude persistent memory that outlives the context window.
Get started with open-context →FAQ
What is a context window, in plain terms?
It's the "working memory" for one Claude conversation — every message, tool result, and document Claude has seen in the current session, up to a per-model token limit (1M tokens on Claude Sonnet 5 and Opus 5, 200K on Claude Haiku 4.5). It resets when the conversation ends.
Does a 1M-token context window mean Claude remembers me across sessions?
No. The token limit describes how much one conversation can hold, not whether that information survives into a new one. A fresh chat starts empty regardless of window size unless something — a memory tool, an MCP server, or you pasting old context back in — carries it forward.
What's the difference between Anthropic's memory tool and an MCP server like open-context's?
Both persist information outside the context window between sessions. Anthropic's memory tool is a file-based capability built into the Claude API itself; an MCP server like open-context is a separate, open-standard service any MCP-compatible client can connect to, with its own storage (JSON, SQLite, Postgres, and more) that you control.
Does giving Claude more context always make its answers better?
No. Anthropic's own documentation describes "context rot" — accuracy and recall degrading as token count grows, even within the model's limit. Curating what's relevant matters more than maximizing how much is loaded in.
Do I need to run a database to get persistent memory with open-context?
No. The default store is a single JSON file with zero configuration. You only need a database if you outgrow that — thousands of saved contexts, or multiple machines sharing one memory store — and switching later doesn't require re-architecting anything.