The complaint shows up the same way every time. You wrote the rules down. They are sitting right there in the file the tool is supposed to read. And somewhere around the middle of a long working session, the AI starts doing whatever it wants anyway.
The usual read is that the model is broken, or that it never really read the file. Neither is quite right, and the actual mechanism is more useful to know, because it tells you which fixes work and which ones just feel like they should.
Instructions do not fail. They fade.
Attention is a budget. Everything in the context window competes for it, and the competition gets worse as the window fills.
At ten thousand tokens, your rules file is a meaningful share of everything in front of the model. It is loud. At a hundred thousand tokens, the same file is a few hundred tokens sitting next to tens of thousands of tokens of code, output, error messages and conversation. It has not been deleted. It has been drowned out.
That is why this feels so inconsistent. A rule that holds perfectly for the first hour starts slipping in the third, and nothing about the rule changed. What changed is how much else is shouting.
The failure mode matters here. A switch fails loudly: it is on or it is off, and you notice. Fading fails quietly. The model does not announce that it is now working from a rough recollection of your standards instead of the text of them. It just starts being slightly wrong in ways that look like judgment calls.
Then compaction takes what is left
Long sessions eventually run out of room, and the tool summarizes what came before to make space. Your rules do not survive that as text. They survive as a paraphrase of themselves, written by the same model that is about to be judged against them.
Do it twice and you have a summary of a summary. Do it enough times and the thing being enforced is a memory of a memory of what you asked for.
For a sense of the scale this reaches in real use: there is an open issue on the claude-code repository, number 34556, where a user counted fifty-nine compactions in twenty-six days on a single project. Some sessions took five or more. That user ended up building their own memory system to cope. The issue was labeled stale with zero comments.
Fifty-nine lossy rewrites in under a month is not an edge case. That is a Tuesday on any project big enough to be interesting.
Three things that actually help
In the order I would try them.
Keep the rules file short enough to stay loud. This is the one people resist, because a rules file feels like the safe place to put everything you never want to explain again. It is not. Every line you add makes every other line quieter. Under a page is a good target. If a rule has not been violated in a month, it is probably taking up room that a rule you actually need could use.
Re-state the load-bearing rules right before the work they govern. Not at session start, where they will be a hundred thousand tokens in the past by the time they matter. Immediately before. If the thing you care about is that tests run before a commit, say it in the message where you ask for the commit. It feels redundant. It is redundant. That is the point: you are paying a small cost every time instead of a large cost occasionally.
Move anything that truly cannot be violated out of prose entirely. A rule in a file is a request. A rule in a hook, a linter, a pre-commit check or a tool that refuses is a wall. The difference is what happens when it is broken: prose degrades quietly, tooling produces an error. If you would be genuinely angry to find a rule was ignored, that rule does not belong in prose. Write it into something that can fail.
That third one is the whole game, and it is worth being honest about the trade. Tooling is more work to set up and less flexible once it exists. You will not do it for thirty rules. Do it for the two or three that would actually hurt.
What none of this fixes
All three of those are ways of managing a budget you do not control. They help. They do not change the underlying shape of the problem, which is that anything living inside the context window competes with everything else living inside the context window, and you lose that competition a little more with every hour of work.
That shape is why I have spent the last several months building NASC: session memory that lives outside the window instead of inside it. What fills up cannot dilute what is stored somewhere else. It is a different failure model, not a better version of the same one.
But you do not need any of that to get most of the way here. Shorten the file, repeat the two rules that matter when they matter, and put a wall around the ones you cannot afford to lose. That is most of the problem, and it costs nothing.