Context Window vs Memory: Why Your AI Still Forgets You

Two completely different mechanisms decide what an AI assistant knows when it answers you, and almost every piece of advice about "fixing AI memory" fails because it addresses the wrong one. The context window governs what the model can see right now, in this conversation. Memory governs what persists about you between conversations. They fail differently, they are fixed differently, and improving one does nothing for the other.

The reason this matters practically: when an assistant forgets something, your next move depends entirely on which mechanism dropped it. Re-explaining works for one and is pure waste for the other. Switching to a model with a larger window helps with one and is irrelevant to the other. Buying a memory tool helps with one and cannot touch the other.

This post separates them properly, gives you a test that tells you which one bit you, and is deliberately free of token counts — those change every few months, and a post organised around this quarter's numbers is wrong by next quarter. The structure does not change.

Two Mechanisms, One Word

The word "memory" gets applied to both, which is most of the problem.

The context window is working memory. It is the fixed amount of text the model can consider in a single request. Everything in it travels together: the system instructions, your messages, the model's replies, any files you attached, anything retrieved on your behalf. It exists only for the duration of the request. The model does not remember the previous message in any biological sense — the entire conversation so far is re-sent every single time, and the window is the ceiling on how much of it fits.

Memory is durable storage. It is a separate store, outside any conversation, holding facts or documents about you that get injected into future conversations. It persists when the chat closes. It is what lets a brand-new chat know your name, your job, or the project you are working on.

The clean way to hold the distinction: the context window is what the model is reading. Memory is what put some of it there.

Two consequences fall straight out. A fact in memory still has to occupy space in the context window to be used, so memory does not escape the window's limits — it competes for them. And a fact that is in the window but not in memory disappears the moment the conversation ends, no matter how important it was.

How Each One Fails

They produce different symptoms, which is what makes diagnosis possible.

Window failure happens within one conversation. You are deep into a long session and the model loses something from earlier in that same session. The scrollback still shows it, you can read it on your own screen, and the model behaves as though it is not there. The giveaway is that the lost material is visible to you and invisible to it, in the same chat.

Memory failure happens between conversations. You open a new chat and the assistant has no idea who you are or what you were working on yesterday. Everything from this conversation is available to it; nothing from the last one is.

A third pattern that is neither. The model has the information — it will confirm it if you point directly at it — but it has stopped acting on it. That is attention drift, not capacity, and it is the one where re-stating the instruction genuinely is the answer.

Check: does the forgotten thing appear in the scrollback of the conversation you are currently in? Yes means window. No, because it was in a different conversation, means memory. Yes, and the model acknowledges it when asked directly but ignores it otherwise, means drift.

Get this right before doing anything else. Nearly all misdirected effort here comes from treating a window problem as a memory problem, at which point people go and configure memory settings that were never involved.

Why a Bigger Window Does Not Give You Memory

Context windows have grown enormously, and every expansion is announced in a way that implies the forgetting problem is being solved. It is not, and the reason is categorical rather than a matter of degree.

A larger window means a longer single conversation before degradation. It means you can paste bigger documents. It does not mean anything survives the end of the chat. Close the conversation and every token in that enormous window is gone, exactly as completely as it was when windows were a hundredth of the size. Persistence is not a large amount of working memory. It is a different subsystem.

There is also a quality effect worth knowing about, independent of capacity. Material in the middle of a very long context tends to be used less reliably than material at the start or the end. Fitting something in is not the same as it being attended to, so a window big enough to hold your whole project history does not mean the model is weighing all of it evenly. Practically: putting the important constraint near the end of your message beats burying it on page four.

And there is a cost dimension. Everything in the window is processed on every turn, so a conversation that has accumulated a great deal of context is slower and more expensive per reply than a focused one. Bigger is not free, which is one reason providers manage long conversations rather than simply letting them grow. How that management shows up is covered in ChatGPT Context Loss Mid-Conversation.

Why Better Memory Does Not Fix the Window

The reverse also holds, and it is less obvious.

Memory features store a compact set of facts and supply them to new conversations. That is genuinely useful and it is what makes a fresh chat feel like it knows you. But a memory system cannot hold your working state for an in-progress task, because the working state is enormous, changes every few minutes, and is mostly detail rather than durable fact.

Memory is good at "prefers concise answers" and "works in TypeScript". It is not designed for "the current version of this function, the four constraints we established, and the thing we tried at 14:00 that did not work". That material belongs in the conversation, is bounded by the window, and dies with the chat. No memory feature changes that, and any product claiming to give you infinite conversational recall is either summarising heavily or retrieving selectively, both of which are lossy in ways you should expect rather than be surprised by.

So the honest framing is that memory extends continuity across conversations, not within them. Both problems are real. Neither product category solves the other. The overview of what the different tools in this space actually do is in Best AI Memory Tools.

The Third Axis Nobody Accounts For

Both mechanisms are also vendor-scoped, and this is where the day-to-day pain concentrates for anyone using more than one assistant.

Your context window is per-conversation, so it obviously does not cross products. But memory does not cross them either, and the mechanisms are not even the same shape. One platform extracts discrete facts into a list you can read and edit. Another attaches documents to a workspace that its conversations can draw on. A third stores a fixed instruction block you write yourself. There is no interchange format between them and no commercial reason for one to appear, since accumulated memory is a large part of what makes any of these hard to leave.

The practical consequence is that context established in one assistant has to be rebuilt by hand in the next one, and the more you invest in one vendor's memory the more expensive switching becomes. That is a lock-in mechanism, whether or not it was designed as one. How the three approaches compare side by side is in AI Memory Compared: ChatGPT, Claude and Gemini.

There is a smaller version of the same problem inside a single product. Switching models mid-conversation carries the transcript over — it is just text — but anything that was model-specific about how the earlier replies were produced does not carry, and a conversation whose early turns were written by a different model can read as subtly inconsistent afterwards. If behaviour changes right after you switched, that is the likely explanation rather than memory breaking.

What Actually Works

Given the split, the practical approach is to treat the two problems separately and stop expecting any single feature to handle both.

For window problems — within a conversation. Front-load the constraints that must hold and restate them periodically, since recent text is always sent verbatim and always attended to. Keep bulky material out unless it is needed, because every token spent on a file the model does not need is a token unavailable for the one it does. Start a new chat when re-establishing context costs less than the errors you are absorbing, and before you abandon the old one, ask for a handover summary and correct it before pasting it forward.

For memory problems — between conversations. Decide deliberately what deserves to persist, rather than letting an automatic extractor guess. Keep it short, because it competes for window space with the actual task. Review it periodically, because nothing expires on its own and stale context is worse than no context — a confidently applied fact that stopped being true last month is more damaging than a blank.

For the cross-vendor problem. Keep the durable material as plain text that you own, outside any assistant. Plain text pastes into every chat box that exists, survives every rename and staged rollout of a memory feature, and does not have to be rebuilt when you switch. This is unglamorous and it is the only approach that has not required redoing every time a product changes. The broader version of this argument is in Why AI Keeps Forgetting You.

Reading Product Claims

A short filter, since this space is marketed loudly.

When something is described as giving an assistant memory, ask which mechanism it touches. If it makes context easier to supply at the start of a conversation, it is a memory tool and it will not stop a long chat from degrading. If it manages what stays in a running conversation, it is working on the window and it will not help a new chat know who you are. Both are legitimate. Neither is both.

Then ask where the state lives and whether you can read it. A system that decides what to remember about you without showing you the result is one you cannot debug when it applies something wrong, and applying something wrong is the failure mode that actually costs you, because unlike forgetting it does not announce itself. A comparison of how the major assistants handle this is in Which AI Chatbot Has the Best Memory.

Where MindLock Sits

To be precise about the category: MindLock is a memory tool, not a context-window tool. It does nothing about a long conversation degrading, and no product can, because the window is a property of the model.

What it does is the between-conversations half, with the state visible. You save conversations worth keeping with Ctrl or Cmd plus S in ChatGPT, Claude, Gemini or Perplexity, or with the one-click button from the sideloaded Chrome extension, then upload the saved page. Distillation turns them into memory documents — a profile memory plus topic memories — which are plain text you can open, read and edit rather than an opaque store. Semantic search across them means you can find the relevant one without remembering which conversation it came from. Then you select what is relevant, generate a context block, and paste it into whichever assistant you are using, which is what makes it portable rather than vendor-scoped. What the documents look like is in Memory Documents.

Two caveats stated plainly. Nothing is automatic: saving is a keystroke you press, and memory documents update when you re-run distillation rather than continuously, so a document is as current as your last distil. And local distillation runs on your own GPU via WebGPU, so hardware without WebGPU support cannot use it and would need the cloud option on the paid tier. The split is on the pricing page.

The Short Version

The context window is what the model can see in this conversation. Memory is what persists between conversations. They are separate subsystems and they fail in different places, so the first question is always whether the forgotten thing is visible in the scrollback of the chat you are in.

A bigger window buys you a longer single conversation and buys you nothing across conversations. A better memory feature buys you continuity between chats and cannot hold the working state of an in-progress task. Expecting either to cover the other is the mistake underneath most of the advice in this area.

Both are also vendor-scoped, which is the part that stings if you use more than one assistant, and the only durable answer is to keep what matters as plain text you own and supply it deliberately. That is unfashionable, it is entirely under your control, and it still works after every product update.