Quick Start
1
Enable with defaults
Enable retry for all tools with safe defaults:
2
Tune attempts and backoff
Configure specific retry behavior:
3
Override per tool
Different tools may need different retry strategies:
How It Works
An error is tagged
rate_limit when its message contains either "rate…limit" or "too many requests" — the latter catches HTTP 429 responses whose bodies use the standard phrasing without the word “limit”:
Precedence Ladder
retry_policy=None on @tool(...) means use the fallback — the tool-level slot is treated as empty, not as “no retries”. To disable retries for a specific tool, pass an explicit RetryPolicy(max_attempts=1) instead.
Tool-level (highest priority):
Choosing a Retry Policy
Configuration Options
Non-retryable error types (always short-circuit):
approval_denied,permission_denied,approval_error,circuit_open- Python exceptions:
ValueError,TypeError,AttributeErrorfrom tool code
Common Patterns
Per-tool override for unreliable API
YAML configuration
In YAML the field name is still
tool_retry_policy:; in Python pass retry settings through tool_config=ToolConfig(retry_policy=…). The standalone tool_retry_policy kwarg on Agent(...) was removed and raises TypeError.CLI usage
If the retry backend isn’t available (the CLI accepted the flags but the runtime dependency is missing), you’ll now see a
tool_retry_policy requested but retry backend unavailable: <ImportError> warning in the logs instead of the settings being silently dropped. Install the retry backend or drop the --tool-retry-* flags to clear the warning.Hook Integration
Monitor retry attempts with hooks:OnRetryInput:
tool_name: Name of the failing toolattempt: Current attempt number (1-based)max_attempts: Maximum attempts configureddelay_ms: Delay before this retry in millisecondserror_type: Classified error type (timeout,rate_limit, etc.)error: Original exception object
Best Practices
Keep max_attempts small (3-5)
Keep max_attempts small (3-5)
Large retry counts mask real failures. If a tool fails 10+ times, there’s likely a deeper issue that retrying won’t solve. Use monitoring instead.
Always set jitter=True for rate-limited APIs
Always set jitter=True for rate-limited APIs
Without jitter, multiple agents retrying simultaneously create a “thundering herd” that can overwhelm rate-limited services. Jitter spreads out retry attempts.
Set narrower retry_on for expensive tools
Set narrower retry_on for expensive tools
Don’t retry LLM tools on
connection_error if every attempt costs money. Use specific error types that indicate transient failures.Use tool-level override sparingly
Use tool-level override sparingly
Agent-level retry policy keeps configuration DRY. Only override at the tool level for genuinely special cases like unreliable third-party APIs.
Related
Tool Configuration
Consolidated tool configuration with ToolConfig
Concurrency
Parallel tool execution and timeouts
Hooks
Monitor and intercept agent behavior
Hook Events
Complete reference of hook events

