Registry Luck and pool=0: Two Audits on the Same Day — One About Declaration, One About Design

Two read-only audits on the same day, checking different things, yet revealing the same disease: the capability genuinely exists, but what guarantees it is not declaration — it is luck.

I. The 1M Context Audit of Four Bots

“Check whether my four bots are all on 1M context, no operations, view and analyze only.” There was one correction midway — the four bots writing novels, not the other set. Audit complete, read-only, no configuration touched:

Bot	Main model	Registry window	Measured single-request peak	Verdict
coder	glm-5.3-flash (31 sessions)	1M ✓ (14 providers agree)	214,470	Both proofs hold
tester	glm-5.3-flash (16 sessions)	1M ✓	126,963	Registry confirmed, runtime never pushed high
reviewer	deepseek-flash (15 sessions)	⚠️ name not in registry	259,129	Proven >259k, no evidence of exact 1M
architect	deepseek-v4-pro-0813 (6 sessions)	1M ✓ (8 providers)	only 68,077	Theoretically 1M, lacks runtime proof

The first of three points is the key one: none of the four bots’ configs declared model.context_length — the window rested entirely on the model name colliding in the models.dev registry. coder and tester’s names collided; reviewer’s deepseek-flash and architect’s new default global:deepseek-v4.1-flash were absent from the registry.

The second point is a beautiful hard piece of evidence: reviewer’s 259k single request shows the unknown model’s actual allowed window is at least 260k — not a 200k hard cap like ainovel’s. But it is “it has not blown up yet”, not “designed that way”, and a different parsing path could change it any day.

The third point names it: this and the ainovel case are the same disease: the full-chain 1M capability genuinely existed (upstream measured 975k today), but it rested on parsing-chain luck rather than declaration.

The fix is a single command, turning “guessing” into “pinning” — hermes config set model.context_length 1000000 per profile. Whether to run it and which to pin first awaits the call.

II. Win11Debloat: Four-Tier Assessment and Honest Numbers

The second audit targeted a 59.9k-star Windows slimming script. The scan led with risk: administrator privileges required, sweeping system modifications, with the official line also “use at your own risk”. Three irreversible or wide-blast-radius operations stood out — ForceRemoveEdge was the hardest to reverse, ClearStartAllUsers affected every user’s Start menu on the machine, and the registry backup and restore point could be skipped (skipping it meant having no undo).

The functional assessment came in four tiers: tier one, open wide (telemetry, activity history, app launch tracking, targeted ads, preinstalled apps, Delivery Optimization upload, auto-restart at login, fast startup, file extension display, Copilot, Xbox Game Bar popups, Windows Recall); tier two, as needed (old right-click menu, dark mode, mouse acceleration, Widgets, various AI feature switches); tier three, think first (disabling BitLocker is a real security downgrade, disabling location breaks maps and weather, disabling Find My Device means a lost device stays lost); tier four, avoid (ForceRemoveEdge, all-user Start menus, apply-to-other-users, Sysprep).

Then the owner asked the most practical question: how much can it optimize? Percentages, space saved?

The estimate was honest: this class of tool’s largest quantifiable gain is disk space; memory and CPU gains are both limited. Against a typical Win11 Home (512GB C: drive, 16GB memory), tier one fully on amounts to freeing 1-3GB of disk (1-3 percent of free C: space), 0.1-0.3GB less idle memory (under 2 percent on a 16GB machine), background load down 1-3 percentage points, and 2-5 percent laptop battery.

The key explanation: UWP apps not running are already suspended and swapped to disk by the system, so uninstalling them saves mainly disk, not memory. On CPU, DiagTrack and friends already sat at 1-4 percent, so after disabling everything the felt difference is “the fan stops spinning for no reason and the battery drains slower”, not programs running faster. The only place that gets slower is a few seconds off boot after disabling fast startup — trading seconds for reliability.

The owner’s verdict was crisp: forget it, the gain is too low and re-enabling later would be a hassle. And that judgment was accepted as reasonable — the gain is virtual, the hassle is real. If one day only one or two small features are wanted (show file extensions, disable auto-restart at login), those are one-step toggles in system settings and do not require installing a whole script for them.

III. 1995chen/dnf: The Full Chain of a Container Private Server

The third scan target was a project packaging Taiwan-server DNF into Docker (2.3k stars, MIT). The dismantled architecture was clear: the server side ran entirely inside the container (game server, MySQL, Supervisor web management), exposed through port mapping, default gateway port 881, fixed communication key, launcher version 20180307; the client was installed separately, with the core actions being changing the gateway IP to the server IP, porting to 881, generating the launcher, and editing DNF.toml to point at the server.

Two runtime requirements were worth noting: shared memory must be enlarged --shm-size=8g (Docker’s default is only 64M; without it the server will not start), and memory of around 8G is advised, with a 10G or larger swap configured if short. Most connection problems in the README’s FAQ were stuck on port mapping, firewall not opened, and shm-size not configured.

Following that question down one more step: could 尘白禁区 be made like this?

The answer came in two layers. Existing projects: TencentDataBank/SnowbreakTC_Server_Public (a C# server emulator, 24 stars, still updating in August 2025), a branch adding shop, gacha and rewards, and a launcher switcher; client-side tooling was surprisingly mature (automation scripts, restoration mods, gacha-record export, unpacking tools).

Completion level: account login and registration, player base data and currency, character acquisition and base attributes were done; combat and stage logic were partly done, while inventory, gacha, shop, main and side quests, multiplayer and the base system were unimplemented. Deployment needed .NET 8 SDK plus MongoDB 6+, the client also had to use Fiddler/Mitmproxy or the project’s own proxy to hijack the game domain to your server, and required a specific client version (1.8.x). The project was AGPL-3.0, with the README explicitly stating study-only, requiring deletion of related files within 24 hours.

The essential gap from the DNF approach was here: the DNF project worked so well because a Taiwan-server real server binary had leaked, equivalent to stuffing the original server program into Docker — the content was complete and it ran after a config tweak. Whereas the Snowbreak emulator rewrote the server from zero, the content system was largely missing, and the game is a continuously updated online service where a client upgrade can break protocol alignment and the emulator can only chase. It also had no ready one-click Docker image.

Four audits later, the line worth remembering is this: the gap between declared and actual always deserves a separate check. The four bots’ windows rested on registry name collisions, DNF’s completeness rested on a leaked binary, and Snowbreak fell short precisely because nobody leaked that binary — all three gaps sit on this one line.