openclaw - 💡(How to fix) Fix OpenClaw should auto-pause and auto-retry on provider 429/rate-limit errors [2 comments, 1 participants]

When a model call hits a provider rate limit, OpenClaw currently behaves like the run has effectively stopped until the user prompts again. This is frustrating during long-running work because the provider often includes an explicit retry delay, but OpenClaw does not automatically resume the run.

OpenClaw should treat 429/rate-limit failures as transient resumable pauses, not terminal run failures.

Problem

Current behavior:

• model call hits 429 / TPM limit
• provider returns retry hint like
• run stops progressing
• user must manually prompt again to continue

This creates a poor user experience, especially for:

• long multi-step runs
• coding/debugging sessions
• background work
• high-context GPT-5.x turns that temporarily exceed TPM

Desired behavior

On provider 429/rate-limit:

1. detect the rate-limit condition

2. parse retry delay from:

   • provider error body
   • structured message text
3. mark the run/session as paused for rate limit
4. schedule an automatic retry
5. resume the pending step automatically without needing a new user prompt

Important note: This does not require resuming partial provider generation state. It only requires resuming at the OpenClaw orchestration step by retrying the pending model call.

Proposed run states

Required implementation

• Catch provider 429 errors centrally
• Parse retry delay if available
• Persist retry metadata:
  • run/session id
  • pending step
  • provider
  • model
  • retry count
  • retry_at
• Schedule wake/retry using existing scheduling/wake primitives
• Retry automatically at with small jitter
• Continue run normally if retry succeeds

Retry policy

• default max retries:
• use provider retry hint first
• otherwise use fallback backoff
• repeated 429s should use exponential backoff with cap
• apply jitter to avoid synchronized retries

UX

• retry delay < 30s:
  • retry silently by default
• retry delay >= 30s:
  • surface a short status update like:
    • “Rate-limited, retrying automatically at 09:20:03”

Failure behavior

After max retries:

• mark run
• surface concise error including:
  • provider/model
  • limit type if known
  • retry attempts
  • suggested mitigations:
    • reduce context
    • reduce concurrency
    • use smaller model
    • request higher limits

Optional follow-ons

• pre-retry context shrinking
• model fallback policy
• per-provider concurrency throttling
• projected TPM budgeting before dispatch
• queueing large runs instead of firing immediately into known TPM exhaustion

Acceptance criteria

1. A provider 429 with a retry delay causes the run to pause and auto-resume without user prompting
2. Session/status shows paused-for-rate-limit state and retry time
3. Successful retry continues the original task
4. Repeated 429s back off and eventually fail cleanly after max retries
5. No duplicate final replies are emitted across retries

Why this matters

This would make OpenClaw feel much more resilient during real work. Right now, a brief TPM spike can make a session appear to “go stale” until the user nudges it again, even when the provider explicitly tells us when to retry.