Diagnosing a Degrading Long Session
A teammate has been in the same Claude Code session for four hours. They started by asking Claude to add a caching layer to an API endpoint, then — while waiting — asked it an unrelated question about a Terraform module, then went back to the caching task. Now Claude keeps "fixing" the same cache-invalidation bug in slightly different ways each time, and each fix breaks something the previous fix had already handled.
- Using the context-window mental model, explain mechanistically why this session is behaving this way.
- What two concrete actions should the teammate take right now, and in what order?
- What should they have done differently at the two-hour mark to avoid this state entirely?
1. Why this is happening:
Every tool call's result — including the unrelated Terraform detour and every failed cache-invalidation attempt — stays in the context window and gets re-sent on every subsequent turn. Two compounding effects follow: the Terraform tangent is now attention-diluting noise for a caching task, and the window contains three or four failed approaches to the same bug. Claude's next guess is being generated with all of those false starts sitting in context as if they were relevant evidence, which is exactly how "fix breaks a previous fix" loops start — the model is threading a design driven by conflicting partial attempts rather than a clean read of the current state.
2. What to do right now, in order:
First, stop correcting inside this session — per the "two corrections"
rule, once you've corrected the same issue twice, a third correction
compounds the pollution rather than escaping it. Second, /clear and
write a single, precise prompt that incorporates what was actually
learned from the failed attempts (e.g., "the cache key must include the
tenant ID — earlier attempts missed this and caused cross-tenant
staleness; implement invalidation with that constraint and write a test
that reproduces the original bug before fixing it"). A clean session
with a better-informed prompt outperforms continuing to correct a
polluted one.
3. What should have happened at the two-hour mark:
The unrelated Terraform question should have gotten its own session (or
at minimum a /clear before returning to caching) — that's the
"kitchen sink session" anti-pattern. And the very first caching attempt
should have included a verification target: a test that reproduces the
invalidation bug, run after each change, so failures would have
surfaced as a concrete red test rather than as "something else broke" a
few fixes later. With a test in the loop, the second or third fix
attempt would have had a pass/fail signal instead of relying on the
teammate's manual observation to catch each regression.
Share this question