Retry like you read the headers.
1. Know the limit model. Limits apply per organization. Start, Build, and Scale tiers each carry a monthly spend cap: the maximum the org can spend per calendar month. Higher tiers raise the caps; if you are planning scale, sort the tier before you need it.
2. Read the headers on every response. Responses carry anthropic-ratelimit-requests-limit, remaining, and reset, plus input-tokens and output-tokens variants. Track remaining against reset in your client and shed load before you hit zero: client-side throttling beats server 429s.
3. Honor retry-after on 429. A rate_limit_error may include a retry-after header telling you how long to wait. Wait it out with exponential backoff and jitter on top. The SDKs retry automatically on some errors: know exactly which errors yours retries so you do not double-retry.
4. Distinguish paused usage from rate limits. When the org hits its monthly spend cap, usage pauses and requests return 429 with the same rate_limit_error type but no retry-after header. Retrying, including SDK automatic retries, fails until access resumes. Detect the missing retry-after and surface "usage paused" to the user instead of looping.
5. Separate retryable from fatal. Retry 429s and 529 overloaded errors. Do not retry 400s (bad request, including rejected thinking parameters), 401s (bad key), or 404s: those need a code or config fix, and retrying them burns quota.
6. Queue, do not hammer. For bulk workloads, put requests in a queue with a concurrency cap derived from the rate-limit headers instead of firing all at once and relying on retries. Consider the Message Batches API for non-urgent bulk work: it is built for throughput and costs half.