One shared timestamp decides which priority job gets through an open circuit breaker

Inside run_job the order matters. The function calls circuit_status() first. If the circuit is open, two things have to hold before the job command runs: the caller passed --priority, and claim_priority_probe() returned true ^[5]. Miss either and the guard prints CLAUDE_QUOTA_JOB_SKIPPED to stderr and returns 0 ^[5]. The exit status is success, so anything watching return codes cannot tell a skipped run from a completed one, and the stderr marker is the only record; quota-catchup.py reads those markers when it re-runs the backlog ^[22][15].

claim_priority_probe() does one thing. It opens locked_state(), reads last_priority_probe, and returns False if less than PRIORITY_PROBE_INTERVAL has passed; otherwise it writes the current time and returns True ^[7]. The default interval is 1800 seconds ^[8]. That timestamp is per circuit, not per job, and it lives in a JSON state file guarded by fcntl.flock ^[9], which for one shared integer is the right amount of machinery. The docstring gives the reason for sharing it: repeated calls while the limit is genuinely in force do not bring the quota back, so the number of attempts is capped on purpose ^[10].

The probe budget is therefore fixed. The fallback cooldown is six hours ^[4], and at 1800 seconds a slot, that is 12 attempts across the whole open window, shared by every job carrying --priority ^[19]. Two priority jobs alternating get six each. The timestamp is written at the moment the probe is claimed, before subprocess.run launches the child, so a child that exits without issuing a request has still spent the slot ^[21].

The request itself happens in that child, and the guard is in its PATH. When the job calls the real claude binary, the call goes back through the guard and circuit_status() runs a second time inside the child ^[13]. The parent has to tell the child it is a probe, which it does by setting CLAUDE_QUOTA_PRIORITY_PROBE=1 only when probe_claimed is true ^[11]. The inline comment at lines 491-498 says that without the flag the circuit returns 75 immediately ^[12]. A probe that loses the variable spends its slot and produces a 75 without a request leaving the machine ^[24].

That 43% is one machine's cumulative launchd.log tally, over one quota account and one job mix ^[2]. 231 runs plus 308 skips is 539 scheduled firings, and 231 divided by 539 is 42.9% ^[18]. Two conditions have to hold for the same starvation to appear in another fleet: the breaker trips on a resource shared across jobs, and the jobs consuming most of that resource fire most often. Both hold here, and the comment at lines 18-24 attributes the collateral damage to the reply and engagement jobs, which account for most of the consumption ^[3].

Posting got the flag for a reason unrelated to throughput. The author wrote that it is a job where "if you miss the time slot, it never gets filled" ^[17], and that a successful attempt doubles as early detection of quota recovery, where the previous behaviour was to wait out open_until blind ^[14].

The post's introduction names two pitfalls and says one of them silently dropped a daily job for four days, 2026-09-13 to 16 ^[16]. The available text stops at the definition of run_claude, before either is explained ^[23]. Two hazards are visible in the code as shown: the shared timestamp, which lets one priority job consume the interval for all of them ^[9], and the environment flag, which is the only thing distinguishing a probe from an immediate 75 inside the child ^[12].