Long sessions fail in a recognisable way. The model starts rewriting work it finished an hour ago and describing files that are not in the project. The whole conversation is still on screen, which is exactly what makes it confusing, and nothing reports a problem because by the tool's own accounting nothing is wrong.

The idea

Everything the model appears to know about your project is text placed in front of it for this one answer. That space is the : your messages, its replies, the files it opened, the output of commands it ran, product instructions you never see, and the your project carries. It is a workbench, not a memory. It gets more crowded with every turn, and a crowded bench is harder to work on before it is full.

code
  ONE MESSAGE = this entire bench, read again from scratch

  +----------------------------------------------+
  | product instructions + tool list   (hidden)  |  constant
  +----------------------------------------------+
  | your CLAUDE.md / .cursor/rules/    (rarely   |  constant
  |                                     seen)    |
  +----------------------------------------------+
  | every message so far, both sides             |  grows every turn
  +----------------------------------------------+
  |                                              |
  | files it opened, command output, test logs   |  grows fastest,
  |                                              |  mostly already spent
  |                                              |
  +----------------------------------------------+
  | the message you just typed                   |  small
  +----------------------------------------------+
  | room left to think and to answer             |  whatever is left
  +----------------------------------------------+

How it works

Give the model five relevant facts and it mainly has to reason. Bury the same five in a hundred thousand tokens of transcript and log, and it has to find them first. The finding can fail while the answer is technically present, which is how a session gets worse while being better informed. Anthropic's context engineering post describes this space as a finite attention budget with diminishing returns rather than a shelf that works perfectly until it is full (checked 13 August 2026).

Published evaluations agree without promising a curve.

  • The 2024 TACL paper Lost in the Middle found tested models did better when the relevant passage sat near the start or the end of a long input than when it sat in the middle.
  • The 2025 NoLiMa benchmark found accuracy falling sharply as inputs grew, when the question did not reuse the source's wording.
  • A 2025 Chroma report across eighteen models found reliability declining with length, and near-miss mattering as much as length.

Those are particular models on particular tasks. There is no percentage at which quality falls over, and anyone quoting one is guessing.

What you see is also not what the model gets. To stay under the limit, products drop older turns or summarize them into something shorter (), and the conversation still reads as continuous. In Claude Code this happens on its own as you approach the limit. You can also type /compact to trigger it early (it accepts an instruction about what to keep) or /clear to throw the conversation away instead of summarizing it. A word typed with a leading slash at the start of a message is usually a command to the tool itself rather than something the model sees.

What to do

  1. Give one session one finishable job, then start a new one. The reset is the feature. Nothing carries over except what is written down, so before you close a session, write the decisions you made and the next step into a file in the project. A single NOTES.md at the top is enough to start. No tool loads that one for you, so point the new session at it. It cannot read the conversation you just ended.
  2. Control what lands on the bench: the failing test rather than the whole run, one directory rather than the repository, the conclusion rather than the log that produced it.
  3. Restate a load-bearing constraint next to the request it constrains, rather than trusting a sentence you typed an hour ago.

Where it breaks

A crowded window is a mechanism and a bad answer is an outcome, and the link between them is real but loose. Plenty of wrong answers owe nothing to context: stale training knowledge, an ambiguous request, a check nobody ran. Diagnosing every one as "the window is full" costs you the actual cause.

Too little context is just as expensive. The model guesses, and a guess costs more than the tokens you saved. Aim for the smallest complete set of current material the job needs.