Skip to main content

RouterAgent

The RouterAgent class is an intelligent agent that automatically selects the most appropriate LLM model for each task based on various factors like task complexity, required capabilities, cost optimization, and performance requirements.

Overview

RouterAgent extends the base Agent class and adds sophisticated model routing capabilities. It analyzes incoming tasks and dynamically chooses the best model from a configured set of options, optimizing for cost, performance, or specific capabilities as needed.

Basic Usage

Configuration Options

Core Parameters

  • models (list[str]): List of available models to route between
  • routing_strategy (str): Strategy for model selection
    • "auto": Automatic selection based on task analysis
    • "manual": User specifies model per request
    • "cost-optimized": Prioritize cheaper models when possible
    • "performance-optimized": Always use the best performing model
  • fallback_model (str): Model to use if primary selection fails
  • model_capabilities (dict): Custom capability definitions for models
  • cost_threshold (float): Maximum cost per request (for cost-optimized strategy)
  • performance_metrics (dict): Custom performance metrics for models

Inherited Parameters

All parameters from the base Agent class are also available.

Routing Strategies

Automatic Routing

Cost-Optimized Routing

Performance-Optimized Routing

Manual Routing

Advanced Features

Custom Model Capabilities

Usage Tracking and Reporting

Fallback Handling

Integration with Other Agents

Best Practices

  1. Model Selection: Choose models that complement each other:
  2. Strategy Selection:
    • Use "auto" for general-purpose applications
    • Use "cost-optimized" for high-volume, budget-conscious apps
    • Use "performance-optimized" for critical applications
    • Use "manual" when you need explicit control
  3. Capability Definition: Define clear capabilities for better routing:
  4. Monitoring: Usage is automatically tracked:

Performance Considerations

  • Initial task analysis adds 0.1-0.5s overhead
  • Model switching has minimal latency impact
  • Usage tracking adds ~1% memory overhead
  • Capability matching is O(n) where n is number of models

See Also