Context rot

What you'll walk away with: why a thread you have been in for an hour starts missing what you told it at the start, and the three-line restart that answers it.

You need: both tabs, about 20 minutes, and one long document you could forward outside the firm — a policy, a report, an exported email thread; the longer the better. Nothing to install.

First, thirty seconds of retrieval — from memory, not from the page: what is a chat? Say it, then check it against lesson 05: every send re-packages the whole transcript and hands it over as one block, and between sends nothing is running. Now turn that around: if every send carries the whole pile, the pile is the one thing that changes while you work — and this lesson is what happens to the context window as it grows, and what to do about it.

Everything in the window competes

The window is finite, and everything in it competes — you counted it in lesson 03. Here is what the lessons so far have not said: even inside the budget, the pile is not a filing cabinet. Where a fact sits, and what surrounds it, change how reliably the continuation uses it.

Where a fact sits in a paste, and what sits beside it, is lesson 08's shape; this lesson's is the pile itself — how much text is in the window, and how old your lines are by the time you need them. Practitioners call it context rot: the longer and messier a window gets, the less reliably any single thing in it gets used. The thread that "got dumb" after an hour did not get tired. Its window filled with dead weight, and your newest sentence became one voice in a very large room.

What the app does when the window fills

The app builds the window, and it edits it. When a thread outgrows what the app hands over in one block, the app trims or condenses the older middle to make room, and nothing in the chat announces it — not a notice, not the reply's confidence. So make the edit visible yourself: re-ask an early question, word for word, and check the answer against your own source. That is how you see it from your chair.

The second thing to watch costs a glance: a standing instruction you gave at the top stops being honored, and the last line of a reply is the cheapest place to see it.

Rules also get dropped in a short window, for a different reason — that is lesson 09, where the rules multiply and the window stays short; here the rule count stays at one on purpose, because this lesson's variable is how much text sits between the plant and the ask.

"It forgot what I told it" is lesson 05's reframe — the window ending, not memory failing. This is a shape you can watch and answer.

The restart

When a long thread has gone dumb, stop pushing it. Start a fresh window and carry a clean summary forward. You watched in lesson 05 why the machine will not miss the dead weight: nothing runs between sends, and the window you build next is the only memory there is.

Lesson 05 gave you the three lines; a long thread adds three habits to them. Carry the conclusions, not the transcript. Carry the one or two facts the next answer is load-bearing on, in your own words, not the thread's. And paste the source passage in fresh, not the copy that rode through the long thread. A restart is not a reset you pay for; it is the cheapest way to make the lines that matter the largest thing in the room.

Do this in ChatGPT and Claude

A fresh chat in the first tab, your long document ready — 2,000 words or more. At the top you will plant a fact and one rule.

Predict, before send 1, and write it down: which of the two will still be honored at the end — the fact, the rule, both, or neither?

Send 1 — the plant.

Here is a document I am working from. Two things to hold for the rest of this conversation: my deadline is the 14th, and every answer you give me must end with a line that starts "Open question:". Confirm both, then summarize the document in three sentences.

[paste the whole document here]

Sends 2–5 — the load. Four asks for length; the point is not the answers, it is the volume they add.

Expand that into a section-by-section walkthrough.

Rewrite the walkthrough for someone who has never seen the document.

List every date, name, and number in the document, with a line of context for each.

Now argue the other side of the document's main claim, at length.

Observe as you go: you do not have to read these. Read the last line of each reply and note the first send where "Open question:" stops appearing — a check that costs a glance.

Send 6 — the deliverable you will compare. Keep this email.

Draft a 200-word email to my team saying what we should do next.

Send 7 — the re-ask.

What is my deadline, and what was the rule I gave you at the start about how every answer must end?

Observe: read the answer against what you typed in send 1, not against how sure it sounds. Three outcomes, all three the mechanism: both come back right; one comes back wrong, vague, or hedged; or it says it no longer has them — the honest branch of the same draw, absence given a word, which lesson 10 makes a habit. If both came back intact, that is a real measurement on your own material — at this length, in this app, two planted lines still won the draw. Push it — paste the document in again, run two more expansions, then send the re-ask again — or go straight to the restart and read the comparison instead.

Explain: nothing got tired and nothing ran between your sends — every long reply rides in again, so your two lines are two lines in a very large room.

The restart. A new chat in the same tab, one send:

I am working from a document. My deadline is the 14th. Every answer must end with a line that starts "Open question:". Where things stand: [one line on what the task is, one on what has been decided, one on what is still open]. The part of the document that matters is below.

[paste only the section that email needs]

Draft a 200-word email to my team saying what we should do next.

Predict whether the rule holds this time. Observe: put the new email beside send 6's and read both cold: which one is about your document? Check the new one's last line. Explain: same odds, same request; what changed is the ratio — the lines that matter are no longer outnumbered, and nothing about the machine had to improve.

Then the same sequence in the other tab. If the drift shows by the third load send, stop there and go to the re-ask — you have what you came for. If one tab drifts and the other holds, that is one product on one day at this length, not a ranking — the restart is the move in both.

---

Check your understanding: an hour into a thread, it gets your deadline wrong. The odds behind it are frozen — the same on your first send as on this one. So what changed, and what are your two moves?

Check yourself first — then open one good answer+−

The pile changed: your first send and every long reply since ride in again on every send, so your deadline is one line in a very large room — and if the thread outgrew what the app hands over in one block, the app trimmed or condensed the older middle, where it sat. Nothing got tired.

Your answer should have hit the window as the thing that changed, not the machine — the re-ask as how you see it from your chair, and a restart as cheaper than a third reminder.

Use this restart before the third reminder. When you catch yourself re-telling a thread something it already had, the cheap move is not another reminder — it is three lines in a window with nothing else of yours in it. Next: The needle in the haystack — the same fact, used differently depending on where it sits.