Retry behavior
The SDK retries requests that fail with transient HTTP statuses:list[int]
default:"[429, 500, 502, 503]"
HTTP status codes that trigger an automatic retry.
int
default:"3"
Maximum number of retry attempts before raising.
float
default:"0.5 × 2^attempt seconds"
Exponential backoff between retries. First retry waits 0.5 s, second 1 s, third 2 s.
float
default:"30.0"
Request timeout in seconds. Configurable on the client.
Token refresh
On401 Unauthorized, the SDK refreshes the access token once and retries the request. You do not manage tokens yourself.
Configuring timeout
Handling errors
After exhausting retries, the SDK raiseshttpx.HTTPStatusError. Catch it to inspect the status and body:
Handling tool execution errors
Common mistakes
- Adding your own retry loop on top of the SDK. This compounds backoff; rely on the built-in retries.
- Treating
429as fatal. It is retried automatically; only persistent rate limiting surfaces as an error.
Best practices
- Catch
httpx.HTTPStatusErrorto inspect status and body. - Raise the timeout for known long-running operations rather than retrying.
- Use idempotency keys for tool executions you may retry.
Related pages
Resources
The client surface.
Tiers & Limits
Rate limits behind 429s.
Troubleshooting
Resolve common failures.
Examples
End-to-end examples.

