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 structuredFailoverDecision 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 inclassify_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 aFailoverDecision 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_timeoutfailures - Auto-resets: On any successful LLM call
- Only triggered by:
idle_timeouterror 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
Treat Permanent Errors as Config Issues
Treat Permanent Errors as Config Issues
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.Tune Circuit Breaker by Model Speed
Tune Circuit Breaker by Model Speed
Fast cloud models can use the default
max_consecutive=3. Slow self-hosted models should increase this to avoid premature circuit breaking.Use Typed Categories Over String Matching
Use Typed Categories Over String Matching
Instead of parsing error messages, use the typed
error_category field for reliable error handling.Pair with Model Failover for Cross-Provider Resilience
Pair with Model Failover for Cross-Provider Resilience
Combine error classification with Model Failover to automatically switch providers on
auth errors.Related
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

