Context drift: why AI assistants forget what you told them, and what to do about it

You have seen it even if you have never had a name for it. An hour into a session with ChatGPT, Claude, Cursor or Lovable, the assistant that was sharp at the start begins to slip. It contradicts something you agreed twenty messages ago. It "fixes" a bug it already fixed, a different way. It rewrites a file you told it to leave alone. It is not getting dumber, and you are not imagining it. The conversation has outgrown what the model can pay attention to, and the behaviour that follows has a name.

Engineers call the underlying effect context rot, after a 2025 study by the team at Chroma. People describe the experience as context drift: the assistant gradually drifting away from what you told it. Both are the same thing seen from two sides. This article explains what is actually happening, why it starts long before any limit is reached, what it looks like in an AI-built app, and what you can do about it, both as someone prompting a tool and as a business putting AI into a real system.

The context window is working memory, not memory

Every large language model works inside a context window: a fixed budget of tokens (roughly three quarters of a word each) that holds everything the model can "see" while it writes a reply. Your instructions, the conversation so far, files it has read, the code it has produced, and its own earlier answers all sit in that window. On each turn the model re-reads the whole thing from scratch and predicts what comes next. There is no separate place where it stores what you said last week. If it is not in the window, it does not exist.

Windows have grown enormously. Anthropic's documentation puts the current Claude models at up to a million tokens, with 200,000 for others, and the other major providers are in the same range. That sounds like it should have solved the problem. It did not, and the research on why is unusually consistent.

Quality drops long before the window is full

Three findings matter most.

Position matters. A 2023 Stanford study titled Lost in the Middle found that model 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". Instructions you gave in the middle of a long session are exactly the ones most likely to be missed.

Length alone hurts, even without clutter. Chroma's Context Rot report evaluated 18 models, including GPT-4.1, Claude 4, Gemini 2.5 and Qwen3, on tasks where only the input length changed. Its conclusion: "models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows", and that held "even on simple tasks".

Reasoning suffers most. The NoLiMa benchmark, published at ICML 2025, tested models on questions whose answers did not share words with the text they had to find, which is how real questions usually work. At 32,000 tokens, which is a fraction of any modern window, "11 models drop below 50% of their strong short-length baselines. Even GPT-4o, one of the top-performing exceptions, experiences a reduction from an almost-perfect baseline of 99.3% to 69.7%". The authors trace the decline to how attention behaves in longer contexts when it cannot rely on literal matches.

Anthropic's own engineering guidance draws the practical conclusion. Their piece on effective context engineering describes an "attention budget" that "every new token introduced depletes", and defines good practice as "finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome". The window is not the memory. It is a budget, and you spend it every time you add something.

The four ways a long context goes wrong

Drew Breunig's essay How Long Contexts Fail gave the field its working vocabulary. His four failure modes map cleanly onto what people see in AI-built projects.

Context poisoning is "when a hallucination or other error makes it into the context, where it is repeatedly referenced". In a coding session this is the wrong assumption the tool made in hour one (a table name that does not exist, a library version it invented) that every later answer builds on. The error compounds because the model treats its own earlier output as fact.

Context distraction is "when the context overwhelms the training". The model leans on the growing transcript instead of on what it knows, so a well-known pattern gets replaced with whatever it happened to write earlier, including the mistake you are trying to remove.

Context confusion is "when superfluous context influences the response". Fifty pasted error logs, three abandoned approaches and an old requirements document are all still in the window, and the model weighs them as if they were current.

Context clash is "when parts of the context disagree". You said "never touch the auth provider" in message twelve and "make login work on mobile" in message ninety. Both are in the window. Which one wins is a coin toss, and the losing instruction is usually the older one.

What it looks like in a vibe-coded app

Put those together and you get the pattern we see most often in rescue work, the one we call the vibe cycle. You ask for a fix. The AI changes half a file, the bug goes away, and a feature that worked last week quietly stops working. You ask again. Something else breaks. The codebase has stopped converging, and the reason is not that the tool is bad. Its view of your project has drifted: the constraints are in the middle of a long session where attention is weakest, an early wrong assumption is being reused, and the last thing it wrote carries more weight than the first thing you asked.

The tell-tale signs are consistent. The assistant reintroduces code you deleted. It proposes the same fix in three slightly different forms. It confidently references a function or column that does not exist. It edits shared files (the router, the auth setup, the database client) while "fixing" something unrelated. If two or more of those are happening in one session, the session is done; more prompting will make it worse, not better. Our article on why vibe-coded apps break in production covers what tends to be broken by the time someone calls us.

What to do about it as someone using the tools

None of this means stop using AI tools. It means work with the budget instead of against it.

Start fresh per task. A new session for each feature or bug is the single most effective habit. The cost is re-explaining the task; the benefit is that the model's attention is on this task and nothing else. Long-running sessions are where drift lives.

Keep the brief outside the conversation. Every serious tool now has a place for standing instructions that are loaded at the start of each session rather than buried in chat history. Cursor's rules attach project conventions to every agent session. Lovable's project and workspace knowledge holds up to 10,000 characters of what the app does, its schema and its architecture decisions. Claude Code reads a project file the same way. Put the things that must never change there: the files that are off limits, the stack, the naming conventions, the rule that database changes go through migrations.

One change per prompt, and read the diff. Small, reviewable changes give drift nowhere to hide. If the tool touched a file you did not expect, that is the moment to stop.

Compact on purpose. Tools that support summarising the session, such as Claude Code's compaction, replace the long transcript with a structured summary. Do it after a milestone, when the work is in a good state, rather than when the tool is already confused.

Keep failures out of the window. Pasting the same 300-line stack trace four times is context poisoning by hand. Paste the relevant lines once, fix, then start a clean session.

Let tests and version control be the memory. A test that pins the behaviour you care about outlives every session. A commit after each working step means drift costs you a revert, not a rewrite. This is also why the first thing we do in a rescue is get the code into a repository the client owns.

What it means for a production AI system

For a business putting AI into a real process, the same physics applies with higher stakes, because nobody is watching each answer.

Retrieval instead of stuffing. The instinct is to put every policy, manual and record into the prompt because the window is big. The research above says that is the fastest way to degrade answers. A retrieval layer that selects the few passages relevant to this question, and puts them near the start or end of the prompt where attention is strongest, beats a giant context every time. We cover the practical shape of this in our AI implementation roadmap.

Explicit state outside the model. Anything the system must remember across turns, such as the customer's account, the steps completed, decisions taken, belongs in a database the code controls, not in the transcript. Assistants that "remember" by keeping the whole conversation are drifting by design.

Evaluate long conversations, not just first answers. Most evaluation sets test one question and one answer. Real support and operations conversations run to dozens of turns. If your test set does not include long, messy sessions, you will only discover context drift from customers.

Cap the transcript deliberately. Summarise or trim conversation history on a rule you chose, rather than letting it grow until the window forces the issue. The same applies to tool outputs and retrieved documents: budget them.

Watch for it over time. Model providers change models and defaults. A conversation length that was fine in March can misbehave in September. Cost and quality telemetry per conversation length is cheap to add and tells you before anyone else does.

Where QLTech fits

We build AI features with a context budget from the first design conversation: retrieval over the documents that matter, state kept in your systems, evaluation sets that include long conversations, and telemetry that shows when behaviour changes. And when an app built with Lovable, Cursor, Bolt or Replit has drifted past the point where prompting helps, our AI app rescue starts with a fixed-price audit and ends with code, tests and a written brief that make the next AI session start from solid ground. If either sounds like your situation, send us a short brief and we will reply with a written scope within three business days.