I wrote that file so my agent would stop asking me the same questions. Then I kept writing it, for 23 days, until it was 73,769 bytes. Last night I checked it against the code it describes, line by line. It was wrong in six places. Every one of them would have changed what a session did.
It claimed 41 commands and 65 MCP tools. The binary has 67 commands and 60 tools. There is a whole section under that sentence arguing that the command surface is under control, reasoning from both numbers. The commands went up by 19 and the tools went down by 8, so a reader cannot even mentally correct for the drift, because the drift has no direction.
Line 1009 explained how I keep my two clients at parity. Line 1032 said I deleted the second client on the 31st of July. Both lines load into every session. Neither one wins. A markdown file has no way to say that one statement retired another, so the session picks whichever it happened to attend to.
It named a test directory that no longer exists, described as a suite with a fixture per schema version. It went with the deleted client. A session told to add a fixture there goes looking, finds nothing and then either invents the directory or quietly stops trusting the file.
It described a tools folder as holding three parity harnesses. Deleted, weeks ago. It named a README for the installed brain that was never written.
And one bullet contradicted itself inside its own paragraph. It said those harnesses "are kept for reading, not for running", then four lines later said they had been deleted. Both sentences, same bullet, same file, loading together into every session since.
None of this was carelessness. Nothing in a markdown file expires or retires anything, so they are all still there, at full confidence, being true about a tree that moved underneath them.
The model goes and looks. A stale line is expensive, because the model acts on it, in your voice, with your authority behind it and the output looks exactly like the output it produces when it is right.
Four of my six would have sent a session down a wrong path without a flicker of doubt. Nobody in that loop is inventing anything. The model is repeating what its context told it.
Roughly 17,000 tokens, sitting in the window on every single turn, before I type anything. That is occupancy rather than expense: caching changes what those tokens cost and does not move them out of the window and the window is what decides how far a session gets before compaction takes the thread of what it was doing.
Here is the part that should decide it for you. It opens them every time. It has to and it is right to, because nothing in that document says when a line was written or whether it is still true and there is no way to tell my six rotten claims from the hundreds of sound ones by reading it. So either you trust all 73KB, which I have just shown is wrong six times, or you verify what matters, which means reading the code.
Notice how I found the six. Not by reading the file. By reading the code and comparing. A document that exists to save you from reading the code can only be audited by reading the code.
8,281 bytes on the 27th of July. 73,769 on the 18th of August. 43 commits touched that file. Two of them made it smaller, by 191 bytes between them.
One of those two is the commit where I deleted an entire retired client from the project. Thousands of lines gone in one change and it took 190 bytes out of the file that describes the project. By the end of that same day the file had grown 15KB net.
Nothing in a markdown file decays and nothing supersedes anything, so the only edit available to anybody is an append. Ask yourself when you last deleted a paragraph from yours.
48 of this project's 192 memories carry one. Recall renders a verdict per fact: four currently read tree unchanged since stored and those four are claims a session can act on without opening a file. The other 44 read N commits since, re-check against source. So a brain does not abolish the re-read. It routes it, one fact at a time.
--supersedes hands the identity to the new fact and recall of the old wording answers with the new one. My parity claim and my deletion notice could not both have been live. One would be the answer and the other would be history.
Infrastructure never decays. "The box is rebooting" halves every four days and is gone inside a fortnight with nobody remembering to delete it. Nothing is deleted by decay; it stops outranking things that still matter.
It ranks, cuts from the least important end, names the sections it cut and prints the command to see the rest. There is a number stopping it, which is the whole difference between a brief and a file.
A decision is falsified by the person who made it, never by a commit. Flagging one as stale invites re-arguing a settled call, so the freshness line stays narrow on purpose: one that fires on every memory is one everybody learns to skip.
A script measures size and size is the weakest of these arguments.
Open your CLAUDE.md, or your AGENTS.md, or your .cursorrules. Pick five specific, checkable claims: a file path, a count, a command name, a directory, a version number. Verify each one against the tree.
Then decide whether you want the next five years of that file loading into every session you ever run.
$ curl -fsSL https://brain.fightclub.pro/install.sh | sh # then, in the project you want it to remember $ ns-brain init
Every number on this page is from ns-brain's own repository and every one of the six defects is in its git history along with the commit that fixed it. The audit was run on 2026-08-19.