Handling rate limits and errors like a production system, not a script
A script that calls messages.create() once and prints the result can get away with ignoring errors; a production system can't, because rate limits, transient network failures, and occasional server-side errors are a normal and expected part of calling any hosted API at scale. The Claude API returns typed HTTP status codes — 429 for rate limiting, 5xx for server-side errors, 400 for malformed requests, 401 for auth failures — and every official SDK exposes these as typed exception classes rather than requiring you to string-match error messages, which is brittle and breaks silently when wording changes.
The pattern worth internalizing is a most-specific-first exception chain: check for rate limit errors and retry with backoff, check for connection errors and retry, but let a 400 (malformed request) or 401 (bad credentials) fail immediately, since retrying those just repeats the same failure. Most SDKs also retry a sensible default set of transient errors automatically, so you don't always need to hand-roll this — but you do need to understand what's being retried for you versus what your code still has to handle deliberately, like backing off across an entire batch job rather than one call at a time.