Auto-retry with backoff on shared-capacity rate limits instead of failing the turn

Problem

When the API returns Server is temporarily limiting requests (not your usage limit) · Rate limited, Claude Code terminates the turn. The user returns to a dead-end conversation with no progress and no automatic recovery, despite having usage quota remaining.

This is particularly disruptive during long autonomous runs (e.g. /loop, multi-agent orchestration, do-work skill) where losing a turn mid-task can lose significant state.

Expected behavior

Shared-capacity throttles are transient and not caused by the user exceeding their plan. The client should:

1. Detect the shared-capacity error (distinct from quota exhaustion).
2. Retry with exponential backoff for a bounded window (e.g. up to 60s) before surfacing the failure.
3. Surface a visible "waiting on capacity" indicator during the retry window so users know it's recovering, not hung.

Why this matters

• Users are effectively throttled twice: once by the API, once by losing the ability to continue a session they're paying for.
• No reliable Retry-After header doesn't preclude client-side backoff — 250ms → 500ms → 1s → 2s → 4s capped at 60s would catch the vast majority of these transient throttles.
• The "state goes stale" argument against retry doesn't hold for short windows — prompt cache TTL is 5 minutes.

Suggested implementation notes

• Only auto-retry for the shared-capacity / 529-class errors, not 429 quota errors.
• Make max retry window configurable (env var or setting).
• Skip auto-retry if the last tool call was destructive and its response was dropped (avoid double-fire on writes).