Build1 distinct publisher2 min readUpdated
A 46-line wrapper treats a Claude Code block as an environment problem. Its retry budget covers a third of a five-hour block, and its fixed prompt only works if PROGRESS.md is current.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The interesting decision in this design is where it puts the memory. A session transcript is a side effect of a running process, and Lily's account is precise about what dies with that process: `--continue` restores the record of the last exchange, but not the intent behind it, because the only instance that knew "next I'll do X" is the one that got killed [6].
So the wrapper does not try to restore a mind. It restores a file. That is why the hardcoded prompt matters more than the retry loop. The first invocation uses whatever task string you passed on the command line; every attempt after that sends the same sentence, "read PROGRESS.md and continue the interrupted work," at line 27 [8][9]. Nineteen of the twenty attempts are therefore worth exactly what the file is worth [15]. A PROGRESS.md that is three steps stale does not produce a stall; it produces a confident resume at the wrong place, unattended, with a model that has been told not to ask [10].
Then there is the arithmetic the post does not finish. Twenty retries at five minutes is 100 minutes of unattended coverage [5], against the 300 minutes of the five-hour block the piece opens with [1]. That is a third of the worst case [14]. Hit a genuine full-length block and the loop burns through all twenty attempts, logs max-retries-exceeded, exits 1 [12], and leaves roughly 200 minutes of the block still to run [17] with the session cold again and nobody awake.
The published log supports the same reading from the other direction. The rate limit hit around 2 AM, retries went out at 2:05 and 2:10, the third attempt succeeded, and the run continued to 6 AM [11]. That is about fifteen minutes of downtime [16], not five hours. Either that particular block cleared quickly or the abnormal exit was never a full block at all. Both readings point at the same fix: derive the sleep interval from whatever reset time the tool reports, rather than a five-minute constant repeated twenty times.
One note on provenance. The revenue figures in the post, including 1.2M yen a month within six months of a layoff [13], are self-reported and have no bearing on whether the exit-code check works. The mechanism stands or falls on its own.
The honest version of the argument is narrower than "the environment gets past the limit." The environment can own scheduling, permission handling and the notification. It cannot own the sentence that says what you were in the middle of. A human still writes that one, at every step, or the loop resumes into nothing.
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.
During the block the Claude Code session dies and thousands of tokens' worth of accumulated working context are wiped, including which files were read and how far, why a given architecture was chosen, and what the next step was.
When the user comes back, Claude greets them from a blank slate: "What would you like to do?"
Lily published resume-on-ratelimit.sh, a 46-line script that watches the exit code of the Claude Code process and, on an abnormal exit caused by a rate limit, waits a configured number of minutes and auto-resumes with claude --continue, inheriting the previous session.
The script retries up to 20 times, which the author computes as 5 minutes x 20 = 100 minutes of fully unattended retrying.
When a session has been fully severed during a 5-hour block, --continue can carry over a record of the last exchange but not the context of intent, because the only instance that knew what came next was the Claude inside the working session, and it is gone.
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.
Code shown, outcomes self-reported
Mechanism claims are well evidenced because the script is quoted inline with its defaults, flow diagram, and prompt lines, so a reader can verify what it does. Effectiveness evidence is thin: one narrated log from the author, no verbatim output, no independent reproduction, and no test of the full five-hour block case. The arithmetic gap between the 100-minute budget and the stated block length is verifiable from the article itself.
Author's own machine only
The cluster documents a published script and exactly one user - its author, on macOS, using osascript notifications. No repository metrics, downloads, forks, third-party write-ups, or other deployments appear in the supplied material.
Framing overshoots the mechanism
The post is titled as a fix for a lost night of work, but its own figures show 100 minutes of retries against a five-hour block, with ~200 minutes uncovered before the script exits 1, and the showcase log resumed after only ~15 minutes. Continuity also depends on a human keeping PROGRESS.md current, since 19 of 20 attempts send nothing but that prompt. The mechanism is real and modest; the framing is stronger than the demonstrated coverage.
Personal-brand and revenue narrative
The technical content is wrapped in the author's monetization story - layoff, ¥1.2M/month within six months, automation revenue as a growing share - which creates an incentive to present the wrapper as a decisive fix rather than a partial mitigation. No vendor sponsorship, paid placement, or commercial relationship is disclosed or evident in the supplied source.
High on code, low on effect
Confidence is high that the script exists and behaves as described, because the source is quoted; it is low on whether the approach reliably rescues work during real blocks, because the cluster has one publisher, one self-reported run, an unverified income claim, and a truncated code listing.
build
AI-written code fails the same four ways, and every gate you own reports green1 distinct publisher
build
A cost monitor overcounted 4.9x, then went dark for a week when set -e did its job1 distinct publisher
build
Thirty minutes a day, and none of it from letting the agent write Swift1 distinct publisher
build
The failure modes of AI agents in low-level code have names, and names can be gated in CI1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026