How to fix Claude API 429 and overloaded errors

Through Lovely Router, a request passes three checks before it reaches Claude: your balance and the key's spend limit, the rate and concurrency limits you set on the key, and the capacity of the channels serving the model. Each check has its own error, in Anthropic's error format so the SDK raises its usual exceptions:

Clients that call Claude in OpenAI format see rate_limit_exceeded for the same 429, and Gemini format uses RESOURCE_EXHAUSTED.

What about 529 overloaded? Anthropic's own API answers 529 overloaded_error when it is under load. Through Lovely Router an overloaded channel is not the end of the request: the gateway retries it on another channel, and you see a 429 or 502 only if every attempt fails. The documented status codes have no 529; treat any other 5xx like 502. Once a stream has started, a busy channel arrives as an overloaded_error event inside the stream instead, because the 200 status has already been sent.

None of these cost money. A request rejected with 429 is not charged, queued requests are charged only when they run, and requests that fail with an error are not charged.

One provider account stops at its own rate limits. Lovely Router serves each model from a pool of channels in a channel group, admits your requests against their combined capacity, and handles most trouble before it reaches you:

High-concurrency LLM apps covers this in depth, and the status page shows each channel group's live success rate and latency. A 429 or 502 that reaches you has already lasted through several attempts, so your client should back off rather than hammer.

1. Raise the SDK's retries

   The Anthropic SDK already retries 408, 409, 429 and 5xx responses with exponential backoff and honors retry-after. It does so twice by default. For batch jobs, raise max_retries:

   Python

   import os
   import anthropic
   
   client = anthropic.Anthropic(
       base_url="https://lovelyrouter.com",
       api_key=os.environ["LOVELY_API_KEY"],
       max_retries=5,  # default is 2
   )

2. Handle what is left

   After the retries run out, the SDK raises. Catch the classes you treat differently, and log the request id so you can look the call up in Logs or quote it to support.

   Python

   def ask(prompt):
       try:
           message = client.messages.create(
               model="claude-sonnet-5.5",
               max_tokens=1024,
               messages=[{"role": "user", "content": prompt}],
           )
       except anthropic.RateLimitError as e:  # 429 after every retry
           print("429:", e.message,
                 "| retry-after:", e.response.headers.get("retry-after"),
                 "| request id:", e.response.headers.get("x-lovely-request-id"))
           raise
       except anthropic.APIStatusError as e:
           if e.status_code == 402:  # balance or spend limit: retrying won't help
               print("402:", e.message)
           raise
       return next(block.text for block in message.content if block.type == "text")

3. Cap your own concurrency

   A worker pool sized below the key's concurrency limit keeps a batch from tripping it at all:

   Python

   from concurrent.futures import ThreadPoolExecutor
   
   prompts = [f"Summarize ticket {i} in one line." for i in range(200)]
   with ThreadPoolExecutor(max_workers=8) as pool:
       answers = list(pool.map(ask, prompts))

Without an SDK, the same policy fits in one flag. --retry covers 429 and 5xx and honors retry-after:

curl --retry 5 --retry-max-time 120 https://lovelyrouter.com/v1/messages \
  -H "x-api-key: $LOVELY_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-5.5", "max_tokens": 1024,
       "messages": [{"role": "user", "content": "Hi"}]}'

For your own retry loop, follow the Errors policy: wait retry-after when present, otherwise 1, 2, 4, 8 seconds capped at 30 plus up to a second of jitter, and stop after about five attempts.

Each key can have a Requests per minute limit (rolling 60 seconds) and a Max concurrent requests limit (open streams count until they end). Both are off by default; set them under Limits & restrictions in API keys. A request over a limit waits up to 2 seconds for room, then fails with 429 and a retry-after header.

Give each workload its own key: production, a nightly batch and an eval run then can't starve each other, and a runaway loop hits its own key's ceiling instead of your app's. API keys covers every key setting.

Every request checks your balance and the key's spend limit before it runs. The spend limit is a lifetime cap on what the key may spend across model requests, tool runs and browser runs, which makes it a good guard on unattended agents and CI jobs. When either is exhausted, you get 402 with billing_error. Don't retry it: add credit on Billing or raise the key's limit. A request that started with a positive balance always finishes, so the balance can end slightly below zero; the next top-up covers it.