A quota error looks like a retry, so 15 jobs idled six hours unnoticed

The arithmetic in the writeup is on the low side. The author prices the outage at 6 hours x 15 jobs = 90 jobs' worth of work ^[2], which only holds if each job runs once an hour ^[17]. He also says these LaunchAgent entries fire every 5 minutes or every hour ^[7]. A five-minute job gets 72 attempts inside a six-hour window ^[15], so fifteen of them on that cadence would produce 1,080 invocations with no chance of succeeding ^[16]. Each one forked a process, made the call, was told the weekly limit was reached ^[3], exited 1, and was rescheduled by launchd ^[4].

Per-job error handling cannot close that loop, and not because the handling is sloppy. Each invocation is a short-lived process that knows nothing about the run before it or about its fourteen siblings, while the quota is a property of the account rather than of the job. The guard's answer is the cheapest shared memory available: one JSON file, an fcntl.LOCK_EX lock, and os.replace() to swap it in so concurrent writers cannot tear it ^[10]. That is the entire difference between fifteen jobs each finding the wall and one job finding it on behalf of the rest.

What the design trades away is detection quality. There is no exit code to key on, because Claude Code returns 0, 1, or other values depending on the situation ^[18], and the error text goes to stderr in a /tmp log nobody tails ^[6]. So the guard reads prose: seven case-insensitive regexes over the last 131,072 bytes of combined stdout and stderr ^[9]. Two of them, "rate limit" and "resets? (at|in|on|tomorrow)", will match output that has nothing to do with quota ^[9], and the penalty for a wrong match is six hours of stopped automation ^[8] until someone runs --reset or open_until expires ^[11]. The 128KB tail fails in the opposite direction: a chatty run that pushes the limit message out of the window passes as healthy.

Then there is the window itself. The limit being defended is weekly ^[3], while the circuit opens for 21,600 seconds and then closes on its own ^[8][11]. A seven-day limit period has room for twenty-eight of those windows ^[14], so if the reset has not arrived, the fifteen jobs wake up, trip the breaker again, and keep cycling, at a cost of one real invocation per job per reopening. That is much better than 1,080 blind attempts, but it is a rate limiter on your own retries, not a stop, and the state file never learns when the quota actually returns.

One caveat on sourcing: this is a single developer's account of his own machine, published on dev.to, and the Y1.2M/month attached to the stack is his stated revenue, not a measured loss ^[1]. The mechanism travels regardless. A scheduler that treats quota exhaustion as a transient error will retry at whatever cadence you configured, for as long as the quota lasts, and will file every attempt as an ordinary failure.