Why ChatGPT Forgets What You Said Earlier in the Same Conversation (2026)

The window has an edge, and you don't see it

Every model has a maximum context. A long conversation eventually exceeds it, at which point something has to go — earlier turns get dropped or compressed so the recent ones fit.

The interface doesn't show you this. There's no line in the thread marking where the model's view begins. So from your side the message is visibly present and being ignored; from the model's side it isn't there. That mismatch is the entire experience of this problem, and it's why the fix always seems to be repeating yourself more firmly.

Even inside the window, position matters

This is the part most people don't know, and it's the better explanation for the cases where the thread clearly still fits.

The finding comes from Lost in the Middle: How Language Models Use Long Contexts (Liu et al., TACL 2023). They tested multi-document question answering and key-value retrieval while moving the location of the relevant information, and reported that "performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models."

Map that onto a chat. Your setup instructions are at the beginning — good position. Your latest message is at the end — good position. The constraint you added at message thirty of ninety is in the middle, which is the weakest position in the input. Nothing about it was unclear; it was just badly placed by the passage of time.

Effective capacity is smaller than the advertised number

The second effect is that a stated context size is an upper bound, not a working capacity.

RULER: What's the Real Context Size of Your Long-Context Language Models? (Hsieh et al., 2024) built a synthetic benchmark going beyond simple needle-in-a-haystack retrieval to include multi-hop tracing and aggregation, and evaluated 17 long-context models. Their conclusion: despite near-perfect scores on the vanilla retrieval test, "almost all models exhibit large performance drops as the context length increases," and while the models all claimed 32K tokens or more, "only half of them can maintain satisfactory performance at the length of 32K."

That evaluation is from 2024 and the specific models have since been replaced, so read it as establishing the shape of the problem rather than as a current leaderboard. The shape has held: the number on the spec sheet describes what fits, not what the model uses well — and tasks needing reasoning across scattered pieces degrade earlier than tasks that just retrieve one fact.

Nothing tells you what was dropped

The compounding factor is silence. When earlier turns get trimmed or compressed, you don't get a notice. Practitioners who write about long agent sessions describe the same thing from the tooling side: an instruction from early in a session isn't being ignored, the model can no longer reliably reach it.

So you can't distinguish "it didn't follow the constraint" from "the constraint isn't in its view anymore," and those need opposite responses. The first calls for clearer instruction. The second calls for restructuring the conversation — and no amount of emphasis fixes it.

Repeating the instruction. Effective, immediately, and it tells you nothing about why. It also inflates the thread, which brings the next failure closer. This is the treadmill most people are on.

Putting everything critical in the first message. Genuinely smart — the beginning is a strong position. It holds until the thread grows long enough that the beginning gets trimmed, and it doesn't help with constraints you discover on message forty.

Starting a new chat. The most reliable single move, and the reason experienced users do it constantly. The cost is that you also drop everything useful, so you're trading a degraded thread for an empty one.

Asking it to summarize before continuing. A real technique: have it restate the constraints, then work from that summary near the end of the context. Effective and lossy — you're compressing, and what gets dropped is chosen by the model.

Custom instructions for the stable parts. Underrated, because these are re-supplied on every request rather than living in the transcript. The block is small, so it holds your handful of standing rules, not the specifics of this task. Worth using properly — and distinct from instructions that are set but don't take effect, which is a different problem.

Re-uploading the document. Common, and it fights the same current: an upload dropping out of context mid-thread is this same mechanism seen from the file side.

Notice what every workaround has in common. They're all ways of managing a transcript that's being used as storage.

The structural mistake is treating the thread as the record. A conversation is a working surface — good for thinking, bad for retention, and actively bad at length. Once your requirements only exist as messages, they're subject to position effects, trimming, and compression, none of which you can see.

So move the requirements out. Keep the constraint, the spec, the schema, the decision in a store the assistant reads from, and let each conversation be short and disposable. A short thread has no middle to get lost in.

That's the honest mechanism, and it's worth being precise about what it does and doesn't do: a memory layer does not extend the context window or fix attention within a long input. Nothing does. What it changes is that you no longer need the thread to be long, because the durable material is retrieved rather than restated — so you get to work in the regime where models are reliable instead of managing the regime where they aren't.

MemoryLake is a memory layer for that — your documents, constraints, and decisions in one store, readable from ChatGPT through the API and from MCP-capable tools like Claude and Codex directly. New chat, same knowledge, no ninety-message thread.

Step 1: Create an API key

Generate a key and make your first request in about 30 seconds. Keep it in your environment or a secret manager rather than pasting it into a chat window.

Step 2: Upload your first memories

Drop in the documents, images, and files you currently re-explain: the spec, the constraints, the style guide, the schema, the decisions. Upload the sources rather than summaries where you can — you're specifically trying to escape a workflow where everything is a compression of something else.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and other AI agents access to memory via MCP or the API. ChatGPT has no MCP client, so retrieve what you need through the API and inject it into the prompt, a custom GPT's instructions, or the workflow that calls the model. Tools that speak MCP read the same store directly.

The first difference is that your threads get shorter, and that's the whole win. Ten short conversations that each start from the same retrieved context beat one ninety-message thread that degrades in the middle — not because they're tidier, but because short inputs are where models actually perform.

The second is that "did it forget or did it disobey?" becomes answerable. When the constraint is supplied with the request rather than sitting thirty messages back, a failure to follow it is a real failure to follow it, and you can respond to what's actually happening.

The third is that starting fresh stops costing you anything. Right now a new chat means re-explaining; that's why people push threads far past the point of reliability. When the knowledge is retrieved, a new chat is free — and the constant re-explaining stops being the price of a clean context.

And it composes with the built-in memory rather than fighting it. Saved memory stays what it's good at — a page or two of stable preferences that doesn't fill up because you're not using it as a filing cabinet.

Treat thread length as a resource you spend

Decide in advance roughly how long a working thread should get, and start a new one when you pass it. Most people go far past the point of reliability because the alternative is re-explaining. Fix the re-explaining problem and this becomes easy.

Put critical constraints at the end, not just the beginning

Position works for you as well as against you. If something must hold for the next answer, restate it in the message you're sending — the end of the input is a strong position. This is why repeating works, and doing it deliberately for the two or three things that matter beats doing it reactively for everything.

Summarize on purpose, at a boundary you choose

When a thread has gotten long, ask for an explicit restatement of the requirements, check it, correct it, then start a new chat with that as your opener. You're doing the compression yourself, with review, instead of letting an invisible trim choose for you.

Never let a decision exist only in a transcript

If something is still going to be true next week, it belongs in a document or a store, not in message forty. This is the single habit that prevents the whole problem class, and it's also what makes the thread safe to abandon.

Suspect position before suspecting the model

When an instruction stops being followed, check where it sits in the conversation before rewriting it. Something established early in a long thread is in the weakest position in the input, and the correct response is restructuring, not rephrasing.

ChatGPT forgets what you said earlier in the same conversation because long inputs are handled unevenly. Information in the middle of a long context is used less reliably than information at the beginning or end — that's Lost in the Middle's finding, and it held even for models explicitly built for long contexts. And usable capacity runs well below the advertised number, which is what RULER demonstrated when half the models claiming 32K couldn't hold up at 32K. Your constraint wasn't ignored; by message ninety it was in the worst position of an input longer than the model handles well.

Which means the fix isn't a prompt technique. Stop using the transcript as your record: keep the durable material in a store the assistant reads from, keep the conversations short, and start new ones freely. You end up working in the range where models are reliable, instead of getting better at managing them where they aren't.