A retry policy answers three questions: which failures are worth retrying, how many times, and how long to wait between attempts. The official Claude SDKs handle much of this for you, and the right enterprise posture is usually to lean on the SDK's built-in behavior, tune it deliberately where your workload demands it, and add application-level handling only for the cases the SDK cannot judge — because they depend on your business logic, not on HTTP.
Which failures are retryable
The dividing line is whether retrying can plausibly change the outcome.
| Failure class | Retry? | Why |
|---|---|---|
| Connection errors, resets, timeouts | Yes | Transient network conditions; the request may never have arrived |
| 429 rate-limit responses | Yes, with backoff | You exceeded a per-window limit; the window will pass |
| Server-side errors and overload (5xx-class) | Yes, with backoff | Capacity or fault conditions that typically clear |
| 4xx request errors (invalid request, auth failure, permissions) | No | The same request will fail the same way; fix the request or credential |
The don't-retry row matters as much as the others. A 401 or 403 retried in a loop is noise at best; on Claude Platform on AWS, for example, a 403 specifically means the request reached the server and was rejected — a wrong workspace ID or a missing IAM action on the principal — which no number of retries will cure.
Configuring the SDK's behavior
The official SDKs across all seven languages are actively maintained, and retry behavior — the default number of attempts, which status codes are retried automatically, and how to change both on the client or per request — is documented in each SDK's own README. This guide deliberately doesn't restate those defaults, because they are library-version specifics that can change between releases; check the repository for the SDK you use (linked below in Sources) and pin the version you validated, as covered in the version-pinning article. The behaviors to look for and set consciously are: the maximum attempt count for synchronous user-facing calls (keep it small — a user waiting on a chat response should not sit through many retry rounds), a larger allowance for offline and batch-style work, and whether your per-request timeout budget accounts for the total time across all attempts rather than a single one.
Backoff: why the waiting strategy matters
Retrying immediately after a capacity-related failure is how clients synchronize into a thundering herd — everyone fails together, retries together, and fails together again. The standard remedy is exponential backoff with jitter: double the wait after each failed attempt and add a random offset so a fleet of clients spreads out rather than stampeding in lockstep. When a response itself indicates how long to wait, honor that signal instead of your own schedule; the details of reading rate-limit responses are covered in the 429-handling article.
Retries and money
One Claude-specific consideration: a retried request that succeeds is a real request — input and output tokens bill at standard rates. That is a reason to cap attempts and to make sure retried work is idempotent from your application's point of view (retrying a "summarize this document" call is harmless; retrying a "send the customer an email via tool use" loop may not be). Prompt caching softens the cost of repeated input: a retry that replays a cached prompt prefix pays the cache-read rate (0.1x the base input price) on the cached portion rather than full price.
Where to go next
Retries interact tightly with timeout tuning and 429 handling — read those two next. For the platform-specific error surface on Claude Platform on AWS, see error codes and retries on that platform.