Why ChatGPT Forgets Your Code in Long Coding Sessions

You are four hours into a debugging session. ChatGPT has been genuinely useful — it understood the architecture, followed the refactor, caught two mistakes. Then it suggests a function you deleted an hour ago, references a variable name you renamed at the start, and hands back a snippet that ignores the constraint you spent twenty minutes establishing.

Nothing broke. You hit the same wall every long coding session hits, and code hits it faster and harder than prose does.

This post covers why code specifically burns through a model's working memory, the failure signatures that tell you it is happening, and the workflow that keeps a long session coherent instead of degrading into re-explanation.

Code Is the Worst Case for a Context Window

Everything the model can see at any moment lives in its context window: your messages, its replies, and any files or snippets pasted along the way. It is finite. When a conversation grows past what fits, the earliest material stops being visible.

That is true of any long chat. What makes coding sessions distinctive is the shape of what fills the window.

Code is token-dense. Prose compresses well into tokens because natural language is predictable. Source code is not. Identifiers, punctuation, indentation, and symbols each cost more than their visual size suggests. A screen of code eats far more of the window than a screen of paragraphs.

You paste the same thing repeatedly. Over an hour you might paste one file five times as it evolves. Every version stays in the transcript. The window now holds five near-identical copies, four of which are wrong, and the model has no reliable way to know which is current beyond position.

Output is as expensive as input. When the model returns a full file, that file is now in the conversation too. A long session where the assistant writes code fills the window from both ends.

Error output is enormous and mostly noise. Stack traces, build logs, and test output are among the least compressible text there is. One pasted CI log can cost more window than the entire architectural discussion that preceded it.

Put together, a coding session reaches the limit far sooner than the message count suggests. Twenty messages of dense code and logs can exhaust what a hundred messages of discussion would not. The general mechanics of running out of window are covered in ChatGPT Loses Context Mid-Chat? Here's The Real Fix; this post is about what that looks like when the content is code.

The Failure Signatures

Context loss in a coding session does not announce itself. It shows up as specific, recognisable symptoms — worth knowing because each one is a signal to act rather than to argue with the model.

Stale identifiers. It uses the old name of something you renamed. The rename is in the transcript; it is no longer in the window.

Resurrected code. It suggests a function or approach you removed earlier, sometimes the exact one you rejected with reasons. The rejection scrolled out.

Dropped constraints. The rule you established at the start — this must stay synchronous, do not add dependencies, target this runtime version — quietly stops being honoured. Constraints are usually stated once, early, in a single sentence, which makes them the first thing to disappear and the most costly loss.

Narrowing output. Responses that used to include the full function come back as fragments, or with sections elided. The window is tight, so the model spends fewer tokens on output.

Shallower answers to the same question. You ask something you asked an hour ago and get a noticeably more generic reply. Same question, less context available to answer it.

Confident inconsistency. It contradicts something it told you earlier with no acknowledgement of the change. It cannot see the earlier statement, so from its point of view there is nothing to reconcile.

The tell that distinguishes this from a model being unhelpful: quality is degrading over the course of one session rather than being poor throughout. If the first hour was good and the fourth is bad, you are looking at context loss, not capability.

What Does Not Fix It

Several plausible-sounding responses do nothing, and it is worth knowing why so you stop spending time on them.

Telling it to remember. "Remember that we renamed this" adds a sentence to a window that is already full. It will hold for a while and then scroll out like everything else. You have bought a few turns.

Turning memory on. The memory feature stores extracted facts about you across conversations. It is not a bigger context window, and it does not retain the current state of a refactor. Different mechanism, different problem. Why Your AI Keeps Forgetting You covers the distinction in detail.

Getting annoyed and repeating yourself. Re-pasting the file and re-stating the constraint does work — briefly — while consuming more of the window and accelerating the next failure. This is the loop most people end up in.

Asking whether it still remembers. The answer is unreliable in both directions. A model will often claim to recall something it cannot see. Testing by asking produces no usable information.

Waiting for bigger windows. Larger windows raise the ceiling and change nothing structurally. A four-hour session with heavy code and logs will find whatever ceiling exists, and attention over very long contexts is not uniform anyway — something being technically inside the window does not guarantee it is being used well.

The Fix: Distil and Restart

The reliable move is to stop trying to preserve a degrading conversation and start a fresh one carrying a compressed version of what mattered.

Concretely, when you notice the signatures:

1. Ask for a handoff summary while it can still see enough to write one. Timing matters — do this at the first symptom, not after an hour of decay. Ask for the current state of the code, decisions made and why, constraints in force, approaches ruled out and their reasons, and what is next. Prose, not code.

2. Read it and correct it. This step gets skipped and it is the one that determines whether the restart works. The summary will have inaccuracies, especially about anything from early in the session. Fix them. You are writing the seed for the next few hours, and errors here compound.

3. Open a new chat and paste the corrected summary first. Before any question, before any code. Add the current version of the relevant files — the actual current version, once.

4. Continue. The new conversation starts with a clean window holding a dense, accurate description of where you are. In practice it performs better than the old one did an hour before you gave up on it, because the summary is more information-dense than the transcript it replaces.

The counter-intuitive part is that the restart is not a loss. A four-hour transcript is mostly redundant — superseded code versions, resolved errors, exploratory dead ends. Compressed to what remains true, it is maybe a page. The page is worth more to the model than the transcript, and it fits.

What the Handoff Summary Should Contain

The quality of the restart is entirely determined by this document. What belongs in it:

Current state. What is built, what works, what is in progress. Not history — state.

Decisions and their reasons. "We use polling rather than websockets because the deployment target has no persistent connection support." The reason is what stops the model re-proposing the rejected option in an hour.

Hard constraints. Runtime versions, dependency limits, style rules, anything that must not be violated. Enumerate them explicitly. This is the category that decays first and costs most.

Rejected approaches. What you tried and why it did not work. Without this, dead ends get re-suggested and re-explored.

Vocabulary. Names of the components and what they do, so the next conversation starts speaking your codebase's language.

Open questions. What is undecided, so the model does not assume a resolution.

What does not belong: full file contents (paste those separately as current versions), resolved errors, and the narrative of how you got here. The summary is a snapshot, not a log.

Preventing the Decay Instead of Reacting to It

A few habits keep sessions coherent for longer.

Keep exploration separate from implementation. Broad questions and architecture discussion generate a lot of text that stops being relevant once decided. Do that in one chat, then start the implementation chat with the conclusions only.

Do not paste more than you need. The whole file when the function would do, the full log when the relevant stack frames would do. Trimming input is the cheapest way to extend a session.

Re-state constraints periodically. Every time you paste a fresh version of a file, add one line with the constraints. Cheap, and it keeps the most fragile category alive.

Restart on a natural boundary. Finished a feature, fixed the bug, made the decision — that is the moment to summarise and start fresh, while the session is still healthy and the summary will be accurate.

Expect several chats per day of real work. People treat one chat per project as the default and fight to keep it alive. Several short, well-seeded conversations outperform one long degrading one.

Making the Summary Reusable Across Sessions

Handoff summaries have an obvious property: the one you write today is most of the one you need tomorrow. Rewriting it from scratch each session is wasted work, and it is exactly the work that makes people skip the step.

This is the workflow MindLock supports. The mechanics:

Save the sessions that produced something. In ChatGPT, Claude, Gemini, or Perplexity, press Ctrl+S (Cmd+S on Mac) at the end of a session where you decided something or solved something. The browser writes an HTML file — no extension, no API key. A Chrome extension with a one-click "Save to Memory" button also exists, installed via chrome://extensions with Load unpacked rather than from a store.

Import them into a store you control. MindLock parses saved HTML from those four platforms and keeps conversations locally in IndexedDB. On the free tier nothing leaves your device, which matters when transcripts contain proprietary code. The walkthrough is Importing Conversations.

Distil transcripts into memory documents. Distillation produces a profile memory plus topic memories — compact documents holding decisions, constraints, and current state instead of dialogue. That is the handoff summary, generated rather than hand-written. It runs locally on your GPU via WebLLM, which requires a WebGPU-compatible GPU and defaults to Llama 3.2 3B, or in the cloud via Gemini on the Pro tier with 100 distillations per month. See Free vs Pro.

Generate a context block to open the next session. Pull the relevant memories into a formatted block and paste it as the first message of a new chat. Details in Generating Context.

Two things this changes for coding specifically. The context block is per-project and cumulative, so a restart mid-week starts from your accumulated project state rather than only from this morning's chat. And because it is plain text, the same block works in Claude or Gemini — useful when you switch assistants mid-project and do not want to re-establish the architecture from zero.

Worth being clear about the limits: memory documents update when you re-run distillation, not automatically, and nothing is captured unless you save it. The habit is roughly a keystroke at the end of good sessions and a re-distil when the project state has genuinely moved.

Two Things That Help Before You Ever Hit the Limit

A pair of habits that are cheap to adopt and change how far a session gets.

Write the constraints down outside the chat. Not because the model needs them there, but because you will need to re-supply them, possibly several times, and reconstructing them from memory each time is where they get quietly dropped. A five-line block covering runtime version, dependency policy, style rules, and anything else non-negotiable takes a minute to write and can be pasted verbatim into every fresh chat for the rest of the project.

Decide up front what a session is for. Long sessions degrade partly because they accumulate several unrelated jobs — some architecture, then some debugging, then a refactor, then a question about tooling. Each job leaves residue in the window that the next one does not need. A session with one purpose stays coherent much longer than a session that drifted through four, and it produces a far better handoff summary because there is a single thread to summarise.

Neither habit requires any tooling. Both mostly consist of noticing that the window is a budget and spending it on purpose.

Bottom Line

Code fills a context window fast — dense tokens, repeated file versions, large error output, expensive generated code. Long coding sessions degrade because of arithmetic, not because the model stopped trying.

Learn the signatures: stale identifiers, resurrected code, dropped constraints, narrowing output. When they appear, get a handoff summary out while it can still write an accurate one, correct it, and restart in a fresh chat.

The restart is an upgrade, not a reset — a corrected page of state beats four hours of transcript. And if you keep the summaries as documents you own rather than rewriting them each time, the restart cost drops to pasting a block. Related reading: Why AI Forgets Your Project Context Between Sessions.