The short version
On October 6 my PC ran out of memory. It has 61.56 GiB of RAM and only 3.21 GiB was available. I had a lot open, but nothing close to that. So I typed the obvious question.
what is taking all my ram
The apps were not it. Claude was holding about 1.07 GiB and Codex about 0.97. Meanwhile 45.33 GiB was sitting in the Windows kernel, in something called the nonpaged pool, and nearly all of that belonged to one NTFS tag called NtFC. That tag was growing by 119.24 MiB every minute.
We closed Claude. Still growing. Stopped its Cowork service. Still growing. Restarted Codex. Still growing. Then a two second trace of file activity counted 78,064 file opens, and 99.09% of them came from one process: Codex's own network service, going at its browser cache through two different paths.
The assistant doing the investigation was running inside Codex. It followed the evidence to its own host and said so. It would have been easier to blame something else.
The two paths were the problem. Codex's public Roaming folder on C: was a junction pointing at a folder on E:, and Windows also gives a packaged app its own private view of that same folder. The two views did not agree. From inside the app you could open a cache file by name but you could not list the folder.
The fix was small on purpose. Copy the 3,277 files back to C:, check every one by hash, swap the junction for a normal folder, let the caches rebuild, and keep the original on E: just in case. After that the tag grew by 384 bytes in 135 seconds. Bytes. I restarted Windows and the 46.886 GiB it was holding dropped to about 27 KiB.
Then I asked for a page about it
I wanted to show this to people, so I asked Opus 5.5 to turn the write-up into a page with animated graphs. It made a long article with twelve sections of charts. Correct, detailed, and I didn't want to scroll it.
In the end all three models got the same brief: one presentation each, same story, same numbers, no looking at each other's work.
| Model | Title | Carried by | Scenes | Length |
|---|---|---|---|---|
| Opus 5.5 | RAM Leak in Motion | Circles drawn to scale | 12 | 93 s |
| Sonnet 5.5 | Missing RAM Column | One tall RAM column | 13 | 90.5 s |
| Fable 5.1 | Pool Tag Trail | One horizontal strip | 14 | 97 s |
They are at the top of this page. All three landed on the same idea without seeing each other: draw the memory to scale and keep one shape on screen the whole way through. Opus used circles, Sonnet a column, Fable a strip.
What I took from it
- Measure what is growing, not what is big. A 41 GiB number tells you where to look. A rate tells you whether the thing you just tried did anything.
- Keep the tests that failed. Closing Claude didn't fix it. That is worth knowing and it stays in the write-up.
- The first recorder died with the app it was recording. It was launched from Codex, so closing Codex killed it. The gap was reported as a gap and not as zero growth. The second one ran from Task Scheduler.
- Three models, one brief, the same instinct. Draw it to scale, keep one shape, one sentence per scene.
If you want all of it
The full writeup has every step: the measurements, the trace command, the eight checks that had to pass before the repair touched anything, the timeline, and the list of what the evidence does not show.
Read the full writeup Same site, the long version