6 views
-/https://github.com/berriai/litellm/issues/27550
GitHub · issue

#27550 [Feature]: Add an LLM as an orchestrator to choose which LLM to call in the gateway

  • State: open
  • Author: @aymen20002005
  • Labels: enhancement, SDK

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### The Feature

Add an LLM-based orchestration layer in the gateway that dynamically selects which downstream LLM provider/model to call based on the incoming request context. The orchestrator should analyze factors such as task type, latency requirements, cost constraints, model capabilities, token limits, and reliability, then route the request to the most suitable LLM automatically.

The feature could also support:

Fallback strategies when a provider fails Multi-model routing policies Context-aware model selection Load balancing between providers Configurable routing rules and priorities

### Motivation, pitch

Currently, model selection must be handled manually or through static configuration, which makes it difficult to optimize for performance, cost, and reliability across different use cases.

I'm working on scenarios where different requests benefit from different models:

lightweight models for fast/simple tasks, reasoning-focused models for complex workflows, cheaper models for cost-sensitive operations, specialized models for coding, embeddings, or st…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (11 events)
#0 of 0 · 31d19h11m58s ago — entered · #import:https:::github.com:berriai:litellm post #1675
The orchestration feature spans gateway architecture, model-selection logic, policy configuration, provider capabilities, fallback behavior, observability, and extensive testing, creating substantial integration and reliability risk. The other task is a narrowly scoped metadata update with limited code impact and straightforward validation.
The second issue requires designing and integrating a cross-cutting gateway orchestration system involving decision logic, routing policies, provider capabilities, failures, configuration, observability, and extensive compatibility testing. The first is comparatively localized to update semantics, validation, persistence, and UI/API synchronization for an existing field.
The right-side work is substantially harder because it introduces a cross-cutting decision engine spanning request classification, routing policy, provider capability matching, fallback behavior, configuration, latency, cost controls, observability, and failure handling. The left-side change is comparatively localized: a configuration-controlled adjustment to existing guardrail error propagation with targeted tests and clear safety semantics.
The orchestration feature spans gateway architecture, routing policy design, provider/model selection, fallback behavior, configuration, observability, and extensive integration testing. The cache propagation defect is comparatively localized to a transformation path with focused regression coverage.
The right issue is substantially harder because it requires a cross-cutting gateway architecture, decision policies, configuration, provider capability and failure handling, observability, and broad integration testing. The left issue is comparatively localized to one streaming transformation path with focused regression coverage.
The right issue is substantially harder: it requires a cross-cutting gateway orchestration architecture involving dynamic routing, policy evaluation, provider selection, failure handling, configuration, and broad integration testing. The left issue is a localized provider-specific schema transformation with comparatively contained implementation and validation.
Issue 27550 is substantially harder: it requires cross-cutting gateway architecture, model-selection logic, policy configuration, provider failure handling, and broad integration and reliability testing. Issue 33512 is comparatively localized to dashboard-generated commands and configuration templates.
The right issue requires substantial gateway-wide design, model-selection logic, provider integration, failure handling, policy configuration, and testing across routing scenarios. The left issue is a comparatively contained Helm-template enhancement with limited implementation and validation scope.
The orchestration feature is substantially harder because it spans gateway architecture, routing policy design, provider integrations, failure handling, configuration, observability, and extensive evaluation/testing. The other issue is a comparatively localized correctness fix involving an existing persistence and cache path.
27550 requires a broad gateway-wide decisioning system spanning provider capabilities, policy configuration, reliability behavior, observability, and extensive integration testing. 31706 is comparatively bounded: exposing and normalizing model-discovery results across API bases, with authentication and provider-compatibility edge cases.
#0 of 0 · 31d18h31m27s ago — current · #import:https:::github.com:berriai:litellm post #2343
#27550 spans new gateway architecture, dynamic decisioning, policy configuration, provider routing, failure handling, and broad testing; #29785 is comparatively localized diagnosis and correction of an existing connection-test path.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search