Loading today’s stories
Build1 distinct publisher3 min readUpdated
A developer lost a day of automated output to a daemon holding 46GB of compressed memory behind a 264MB resident set. Sorting top by RSS will never surface it.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A developer running an automated posting stack on macOS lost a full day of output on August 9, 2026, and `top -o mem` reported nothing wrong for the duration [1][2]. The process responsible, `dasd`, was carrying 46GB of compressed memory behind a 264MB resident set, roughly 178 times its RSS, which is exactly why it never entered the top 20 of an RSS-descending list [4][1].
The failure presented as an application bug. The Playwright instance managed by Claude Code looked alive, but `launchPersistentContext` had been timing out at 180 seconds, repeatedly [5]. The first diagnostic, `top -o mem`, showed nothing above a few GB of RSS and no sign of `dasd` at all [2]. The signal was on a different screen: swap at 37GB, described by the author as nearly double physical RAM [3]. At that point every new allocation is disk I/O, so the moment Playwright asked for a browser context the OS started paging to secure the memory, and 180 seconds was not enough [6].
The structural part matters more than the incident. macOS zlib-compresses pages that are not actively used and keeps only the mapping, and that compressed region consumes physical RAM but is not counted in RSS [7]. It is visible, but only if you ask for it: `top -l 1 -n 20 -o mem -stats pid,command,mem,cmprs` put `dasd` in the output at 264M MEM and 46G CMPRS, PID 1842 [8]. According to the author, `dasd` is the Duet Activity Scheduler, the background task arbitration daemon, and it had accumulated that 46GB over 21 hours of uptime [9]. The account attributes the 37GB of swap directly to that compressed pool, though it does not say whether the CMPRS column reports the footprint before compression or the bytes resident after it [17].
Threshold design follows from the blind spot. An RSS trigger set at any sane level never fires against 264MB, so the author keys the alert on the `mem` column, which sums CMPRS and the RSS-equivalent figure, with an awk helper normalising T and G suffixes into MB [12][13]. That is the transferable part: if your alerting rule reads RSS, its coverage of a compressed leak is zero regardless of how low you set the number.
`dasd` was not alone. A second leaker, a Node.js process the author calls `iii` (agentmemory), managing agent session memory, was growing at roughly 4GB per hour, which at that rate reaches 46GB in about 11 and a half hours [11][3]. Manual remediation was five minutes of work, and the author noted the symptom recurring after 21 hours of uptime, which converts the fix into a daily chore of reading `top` and running `sudo killall dasd` [10]. The replacement was a script on a 10-minute interval that restarts on threshold crossing and posts to Discord [14]. The log line the next morning read reclaimed at 02:32, with swap back at 4.1GB, a drop of about 89 percent from the 37GB peak [15][2]. The detection window went from roughly a day to ten minutes, or 144 checks daily [4].
Worth verifying before you copy the fix: run the `-stats` variant on your own long-uptime machines and see whether CMPRS is already large, because the 21-hour pattern is one person's observation on one box [10]. The revenue framing around this account, 1.2M yen per month, is self-reported and unaudited [16]. The monitoring defect is the part that generalises.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
With swap that inflated, any new memory request is essentially disk I/O; when Playwright tried to create a browser context the OS began reading and writing swap to secure pages, which blew past the 180 second limit and failed.
On August 9, 2026, every lane of the author's SNS auto-posting produced zero posts for a full day.
Running top -o mem showed nothing suspicious in the top 20 processes; the largest RSS was a few GB and dasd did not appear in the list at all.
Swap usage shown on top's other screen was 37GB, which the author describes as nearly double physical RAM.
dasd was holding 46GB of compressed memory behind a 264MB RSS and never appeared anywhere in the top 20.
The Playwright instance managed by Claude Code appeared to be running, but launchPersistentContext had been timing out at 180 seconds over and over.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single self-reported incident with concrete artifacts
The cluster is one first-person dev.to post. It carries unusually concrete artifacts for an anecdote — a pasted top -stats line (dasd, 264M MEM, 46G CMPRS), the swap figures before and after, the to_mb() awk helper and the guard's threshold logic — which makes the central mechanism claim checkable in principle. But n=1 host, no OS version or RAM size, no reproduction, no root cause for the daemon growth, and no independent source or vendor acknowledgement; the CMPRS unit semantics are left undefined even though the swap attribution depends on them.
One self-reported host
Observed adoption is exactly one deployment on the author's own machine, with one logged remediation outcome. No third-party users, forks, downstream reports, vendor fix, or organisational rollout appears anywhere in the supplied material.
Real mechanism, over-generalised framing
The underlying observation is legitimate and specific — compressed memory is not counted in RSS, so an RSS-sorted view can miss a large consumer — and the guard's reported outcome is plausible. Overstatement comes from generalising a single host's daemon behaviour into a claim that RSS threshold monitoring is broken, from asserting the 46GB CMPRS figure as the cause of 37GB swap without defining the column's units or ruling out other consumers, and from wrapping the technical finding in unverifiable monthly revenue figures that inflate perceived stakes.
Self-promotional build-log incentives
The source is the author's own personal-brand post on a developer publishing platform, structured around a monetised autonomous-agent business: a rags-to-1.2M-yen narrative frames the debugging story, and credibility for that business is served by presenting the incident as hard-won expertise. There is no disclosed vendor sponsorship, product for sale, or affiliate relationship in the supplied material, so the incentive is reputational and audience-building rather than commercial payment.
Moderate-low
Confidence is limited by single-sourcing and the absence of any corroboration, but supported by the specificity and internal consistency of the artifacts: the pasted top line, the threshold code, and the before/after swap figures all cohere, and the core OS behaviour claim is of a kind that is externally checkable. Quantitative details (the 46GB-to-37GB accounting) and generality beyond one machine remain unverified.
build
Exit 0 is not a health check: three weeks of macOS backups that copied nothing1 distinct publisher
build
launchd Tells You Nothing When a Job Dies, So Your Revenue Reports It Instead1 distinct publisher
build
The 2-4 seconds you pay per file: batch tsc once per agent session, not once per edit1 distinct publisher
build
Yadda 3's real artifact is not the code, it is the rules the agent could not rewrite1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 17, 2026