Skip to main content
PraisonAI classifies every LLM failure into one of 11 typed categories so retries, failovers, and circuit breakers can react correctly without parsing error strings.
The user sends a prompt; transient LLM errors trigger retries or profile rotation instead of opaque failures.
The underlying classifier now prefers exception type and HTTP status code over message text, so AgentErrorKind decisions stay stable across providers whose messages don’t include the expected keywords (e.g. a 429 without the word “rate”). See Structured LLM Errors for the classification order.

Quick Start

1

Simple Usage

Error classification happens automatically when using agents:
2

Read Error Category

Access the typed error category in error hooks:
3

Custom Idle-Timeout Protection

Tune the idle-timeout circuit breaker for different scenarios:

How It Works

The classification system converts every LLM exception into a structured FailoverDecision that tells retry logic exactly what to do. Classification (is_retryable, should_fallback_model) is consulted from every turn shape — non-streaming, streaming, tool-iteration, reflection, sync and async — so an LLMError category maps to the same retry/failover decision regardless of how the turn is being executed.

Error Categories

All LLM failures are classified into these 11 typed categories: As of PR #1898, billing errors are explicitly added to the non-retryable list and are classified before rate-limit (so quota exceeded no longer double-matches as a rate-limit error). This means a quota-exhausted call now surfaces immediately instead of retrying with backoff.

Classification Ordering

The order of checks in classify_error_kind matters: billing is checked before rate-limit so phrases like quota exceeded route to billing (non-retryable) instead of rate_limit (retryable). Auth is checked before billing so auth_permanent takes precedence on invalid API keys.

FailoverDecision Structure

Every classification produces a FailoverDecision with these fields:

Idle-Timeout Circuit Breaker

The idle-timeout circuit breaker is separate from the per-tool circuit breaker. It protects against LLM provider stalls:
  • Default: Stops after 3 consecutive idle_timeout failures
  • Auto-resets: On any successful LLM call
  • Only triggered by: idle_timeout error kind (not other timeouts)

Choosing Between Options

Common Patterns

Log Every Classified Failure

Custom Breaker for Slow Models

Gate Alerts by Error Type

Legacy Migration

The old error_category string values still work but emit a DeprecationWarning. Update to the new typed categories for cleaner code.
Example migration:

Migrating from _classify_error_and_should_retry

If you previously subclassed LLM to override _classify_error_and_should_retry, that method now emits a DeprecationWarning and delegates to resolve_failover_decision. Override resolve_failover_decision directly instead — it returns a typed FailoverDecision instead of a (category, retry, delay) tuple.

Best Practices

Errors classified as auth_permanent, model_not_found, and context_overflow indicate configuration problems, not transient failures. Set up monitoring to catch these during development.
Fast cloud models can use the default max_consecutive=3. Slow self-hosted models should increase this to avoid premature circuit breaking.
Instead of parsing error messages, use the typed error_category field for reliable error handling.
Combine error classification with Model Failover to automatically switch providers on auth errors.

Structured LLM Errors

Foundation error handling with LLMError structure

Model Failover

Cross-provider failover with FailoverManager

Tool Circuit Breaker

Per-tool circuit breaking for tool execution

Execution Config

Configure max_iter and other execution parameters