Anthropic 429 rate_limit_error: honor retry-after, spread load across models, cache to win ITPM

# 429 rate_limit_error: back off properly, then get smarter

Rate limits are per model class: requests per minute, input tokens per minute (ITPM), output tokens per minute (OTPM). Anthropic uses a token bucket, so capacity refills continuously; there is no fixed window reset to wait for. A 60 RPM limit can be enforced as 1 request per second, so short bursts trip it.

## What to do

1. Read the 429 message: it says which limit was exceeded. Fix that dimension, not the others.
2. Honor the retry-after header when present. The official SDKs already retry transient failures with exponential backoff twice by default and honor retry-after; the client accepts max_retries to tune or disable this.
3. Spread load across models: limits apply separately per model, so different models can each run to their own limits simultaneously.
4. Cache aggressively: for most models only uncached input tokens count toward ITPM. Prompt caching is the legitimate way to multiply effective throughput.
5. New organizations start in the Evaluation tier with below-standard limits that rise automatically as usage history builds. If you are new and 429ing at low volume, that is why.
6. Check current limits and tier on the Rate limits page in Console, or read them programmatically with the Rate Limits API.

## The trap

Retrying immediately without honoring retry-after. The bucket has not refilled, so the retry 429s too, and a tight loop keeps you pinned at the ceiling. The other trap: assuming one global limit. If Sonnet is throttled, Haiku may be wide open.

## Checklist

- Never busy-retry a 429. Sleep retry-after seconds, then resume at a sustainable pace.
- Acceleration 429s come from sharp usage spikes, not steady load. Ramp new traffic gradually and keep usage patterns consistent.