For three months I was running multi-agent Claude Code sessions with the pagefile on the slowest disk in the machine. I found out the way you find out most things like this: by finally running Get-PageFileSetting instead of just living with the accumulation.
The machine is a Windows desktop with one SSD and one HDD. The SSD is C:. The HDD is D:. Three years ago I put D: to work as the project root: all four HTO clones, the vault, ben-hq, and every auxiliary repo I touch on a regular day. I also pinned the Windows pagefile to D:. My reasoning at the time was disk-pressure management on C:. The reasoning was wrong, but not immediately costly enough to notice.
When I started running parallel agent sessions in January, that layout started to matter. Each week the machine felt a little less responsive, and I kept attributing it to the work: longer context windows, bigger diffs, more files in play. That story was plausible, which is why I kept accepting it.
The actual bottleneck
With three or four Claude Code instances doing concurrent file reads and writes across the project tree, the machine locked up. Not crashed, just locked, every disk read queued behind every other disk read. A 7200-RPM drive is rated around 120 MB/s sequential, but under the random-read pattern of parallel agents jumping through a 40k-file tree, the realistic throughput per agent felt like a few MB/s, not 30. Add a pagefile on the same spindle competing for head time, and you’ve designed a ceiling.
Get-PhysicalDisk came back: one SSD, one HDD, the HDD on D:. Get-PageFileSetting returned D:\pagefile.sys, 2048-4096 MB. Both swap pressure and code access were racing for the slowest disk in the machine.
The fix: G: and an env-var convention
I have a second SSD in this machine, G:, used mostly for games and scratch. I moved it into production use.
HQ-42 became the plan: make G:\Projects\ the canonical root, migrate all active repos from D:\Projects\, and introduce a BEN_PROJECTS environment variable so tools stop hardcoding paths that assume one machine layout. Any script, hook, or skill that currently references a hardcoded projects path reads $env:BEN_PROJECTS instead. That convention makes the layout portable across machines and sidesteps the next time someone installs a new drive and forgets to update 14 config files.
The pagefile went back to C:. The D: drive became media storage.
The migration itself was a list-and-move operation: git worktree list per clone to catch anything attached, robocopy per repo, verify the new path is clean, update .gitconfig safe.directory entries for the cross-user runners, update session manifests. The BEN_PROJECTS convention required one pass through hook configs in ~/.claude/settings.json and two spots in pyproject.toml that had hardcoded paths.
The unglamorous part of AI-native work
I expected the bottleneck to be something interesting: context window saturation, rate limits, a provider that queues aggressively. A spinner disk is not interesting. It is a $60 SSD swap and a pagefile setting.
What bothers me in retrospect is not that the answer was physical, but that the wrong explanation was convincing for so long. “Heavier workloads are slower” is self-evidently true, which makes it a good hiding place for a different cause. The pagefile setting I applied three years ago, for entirely sensible reasons, became a throughput cap the moment the access pattern changed. The D:\pagefile.sys entry is gone. The sessions run clean. I had spent three months blaming the models.