ChatGPT Compacting Context: What It Means for Your Chat

You have been in the same ChatGPT conversation for two hours. Somewhere in the last twenty messages it stopped knowing things it definitely knew earlier — the variable names you agreed on, the constraint you spelled out at the start, the tone you asked it to hold. Nothing announced the change. You went looking for an explanation and found people talking about compacting, compaction, or the context being compressed, and now you want to know whether that is what happened to you and whether you can stop it.

This post separates three things that get tangled together: what compaction actually is as a technique, what a long ChatGPT conversation demonstrably does to your earlier messages, and what is simply not observable from where you are sitting. The distinction matters because the fixes are different, and most of the advice floating around fixes the wrong one.

One thing up front, because the honest answer is more useful than a confident one. OpenAI does not document how ChatGPT handles a conversation that outgrows its context window, and the interface gives you no indicator when it happens. Anything written as though it does is inferred from behaviour. What follows is the behaviour you can verify yourself and the reasoning that holds regardless of which implementation is running this month.

What Compaction Means

Every model has a fixed budget for how much text it can consider at once. That budget covers your whole conversation: the system instructions, every message you sent, every reply it produced, and anything retrieved on your behalf. It is not a limit on how long you can keep typing. It is a limit on how much of the accumulated history travels with each new request.

When a conversation grows past that budget, something has to give, and there are only two families of answer.

Truncation drops content. The oldest turns fall off the front and are simply not sent. The model sees a conversation that appears to begin partway through. Cheap, predictable, and completely lossy at the boundary.

Compaction replaces content. Older turns are summarised into a much shorter block of text, and that summary is sent in place of the originals. More expensive, because producing the summary costs a model call, and lossy in a different way: nothing vanishes at a hard boundary, but everything before the boundary is now a paraphrase of itself.

The word has become common because agentic coding tools surface it explicitly. They run long sessions, they blow through the window routinely, and they tell you when they have compressed the history. That visibility is why the term entered general vocabulary and why people now search for it alongside ChatGPT, where nothing comparable is shown to you.

Why You Cannot Simply Look It Up

The reason this is frustrating rather than merely technical: the consumer interface exposes none of it.

You are not shown how much of the window you have consumed. You are not told when the history was trimmed or rewritten. You do not see the summary, so you cannot check whether it kept the detail you cared about. There is no marker in the transcript separating what the model can still see from what it is reconstructing. The conversation scrolls back forever in your browser, which makes it look as though all of it is still in play, and that impression is the single biggest source of confusion here.

So the model does not "forget" in any sense that involves it noticing. From its side, the conversation it was handed is the whole conversation. It answers confidently about a history it is no longer fully holding, which is exactly why the failure is so easy to miss — you do not get an error, you get a subtly wrong answer delivered in the same tone as the right ones.

Reading the Failure Signature

You cannot see the mechanism, but the two families leave different fingerprints. This is worth five minutes because it tells you whether starting a new chat will help.

A truncation signature looks like a cliff. Details from early in the conversation are gone completely — not vague, not approximated, absent. Ask about something from your third message and the model has no idea what you mean, while something from twenty messages ago comes back perfectly. There is a point in the transcript before which nothing survives and after which everything does.

A compaction signature looks like a fog. The model still knows roughly what the conversation was about from the beginning. It remembers you are building a scheduling tool, that there was a constraint about time zones, that you preferred one approach over another. What it has lost is the specifics: the exact function name, the precise wording of the rule, the number you gave it. Ask for the detail and you get a plausible reconstruction rather than a blank. This is the more dangerous of the two, because a plausible reconstruction reads like a memory.

A third signature that is neither. The model has everything but is weighting it badly — it recalls your early instruction if you point at it directly, but it has stopped applying it spontaneously. That is not a window problem at all, it is attention drifting toward the most recent turns, and no amount of context management fixes it. Re-stating the instruction does.

Check: pick three specific facts from the first quarter of your conversation — a name, a number, a constraint phrased distinctively. Ask about each one directly, in the same chat. Blank on all three is a cliff. Approximately-right-but-wrong on all three is fog. Correct on all three means your problem is elsewhere, and ChatGPT Context Loss Mid-Conversation walks through the other causes.

What Compaction Costs You, Specifically

If your signature is fog, it is worth understanding what kind of information dies first, because it is not random.

Summarisation preserves structure and discards particulars. That is what summarisation is for. A summary of a two-hour design conversation will faithfully report that you discussed authentication, chose sessions over tokens, and rejected a third-party provider. It will very often not preserve the exact reason you rejected the provider, the edge case that made sessions win, or the specific wording of the constraint you set.

The pattern generalises. Verbatim text degrades worst. Code snippets, exact error strings, precise phrasings, anything where the value is in the characters rather than the gist. Negative constraints degrade badly. "Do not use this library" is a single clause that is easy to drop from a summary and expensive to lose, and its absence is invisible until the model cheerfully uses the library. Numbers degrade quietly. A figure that appears once in a long conversation is exactly the kind of detail a summary compresses away, and the model will happily supply a different one later without flagging that it is guessing.

Recency survives. Whatever you said most recently is sent verbatim regardless, which is why the last few turns always feel sharp and why the problem seems to live in the distant past. That asymmetry is the whole shape of the experience.

This is also why the failure hits coding sessions hardest. A long technical conversation is mostly verbatim content and negative constraints, which is the exact material that compression destroys. The specific version of that problem is worked through in Why ChatGPT Forgets Your Code in Long Sessions.

What You Can and Cannot Control

Being clear about the boundary saves a lot of wasted effort.

You cannot choose truncation over compaction, see the summary, edit it, set a threshold, or ask for the original turns back. None of that is exposed, and no prompt makes it appear. Instructions like "remember everything in this conversation" or "do not summarise our history" address a process the model is not in charge of; the history is assembled before the model is called. Asking it to try harder changes nothing.

You also cannot infer your position in the window from how long the chat looks. Message count is a poor proxy: twenty messages containing pasted files can consume more budget than two hundred short exchanges. If you have pasted large documents or long code blocks, you are much closer to the edge than the scrollbar suggests.

You can control what goes in, how much of it, and when you start over. That is the entire lever, and it is a bigger one than it sounds.

Working With It Instead of Against It

None of these are clever. They work because they attack the input side, which is the side you own.

Restate before it matters, not after. The moment you notice a constraint being dropped is the moment it is already gone from the history. A short re-statement of the active constraints every so often puts them back into recent context where they are sent verbatim. Six lines is enough: what we are building, what is decided, what is off-limits.

Keep verbatim material out of the conversation when you can. Paste the twenty lines that matter rather than the four-hundred-line file. Every token of context you spend on material the model does not need is a token unavailable for the material it does.

Treat a conversation as having a useful lifespan. Long chats do not degrade gracefully past a point, and pushing on is usually worse than restarting with a clean brief. The cost of restarting is one paste; the cost of continuing is answers that are confidently reconstructed from a summary.

Carry the state forward deliberately. Before you abandon a long chat, ask it to produce a handover: decisions made, constraints active, open questions, current state. Read it, correct it — this is the step people skip and it is the one that matters, because an uncorrected summary carries the same fog into the fresh chat — then open a new conversation and paste it as the first message. You have done manual compaction, except you got to see the summary and fix it.

Do not rely on the memory feature to cover this. It is a different mechanism aimed at a different problem: durable facts about you across conversations, not the working state of this one. It does not extend your context window and it will not restore a detail that fell out of a long chat. The two get conflated constantly, and the distinction is set out in How to Fix ChatGPT Memory Problems.

When to Start a New Chat

A rough rule that holds up: start over when re-establishing context costs less than the errors you are absorbing.

Concretely, when you have corrected the same drift twice, when the model contradicts something you can see in the scrollback, when you are spending more messages repairing its understanding than advancing the work, or when you are about to move to a genuinely new phase of the task. That last one is the cheapest moment to restart, because the handover writes itself: the phase you just finished is the summary.

The instinct to keep one long thread going is usually about not wanting to re-explain. That instinct is correct about the cost and wrong about the alternative, because a written handover is re-explaining once, permanently, in a form you can reuse. What that looks like as a recovery procedure is in What to Do When ChatGPT Forgets Everything.

The Structural Version of the Problem

Step back and the recurring cost is not compaction. It is that the state of your work lives inside a conversation you do not control, in a container whose size you cannot see, managed by a process that does not report what it did.

Every long session regenerates the same context from scratch, degrades it the same way, and loses it the same way. You pay the re-explaining tax at the start of each new chat and the reconstruction tax at the end of each old one. The compaction question is really a symptom of that: you are asking how your working memory is being managed because it is being managed somewhere you cannot look.

The alternative is not a better prompt. It is keeping the context that matters outside the conversation, in something you can read, edit and re-supply on purpose.

Holding Context Outside the Chat

That is the problem MindLock is built around. You save the conversations worth keeping — Ctrl or Cmd plus S in ChatGPT, Claude, Gemini or Perplexity, or the one-click button from the sideloaded Chrome extension — and upload the saved page. Distillation turns those conversations into memory documents: a profile memory plus topic memories, all of them plain text you can open and read in full, with nothing hidden in a summary you never see.

When you start a fresh chat, you select the relevant memories and generate a context block to paste as your first message. That is manual compaction with the summary visible and editable, which is precisely what the built-in version does not give you. Walkthrough in Generating Context.

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

The Short Version

Compaction is the technique of replacing old conversation turns with a summary so a long chat still fits the model's fixed budget. The alternative is truncation, which drops them instead. ChatGPT does not tell you which it does or when, and no prompt reveals it.

You can still diagnose it from the outside. Blank recall of early specifics is a cliff; approximately-right-but-wrong recall is fog, and fog is the compaction signature. Verbatim text, negative constraints and one-off numbers are what compression destroys first, which is why coding sessions suffer most.

You control the input, not the mechanism. Restate active constraints periodically, keep bulky material out unless it is needed, and when a chat has clearly degraded, ask for a handover, correct it, and start clean. Do not expect the memory feature to help — it is a different thing solving a different problem, and it does not make your context window any bigger.