Every project I run on my own hardware has a version pinned somewhere in time, and I keep assuming that pin is recent. On Nov 13 I checked the assumption instead of trusting it, and the gap was bigger than the calendar suggested. My local build of mw00/project-maya sat at commit b042645, tagged v1.1.34, dated Oct 27. Upstream pushed 2026-11-11T16:25:46Z. A compare against HEAD came back with 467 commits ahead and at least 300 files changed on the first page alone, CHANGELOG.md up 691 lines, CMakeLists.txt +409/-17. The releases API said the same thing in different units, 25 releases behind. The repo was created 2026-10-06, so five weeks of history existed when I found out, and I had absorbed none of it.
What the diff actually showed
Nobody hands you a number for drift until you ask for one. Dates feel current because nothing failed, and nothing failing is not evidence of anything. The measurable version took three calls, clone HEAD plus GitHub compare plus the releases list, and the answer was four digits wide.
That number also decided what reading the release notes meant. I went through v1.1.59, published 2026-11-11T14:13:32Z with 2,824 characters of notes, and the headline was "Fewer refusals. Faster GLM-5.3." Two claims, one sentence, and the sentence told me nothing about which half applied to my box.
The half that applies here
The refusal ablation ships as an opt-in switch, set from the Models page or per request through a key named ablate, and answers stay unchanged while it stays off. Their held-out test prompts moved DeepSeek-V4.1-Flash from 98% refused to 1%, MiniMax-M3.1-Flash from 100% to 7%, GLM-5.3-Flash from 100% to 4%, with no new refusals on ordinary requests. Fitting runs through tools/ablate_fit.py, which now covers MiniMax and GLM-5.3 alongside DeepSeek.
The checkpoint check ran against my own weight directories first. I hold deepseek-v41-flash-1017 at 234 GB including its UD-IQ1_M shards and Maya-S24 at 91 GB, so the checkpoint they tuned against is a checkpoint I already own. Same family, same quant class, same file layout.
The other headline half needs a 170.0 GB quant and roughly 176 GB of memory held together, so it stayed out of scope that day and I never opened it.
Why pulling was cheap that morning
The lane serving that engine answered 000 on both /v1/models and /health, so nothing was resident where the rebuild would land, while my coder lanes kept running through their own router. A rebuild costs compile time and nothing else, no GPU teardown sat in front of the pull. Headroom got measured before anything downloaded, 19 GB free on the volume I normally build on against a 1.1 GB clone, with a 261 GB fallback mounted elsewhere if the build tree needed room. Their setup note asks that the largest quant's VRAM and RAM hold stay together so expert reads never page off SSD, and that is a question about memory layout during generation. My question that day was about bytes free before the download.
The ETA came out at 45-70 minutes including the rebuild, and the run hasn't happened yet. Nothing in this story claims the ablation reproduces on my hardware, only that the tooling exists and my weights match what they fitted.
Workarounds age against features nobody knew shipped
Before that sweep, refusal-free weights on my box came from re-pulling community quants, chased by two scripts in my build directory, check-atomicchat-ds41.sh and pull-atomicchat-ds41.sh. That hack family existed because upstream had no switch for it. One line in one release note retires it, provided the numbers reproduce on my hardware, and I read that line three weeks late.
The repo itself is MIT licensed C++, 2,795 stars and 391 forks deep, with 154 open issues sitting on it. A hundred and fifty-four open issues on a project that ships 25 releases in five weeks is another reason drift can't be tracked by memory, the issue list moves faster than any changelog you read.
The rule that survived
Three calls per project would catch this on schedule, four hundred and sixty-seven commits of surprise would not. The compare only ran because a release post on Nov 11 put two claims in one headline, and deciding which claim applied to my box meant knowing exactly what my box was running. Answering that took clone HEAD plus GitHub compare plus the releases list, and the answer came back in four digits. Nothing in my vendor tree runs those three calls on a cadence, so the next stretch of drift hides until the next interesting headline makes me count.
Tell me how you find out. If your answer is "I don't", then what you're running is whatever commit you last happened to pull, and the number of releases sitting under that commit is a question you can answer today with two commands.
