OpenClaw Rate Limit Exceeded 429: Provider, ClawHub, Cooldown, and Fallback Fixes

OpenClaw 429 errors are not one problem. The same visible "rate limit exceeded" message can come from at least five branches: upstream model-provider quotas, ClawHub skill download limits, gateway cooldown state, missing fallback coverage, and oversized agent sessions that keep producing too many provider calls. A useful fix starts by identifying the failing surface, not by repeating a generic "wait and retry" answer.

Use the raw error text as the owner selector. Mentions of retry-after, RESOURCE_EXHAUSTED, request quota, token quota, organization quota, or an upstream provider name point to a model-provider branch. Mentions of clawhub, /api/v1/download, skill install, or anonymous download point to a hub/download branch. Messages about all profiles being in cooldown point to OpenClaw gateway state, but the cooldown is usually a symptom of an earlier provider, auth, quota, or network failure.

Quick Diagnosis: Branch Before Retrying

Run these checks before changing configuration:

bash

openclaw models status

# Recent provider and hub-side 429 evidence
grep -i "429\|rate.limit\|resource_exhausted\|retry-after\|clawhub" ~/.openclaw/logs/openclaw.log | tail -40

Read the first failing log line, not the last summary message. The last message may only say "all in cooldown"; the first provider response usually tells you whether the real owner is Anthropic, OpenAI, Gemini, ClawHub, billing, context size, or a local retry loop.

TL;DR

• Provider quota: obey retry-after, check the provider dashboard, reduce context/concurrency, and configure tested fallbacks.
• ClawHub download limit: stop the install retry loop, authenticate through the current hub flow if available, or wait for the rolling download window.
• Gateway cooldown: restart only after the original provider error has expired or been fixed; restart is not a provider-quota solution.
• Missing fallback: add backup providers before the incident, and test credentials with openclaw models status.
• Context pressure: compact or start a fresh session when tool output, memory, and agent history make each visible task fan out into many provider calls.

Restore Service Now

1. Respect the original limiter. If the raw response contains retry-after, wait for that value. If the provider dashboard shows quota or billing exhausted, a short wait will not help. Reduce context, reduce concurrent agents, switch to a route with remaining quota, or upgrade through the provider's current account flow.

2. Do not rotate model keys for a ClawHub 429. A 429 during skill download or hub access is not fixed by changing Anthropic, OpenAI, or Gemini keys. Stop repeated downloads first. Then authenticate the current OpenClaw/ClawHub route if your installed version supports it, or wait for the download quota window.

3. Clear stale cooldown only after fixing the owner. Restarting OpenClaw can clear local cooldown state, but it does not refill upstream quota or repair a bad key.

bash
openclaw stop
openclaw start

# Or, if you run OpenClaw as a service
systemctl restart openclaw
brew services restart openclaw

4. Move to a verified fallback route. A fallback helps only when the backup provider is already configured, authenticated, allowed by the agent, and has enough quota for the same task. A fallback will not fix invalid credentials, unsupported beta flags, a broken hub download, or a request that is too large for every configured model.

Diagnose by Owner

Fallback Boundaries

Fallback is an availability pattern, not a license to ignore limits. Configure it with three boundaries:

• It should trigger for temporary provider failures, rate limits, and timeouts.
• It should not hide authentication, billing, unsupported model, or invalid request errors.
• It should be tested before traffic moves there.

A schema pattern may look like this, but keep the exact fields aligned with your installed OpenClaw version:

json5
{
  agents: {
    defaults: {
      model: {
        primary: "primary-provider/primary-model",
        fallbacks: [
          "fallback-provider/fallback-model",
          "gateway-provider/gateway-model"
        ]
      }
    }
  }
}

If you use an OpenAI-compatible gateway such as laozhang.ai, treat it as a provider-gateway route. Verify current model IDs, pricing, quota behavior, context limits, and tool support before putting it into a production fallback chain. Do not describe any gateway as "multiplying quota" or "guaranteeing availability" unless that exact claim has been verified in the current run.

Context Pressure Can Create 429s

A user may see one task, while the provider sees dozens of calls. Long agent history, repeated file search, large command output, memory retrieval, subagents, and background retries can quickly consume token-per-minute or request-per-minute limits. Before upgrading a tier, reduce avoidable request volume:

• Start a fresh session for a new task family.
• Compact before large refactors or audits.
• Limit concurrent agents when a provider is close to quota.
• Avoid piping huge logs into the model.
• Prefer targeted file reads over whole-repo dumps.
• Test whether a smaller route can handle low-risk heartbeat or summary work.

This is also why a context-looking failure may actually be a quota failure. If context_length_exceeded appears immediately after failover or cooldown, read the first provider log line before rebuilding context settings.

Prevention

Add a small operational checklist to every OpenClaw deployment:

1. Run openclaw models status after provider changes.
2. Keep at least one tested fallback route for production work.
3. Record which provider owns billing, quota, and model access for each key.
4. Keep hub/download authentication separate from model-provider authentication.
5. Monitor context size and concurrent agent count before incidents.
6. Treat pricing, model IDs, quota, and gateway coverage as volatile facts that require current verification.

FAQ

Is every OpenClaw 429 fixed by waiting?

No. Waiting helps when the provider's rolling window is the only limiter. It does not fix exhausted billing, bad credentials, unsupported model access, ClawHub anonymous download limits, runaway retry loops, or missing fallback routes.

Should I rotate my API key?

Only rotate a key when the first failure is credential-related, the key was exposed, the account owner changed, or the provider console shows the key is invalid. Rotating keys for a quota 429 can hide the real owner and make incident review harder.

Can a gateway solve provider limits?

A gateway can be useful when the reader's job is multi-provider routing, fallback, unified billing, or access-route simplification. It must still be verified like any other provider route. It is not proof that quota, cost, model coverage, or uptime claims are currently true.

Why does OpenClaw say all profiles are in cooldown?

Cooldown is local gateway state after earlier failures. Find the first failed provider or hub response, fix that owner, then restart OpenClaw only if the cooldown state is stale.