Three of 87 agent launches were admitted in one day. The spawn admission gate deferred on commit.pct > 80, and commit sat at 81-87% all day.
What the deferral looked like
The feed wakes never ran, and a partner’s update about a stack question before customer two went unread. The work log says wakes deferred for load now retry and give up quietly instead of reading as crashes. The same entry says “Memory pressure still blocks feed wakes.”
The ticket for this listed the top consumers on the machine:
30 claude processes, about 9.4GB
44 Cursor processes, about 7.8GB
96 chrome processes, about 5.8GB
107 node processes, about 4.7GB
It framed the decision as reaping idle sessions and MCP node helpers versus tuning the ceiling.
Three suspects
The brief handed to a Sonnet diagnosis agent split the cause three ways. Either the ceiling is wrong for this machine (a fixed number against its real RAM and pagefile), or the metric is wrong (commit charge includes the pagefile-backed reserve), or something is leaking commit. It asked for evidence on each, and for a named process and owner if a leaker existed.
It also set the requirements for the fix. The new rule should use measured, justified thresholds relative to installed RAM or the commit limit, not a guessed constant. It had to stay fail-safe, so it still defers when the machine is genuinely starved. Tests had to use recorded real readings.
The brief’s first step was to ground the check live. The load sampler gave the machine view: 10345 samples for the day, 9021 of them burst samples. Its latest reading was cpu 40.8%, RAM available 14.66 GB, commit 57.2%.
The denominator moves
The seed evidence for the ticket names the mechanism. The pagefile is system-managed, so the commit limit floats, between 47.9 and 60.8 GB over 09-28 to 09-30, and pct parked at 80-86%.
What we don’t have
Our notes stop at the diagnosis brief. They don’t record which of the three suspects the diagnosis agent confirmed, what the new thresholds are, or whether the proof launch (a prepaid Haiku claude call replying “OK”) was admitted. We won’t quote a fix we can’t show.
What the evidence does show is a gate with a constant 80 on one side and a commit limit ranging from 47.9 to 60.8 GB on the other.
AI Skills
Use this lesson with the AI assistant you already use
Only 3 of 87 agent launches were admitted in one day because the spawn gate deferred whenever commit.pct exceeded 80, and commit sat at 81-87% all day. The pagefile is system-managed, so the commit limit floated between 47.9 and 60.8 GB over three days.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Compare A Fixed Threshold Against The Floating Denominator It Divides By
SOURCE: dxdev.com/blog/floating-memory-ceiling-spawns
WHAT HAPPENED: The spawn admission gate deferred launches on a constant `commit.pct > 80` rule. Feed wakes never ran, and a partner's update went unread. The ticket listed heavy consumers such as 30 claude processes at about 9.4GB and 96 chrome processes at about 5.8GB, and framed the choice as reaping idle sessions versus tuning the ceiling. A diagnosis brief split the cause into three suspects: a wrong ceiling, a wrong metric, or a commit leak. The seed evidence pointed at the mechanism, which is that the system-managed pagefile makes the commit limit float, so the percentage parked at 80-86%. The latest load sample showed commit at 57.2%, with 14.66 GB of RAM available. The notes do not record which suspect was confirmed or what the new thresholds are.
THE RULE: Do not gate on a percentage whose denominator can move. Gate on measured values tied to installed RAM or a fixed limit, and keep a fail-safe deferral for when the machine is genuinely starved.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Every resource gate that uses a percentage names its denominator and states whether that denominator is fixed or can change at runtime, such as a system-managed pagefile.
2. Each admission threshold has a recorded justification from real readings, such as installed RAM or the observed commit limit range, rather than a guessed constant.
3. Deferral rates are logged per gate, for example admitted versus total launches per day, so a gate that blocks almost everything (3 of 87) triggers an alert.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
