[MODEL] Long-context degradation silently drops CLAUDE.md directives - no user-visible signal, and the mitigation is billed to the user
What happens
Partway through a long session, output quality changes character: confident assertions built on
guesses instead of verification, long speculative explanations in place of a two-minute check, and
the project's CLAUDE.md working-mode rules stop being followed. Nothing marks the transition. The
only reliable fix I have found is to type "read CLAUDE.md" and effectively restart the working
agreement, or to hand over to a fresh session.
Why this is severe rather than annoying
From the user's side, degraded output is indistinguishable from correct output. Both are fluent,
both are confident, and I only find out by acting on it.
The detection mechanism is my own independent knowledge. I catch it when an answer contradicts
something I can see or already know - a file I have open, a behaviour I just observed on the
device, a commit I made myself. Everywhere I do not already know the answer, which is most of the
reason I am using the tool, there is nothing for the answer to contradict and it is simply
accepted. So the cases I catch are the minority, and I have no way to estimate how many I did not.
Two sessions this week:
- A regression in offline/connectivity detection. Over roughly two hours the model produced a
sequence of confident, wrong causes, called an incomplete grep a "complete list", asserted which
build was on my phone without asking, and attributed its own earlier change to a commit of mine.
Each time I was the one who found the gap. I lost an evening to a two-minute diff.
- A second session began producing lengthy explanations built on assumptions the moment it got
long enough, and only recovered when I told it to re-read CLAUDE.md.
The symptom I can see is a trailing indicator - the harm is already done
The thing I eventually notice is a permission violation: Claude commits without my explicit
agreement. My CLAUDE.md is emphatic that edit, commit and push are three separate permissions, so
when that breaks it is unmistakable.
But that is late, not early. The rules do not fail in one moment - the quiet ones go first.
Verification discipline is gone well before the permission rule visibly breaks, so by the time I
see an unauthorised commit, the session has already produced several turns of confident,
unverified work, and some of it is in the branch. The visible violation is where I START looking;
the damage begins somewhere earlier that I then have to locate.
That also means "watch for the model misbehaving" is not a usable defence for me. I need the
degradation caught while it is still only affecting answers, not once it is affecting history.
And it is detectable on your side, not just mine. An agent taking an action its own project
directives forbid is a measurable event. If the harness noticed "this session just did something
CLAUDE.md prohibits", it would have a signal - a late one, but still earlier than mine - and could
re-assert the directives or warn, instead of leaving me to discover it several commits later.
Relationship to my earlier reports
- #80938 - compaction silently dropping custom working-mode directives. This is the same failure
class with a different trigger: the directives lose their weight from LENGTH ALONE, before any
compaction happens. Fixing compaction does not cover this.
- #80003 - preferring complete solutions over workarounds. That behaviour also decays as context
grows; the workaround instinct returns even with the rule written down.
This is documented, but the product does not act on it
platform.claude.com/docs/en/build-with-claude/context-windows states plainly: "more context isn't
automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as
context rot."
So the behaviour is known and expected. The product still presents 1M tokens as a flat capability,
and leaves detection and mitigation entirely to the user.
The workaround I was offered costs about 10% of my tokens
Asked how to prevent the drift, Claude's own proposal was a UserPromptSubmit hook that re-injects
my priorities on every turn. The arithmetic: a usable rules block is 400-500 tokens, re-sent every
turn, which over a 200-turn session is roughly 100k tokens spent restating instructions the product
already has in CLAUDE.md. Measured against what each turn actually contributes, that is on the
order of 10%.
I should not be paying to remind your product of the configuration file it read at startup. Either
the harness maintains the weighting of project directives itself, or the tokens spent compensating
for it should not count against my quota.
What this actually costs me
- Tokens spent on mitigation - handing over to a fresh session so it re-reads the project state,
re-explaining directives, and the per-turn hook above.
- Tokens spent on the wrong work itself, produced confidently and committed.
- My time undoing it. This is the one that matters. By the time I notice, the degraded behaviour
is several commits deep, so I am not correcting an answer - I am unpicking changes that were
made without my agreement and finding out what else moved with them. That time is unbillable. A
single incident this week cost more than the subscription does.
The comparison I would make: a managed cloud service that charges me extra for the security patches
and the data cleanups, and then requires me to apply them myself. I pay for the platform, I pay
again for the remediation in tokens, and I supply the labour. The advertised capacity is materially
smaller than 1M in practice, and the difference is settled in my evenings.
What I am asking for
- Re-assert project directives (CLAUDE.md) automatically as context grows, and use the signal you
already have: an action that violates the project's own stated rules. Claude Code already
injects reminders for other things; this is a product gap, not a model limitation.
- Give the user a signal when a session enters the degraded regime - and earlier than the point
where it is already writing to my repository.
- Do not charge the mitigation to the user's quota, or state the effective working capacity
honestly.
- Put the context-rot caveat next to the 1M figure where it is advertised, not three clicks into
developer documentation.
Environment
Claude Code, VS Code extension, Opus 5 (1M context). Long single-project sessions, CLAUDE.md with
explicit working-mode rules at the top.