On Wednesday morning, October 29, 2026, at 04:10 EDT, my autonomous daily blog task stopped cold mid-run. The worker did not crash. It did not throw an error code or fail its health check. It simply parked. And when Thursday morning rolled around and the recurring scheduler tried to run the next task, nothing moved.
My publishing queue sat motionless for forty-eight hours because a worker was waiting for a reset that was days away.
Here is the setup in plain terms. I run an autonomous fleet where a supervisor agent dispatches coding jobs to worker agents. Each worker runs in an isolated terminal workspace called a lane. The workers rely on large language models to write code, test changes, and publish updates.
Every model provider enforces rate limits. An hourly rate limit is like a highway toll booth that meters cars per minute. If traffic backs up, you idle for ten or fifteen minutes until the gate lifts, and then you drive through.
A weekly quota is completely different. It is not a metered toll booth. It is a monthly phone data cap. Once you burn through your high-speed allowance for the cycle, the phone does not resume ten minutes later. The line goes dead until billing day.
The trap in the pause
My worker harness had a built-in retry mechanism. When an API call returned an HTTP 429 status code (the standard web signal for “too many requests”), the harness did what made sense for a toll booth: it paused execution and reported its state as “parked” to the supervisor.
The trouble on Wednesday was that the error body had nothing to do with a fifteen-minute token bucket. The account had burned its entire seven-day rolling quota. The next request window would not open until Saturday afternoon.
Because the worker reported itself as parked rather than failed, the supervisor assumed work was actively in progress. It held the lane open. It preserved the task lock. It waited quietly for the worker to finish.
Then Thursday morning, October 30, at 04:10 EDT, the daily scheduler fired its recurring check. I call this a due fire: a timer ticks, sees work is owed, and asks the dispatcher for an available lane.
The dispatcher inspected its workhorse array. The primary lane was still tied up by Wednesday’s parked session. And the alternate accounts in the pool were already tapped out.
There was no healthy lane to dispatch. The timer fired into a void, the parked worker sat frozen in its terminal window, and two full days of publishing vanished without a single alarm bell ringing.
What I tried first
My first instinct was to blame the scheduler. I assumed the timer loop had died, because I had seen that exact silent failure before when my due sweep timer stopped for four days and every dashboard read green. I checked the logs. The cron had fired at 04:10 EDT on both mornings, right on schedule.
My second theory was credential drift. I wondered if my account-switching wrapper had scrambled tokens between machines, the sort of confusion I ran into when I kept aligning an account pin nothing was reading. But the credentials on disk were fresh and valid.
The problem was neither a dead clock nor bad credentials. The problem was that my supervisor could not tell the difference between a pause and an eviction.
The duration fork
The fix came down to reading the reset header instead of only checking the status code.
An HTTP 429 response tells you that you are blocked right now. It does not tell you how long to wait. To know whether waiting makes sense, you have to read the retry-after header or parse the reset timestamp in the error body.
I split the rate-limit policy into two branches:
rate limit received (HTTP 429):
reset_window <= 30 minutes -> PAUSE (hold lane, retry on timer)
reset_window > 30 minutes -> EVICT (kill session, release lane, failover)If the reset window is under thirty minutes, pausing in place is fine. The worker holds its context and resumes as soon as the bucket refills. I built that kind of headroom rotation when I set up my multi-account load balancer.
If the reset window is longer than thirty minutes, waiting in place is toxic. The worker must immediately abort its session, release the workspace lock, and report an eviction to the supervisor.
The supervisor can then route the job to a fallback provider, fail over to a pay-as-you-go lane, or escalate to me. Most importantly, the lane is cleared for tomorrow’s fire.
Evict, do not park
That distinction gave me a rule I now enforce across all my agent harnesses: a weekly limit is an eviction, not a pause.
When an agent parks on a weekly limit, it is not saving its spot in line. It is squatting in an empty house where the power has been cut. It cannot finish the task it started, and its presence prevents any other task from starting.
If you orchestrate long-running agents across model tiers, check your 429 handlers today. If your worker treats a 48-hour quota wall the same way it treats a 60-second burst limit, you do not have a self-healing fleet. You have a fleet waiting on a billing cycle.