The context window is the whole memory

Your project is not inside the model

People assume that once they have worked with a tool for a week, it knows their app. It does not. A language model has no memory between requests. Everything it appears to know about your project was placed into a single block of text, right before it answered, and thrown away afterwards.

That block is the context window, and it holds a fixed number of tokens: roughly three-quarters of a word each, so 100,000 tokens is around 75,000 words. Current coding models sit somewhere between 128,000 and 1,000,000 tokens depending on which one you are paying for.

That sounds enormous until you weigh a codebase. A modest Next.js project with 120 files is easily 20,000 lines, which is 250,000 tokens or more, before the conversation, the error messages, the terminal output and the documentation. No tool sends all of it. They send fragments.

How the fragments get chosen

Editor agents assemble the context for each turn out of a few things: the file you have open, files you named with @, the results of searches the agent ran, the output of commands it executed, and a summary of the conversation so far.

That is why the same request behaves differently on Tuesday and Thursday. On Tuesday the relevant file happened to be open. On Thursday it was not, the agent searched for booking, found BookingCard.tsx and not bookingRules.ts, and wrote a second, conflicting implementation of a rule that already existed.

It is not being careless. It never saw the file.

Three symptoms, one cause

It forgets a decision you made an hour ago. Long conversations get compacted: the tool summarises earlier turns to make room. Details go first, and the detail that goes is often the constraint you cared most about.

It edits a file whose other half it never read. Agents frequently read the top 200 lines of a long file, edit confidently, and duplicate something defined at line 600.

Quality falls off in hour three. As the window fills with old errors, abandoned attempts and dead output, the useful material is a smaller fraction of what the model is reading. Researchers call the general effect context rot, and you will feel it as the model becoming vaguer and more willing to rewrite things you did not mention.

What to do about it

Start a new session on purpose. Not when things break, when a feature is finished. Cheap, and it clears the accumulated debris. Before you do, ask for a handover: summarise the current state of this feature, the files involved, and any decision I made that is not obvious from the code. Paste that into the new session.

Name your files. @lib/bookingRules.ts costs you four seconds and removes an entire class of failure. Vague requests make the agent guess where things live, and its guesses are drawn from other people’s projects.

Keep a rules file. Every tool now reads one automatically: CLAUDE.md, .cursorrules, AGENTS.md, .github/copilot-instructions.md. Anything in there is in the context every single turn without you paying attention. A later lesson in this block is entirely about what belongs in it.

Keep files short. A 900-line file will be read in pieces by every tool you use. Three 300-line files with clear names will not. This is a genuine reason to split code, and it is a new one: it did not matter much before agents.

The cost angle

Context is not free. You are billed for every token read, on most usage-based plans, every turn. An agent that reads 60,000 tokens of your codebase to change one line has charged you for 60,000 tokens. A long session where the window stays full is expensive in a way that a short focused one is not, and this is most of the difference between a 20-dollar month and a 200-dollar month.

Caching helps (providers charge much less for a prefix they have seen before) but it only applies while the beginning of your context stays identical, which is another argument for a stable rules file at the top and churn at the bottom.

The check that costs nothing

Before you accept a change to logic that matters, ask one question: which files did you read before writing this?

If the answer does not include the file where the rule actually lives, the change was written by something that had not seen the rule. That is not a reason to panic. It is a reason to say read lib/bookingRules.ts first, then try again, which usually produces a completely different and much better answer.