529 Overloaded for a minute, or you burn through a Max plan window at 11am and the next reset is three hours out. Without help, both look the same from your side: a turn that stops, a prompt you have to send again, and an autonomous run that quietly stalls until you notice.
Agent Resilience answers that failure for you. When a turn fails for a reason that time alone will fix, Maestro keeps the exact prompt, waits the right amount, and sends it again. You get a live status card in the transcript instead of an error dialog, and long Auto Run batches survive an outage that started while you were asleep.
It is on by default for every agent.
What it does
When an agent turn fails, Maestro classifies the error and picks one of two strategies.
The resend is your original prompt replayed through the same code path that sent it the first time, so attached images, slash commands,
@ file mentions, and your tab’s model and effort settings all survive unchanged. This holds for every provider, not just Claude Code.
It keeps trying until it goes through
A quota does come back on a clock, so the obvious thing to do is read the reset time and sleep until it. Maestro does read the reset time, but it does not sleep on it, because the provider’s notice is not the only way the wait can end. You can point the agent at a different account or a different provider. The plan can roll over early. The message can name the five-hour window when the weekly one is what actually ran out. A single long sleep is blind to all of that. So Maestro probes instead: 15 seconds after the limit hits, then 30, then once a minute for as long as it takes, and exactly on the reset moment when the error named one. Each probe is your real prompt resent, because that is the only honest test of whether the quota is back, and it costs nothing when it is not: the provider refuses before spending any tokens, and the outage card updates in place instead of adding a card per attempt. The Retries counter on the card is the count of probes so far. Maestro reads the reset moment out of the error itself, in descending order of confidence, and uses it to make sure a known reset is met on the second rather than up to a minute late:- The provider’s own quota block. Claude Code sends
quotaLimits.resetsAtalongside the limit message, which is the exact reset second, so the retry lands the moment your window reopens rather than up to an hour late. - A top-level
retryAfter/resetAtfield, or aretry after 30 seconds/try again in 5 minutesphrase. - Claude Code’s legacy
Claude AI usage limit reached|1755500000epoch marker. - The banner text itself, which names its own timezone:
You've hit your session limit · resets 11:40am (America/Chicago). This is the fallback for paths that forward only the message.
resets at 3pm) is deliberately ignored, since a wrong guess would only pull a probe forward to a moment that means nothing.
Claude Code does not report a hit plan limit as an error. It sends an ordinary-looking assistant message whose text is the banner, which is why an unpatched build showed the notice as a normal reply and the turn appeared to succeed. Maestro recognizes that message specifically. It requires the banner to be the entire message, so an agent that merely writes about usage limits is never mistaken for one.
What it will never retry
Some failures need you, and retrying them either loops forever or hides a real problem. These always surface the normal error dialog instead:- Expired or invalid credentials
- Permission denied
- Session not found
- A human-in-the-loop gate in an Auto Run document
- A full context window (
prompt is too long) - resending the same oversized prompt cannot help - An agent crash
The status card
An outage collapses into a single live card in the transcript, not a wall of repeated error bubbles. While it is retrying, the card shows which failure mode you are in, how many retries have gone out, how long the outage has been running, and a live countdown to the next attempt. Two buttons:- Try now - skip the timer and resend immediately. Useful when you know the provider recovered, or you just switched accounts.
- Stop - give up on this outage. The card freezes into a summary and the turn is yours to handle.
Pending retries do not survive quitting Maestro. This is deliberate: a closed app should not sit in the background burning quota on your behalf. Reopening the app leaves the outage card in place as a dim summary, and you send the prompt again yourself.
Queued messages
If you queued several messages behind a turn that then failed, the queue holds. It does not drain into a provider that just refused you, because every queued message would hit the same wall and fail in turn. The retry goes out for the prompt that actually failed. Your queue then drains in order behind it, exactly as it would have if the outage had never happened. Nothing is dropped and nothing is reordered, so a batch of work you lined up before bed is still there in the morning. Sending a new message while a retry is counting down is different: that is you moving on, so it takes over. The countdown stops, the outage card freezes into a stopped summary, and your new prompt goes out instead.Prompts that arrive from automation
A turn does not have to be typed to be covered. Prompts that arrive frommaestro-cli dispatch, a Cue pipeline, or the web and mobile composer are ordinary desktop turns, and they retry on exactly the same rules as one you typed yourself.
This matters more for automation than for interactive use: when a scheduled pipeline hits a quota wall at 3am, nobody is watching to press Try now.
Turning it on and off
Both toggles live in the New Agent dialog when you create an agent, and in Edit Agent afterwards. To reach Edit Agent, right-click the agent in the Left Bar and choose Edit Agent…, or pressCmd+K / Ctrl+K and pick Edit Agent.
- Retry on availability errors - overloaded, 529, and server errors. Backs off 30s to 30m, then keeps trying.
- Retry on token exhaustion - plan or quota limit reached. Keeps resending, about once a minute, until it goes through.
Auto Run
An Auto Run batch is where this matters most, because a stalled overnight run wastes the whole night. When a batch turn fails with a retryable error, Maestro parks the loop rather than aborting it, then resumes it automatically once the backoff elapses. The run continues from where it stopped, re-reading the document so any task you checked off in the meantime is respected. You get a toast reading Auto Run: retrying, and the History entry records the outage rather than logging it as a plain failure. You can still take over: cancel the auto-retry from the status card and the batch’s usual resume, skip, and abort controls come back.Auto Run batches launched from
maestro-cli do not auto-retry. Resilience is a desktop feature, and the CLI’s batch runner reports the failure instead. A prompt sent INTO the running desktop app with maestro-cli dispatch is different: it is a normal desktop turn and retries like any other.Tracking it over time
The Usage Dashboard (Cmd+Alt+U / Ctrl+Alt+U) keeps score under Activity → Resilience: how many outages Maestro carried your work through, how much downtime it bridged while you were away, the recovery rate, and a per-day timeline split into recovered vs. stopped. Only resolved outages are counted - a countdown still in progress shows on its transcript card, not here.
See also
- Provider Notes - Claude Code token sources, and how Dynamic mode switches from Max plan quota to API when a window runs dry
- Auto Run & Playbooks - the batch runner resilience keeps alive
- Troubleshooting - agent errors that resilience deliberately does not handle