Skip to main content
Agent retry automatically re-runs failed LLM calls — across single-shot, streaming, tool-iteration and reflection turns — with jittered exponential backoff so transient rate limits, overloads, and network blips don’t break your agent.
The user runs an agent; transient LLM failures retry automatically with jittered backoff.

Quick Start

1

Enable with True (simplest)

The user sends a research query; transient LLM failures trigger automatic retries with backoff.retry=True enables retry with sensible defaults: 3 retries, 5 s → 10 s → 20 s exponential schedule, capped at 120 s, with 50% additive jitter.
2

Tune with a dict (no extra import)

3

Full control with RetryBackoffConfig


How It Works

Which turn shapes retry?

retry= applies to every LLM call the agent makes, whether the model is being called for the first turn, a streaming turn, a tool-iteration turn, a reflection turn, or an async equivalent. If you can configure it, it retries. max_retries also caps the recursive retries the LLM path performs after context compression and after backing off on a transient error. These were previously fixed at 2; they now follow the configured policy, and fall back to 2 only when retry= is not set.
Coverage across streaming and tool-iteration paths was made consistent in PraisonAI PR #2665. Before that release, streaming/tool-iter/reflection turns silently bypassed retry — a transient 429 on those paths surfaced raw. On current versions, retry= applies uniformly.
Behavioural change: RetryBackoffConfig.max_retries now also bounds the internal recursive retry loop. If you set max_retries=5, the compression / transient-backoff paths will now retry up to 5 times instead of the previous fixed 2.

Configuration Options

RetryBackoffConfig Fields

Validation — the constructor raises ValueError if:
  • base_delay <= 0
  • max_delay < base_delay
  • jitter_ratio outside [0, 1]
  • max_retries < 0

Precedence


Common Patterns

Rate-limit friendly long jobs

Strict mode — fail fast

Disable recursive retries entirely

Set max_retries=0 to disable the recursive compression / transient-backoff retries while keeping the retry policy configured.

Reproducible tests — disable jitter

Observe retries with a hook

The OnRetry hook receives:

Best Practices

The defaults (base_delay=5.0, max_delay=120.0, jitter_ratio=0.5, max_retries=3) are well-suited to most OpenAI and Anthropic rate-limit patterns. Start with retry=True and only tune when you observe systematic timeouts or excessive waiting.
Setting jitter_ratio=0.0 creates a deterministic schedule that is useful for tests but dangerous in production. When many agents share the same API key and all retry at the same second, they hammer the endpoint simultaneously — exactly what jitter prevents. Keep jitter_ratio at 0.3 or higher in production.
A 120-second wait is acceptable for background batch jobs but not when a human is waiting for a response. For interactive agents, set max_delay to something like 20.0 or 30.0, and keep max_retries low (12).
The OnRetry hook is the right place to log metrics and send alerts. Retries are best-effort — if all attempts fail, the original LLMError propagates to your caller. Build your resilience strategy around catching that exception in your application code, not inside the hook.

Agent retry covers the LiteLLM-backed agent loop. For the native OpenAIClient path used by AutoAgents and direct get_openai_client() callers, see OpenAI Client Retries.

OpenAI Client Retries

SDK-level Retry-After + backoff for the native OpenAI client path.

Tool Retry Policy

Retry tool calls — a different surface from LLM call retry.

Structured LLM Errors

Which LLMError categories are classified as retryable.

Hook Events

The OnRetry event and all other lifecycle hooks.

Agent Retry Strategies

Strategy guidance for production retry patterns.