OpenRouter vs LiteLLM (2026) — sono livelli diversi e la maggior parte dei team che lo chiede dovrebbe eseguire entrambi

Il confronto è impostato in modo errato quasi ovunque compaia, e il quarto risultato di questa ricerca lo dimostra: è la pagina della documentazione di LiteLLM dedicata a OpenRouter. LiteLLM include un'integrazione con OpenRouter perché i due prodotti non sono sostituti: appartengono a livelli diversi. LiteLLM è un proxy che distribuisci sugli account dei provider che possiedi; OpenRouter è un servizio ospitato che possiede gli account dei provider per te e rivende l'accesso ai modelli. Un proxy ha bisogno di una fonte; OpenRouter è una fonte. Molti team usano deliberatamente entrambi.

Dichiarazione di parzialità: Kunavo è il nostro prodotto e in questa pagina appartiene al lato OpenRouter: una fonte ospitata di modelli, non un proxy. Non è un'alternativa a ciò che fa LiteLLM, e la pagina non sostiene il contrario.

La differenza di livello, in una tabella

Leggi la riga «è una fonte di modelli?» dall'alto verso il basso e l'impostazione del confronto crolla. Ogni altra differenza deriva da quella.

Usarli insieme, il caso più comune

LiteLLM davanti, OpenRouter dietro: le tue applicazioni comunicano con un unico endpoint interno, LiteLLM applica budget per chiave e instradamento dei team, mentre OpenRouter fornisce il catalogo senza che tu debba aprire un account presso ogni provider. Qualsiasi endpoint compatibile con OpenAI si inserisce nello stesso modo, quindi aggiungere una seconda fonte per il failover richiede poche righe:

# LiteLLM and OpenRouter are layers, not rivals. This is a
# LiteLLM config with two model sources behind one proxy.
model_list:
  - model_name: claude-sonnet
    litellm_params:
      model: openrouter/anthropic/claude-sonnet-4.6
      api_key: os.environ/OPENROUTER_API_KEY

  # A second source behind the same proxy — any OpenAI-compatible
  # endpoint works the same way.
  - model_name: claude-sonnet-backup
    litellm_params:
      model: openai/claude-sonnet-5
      api_base: https://api.kunavo.com/v1
      api_key: os.environ/KUNAVO_API_KEY

Questa è l'impostazione che la domanda «vs» dovrebbe avere di solito: non quale scegliere, ma se ti serve davvero il livello proxy sopra una fonte ospitata.

Quando ti serve davvero soltanto uno dei due

• Solo OpenRouter: non hai account presso i provider, non ne vuoi avere e le tue esigenze di instradamento sono soddisfatte da ciò che offre già un gateway ospitato. Aggiungere LiteLLM qui significa ottenere un servizio da gestire e poco altro. Alternative in questa categoria: la raccolta su OpenRouter.
• Solo LiteLLM: possiedi già account presso i provider, eventualmente con tariffe negoziate, e ciò che ti manca è il controllo: un endpoint, budget per chiave, criteri di instradamento e testo dei prompt che non lasci mai la tua infrastruttura. Un rivenditore non può offrirti quest'ultimo elemento a nessun prezzo.
• Nessuno dei due: vuoi instradamento e governance, ma non vuoi gestire un servizio. Si tratta di un control plane ospitato con BYO-key, una terza categoria al di fuori della quale si collocano entrambi: le quattro categorie di gateway LLM.

Le due cose da verificare prima di scegliere uno dei due

Dal lato LiteLLM: la superficie operativa. Un proxy self-hosted è un pacchetto nella tua build, quindi mette CI/CD e cluster nel suo raggio d'impatto: non è un'ipotesi teorica per questo progetto, come ha dimostrato l'incidente della supply chain di marzo 2026. La risposta di LiteLLM è stata sostanziale e l'incidente è chiuso per chi usa v1.83.0 o versioni successive, ma il punto strutturale vale per ogni proxy self-hosted.

Dal lato OpenRouter: il prezzo minimo. Un rivenditore che trasferisce i prezzi di listino applicando una commissione sugli acquisti di crediti non è automaticamente più economico del tuo account, né automaticamente più costoso se il tuo account applica il listino pubblico. Il confronto utile consiste nel verificare la tua tariffa effettiva rispetto a quella effettiva del gateway, modello per modello, per i modelli che utilizzi. Kunavo elenca la maggior parte dei modelli a tariffe inferiori a quelle ufficiali dei provider: è lo stesso confronto visto dall'altra direzione: Kunavo vs OpenRouter.

Compatibilità del protocollo, per rendere economico il passaggio

Entrambi parlano il protocollo wire di OpenAI, così come ogni alternativa ospitata a uno dei due (la documentazione di OpenRouter · quella di LiteLLM). Qualunque scelta tu faccia, il costo di sbagliare è una base_url e una modifica della chiave, il fatto più utile di questa pagina: questa decisione non merita le settimane che alcuni team vi dedicano. Dettagli nella guida all'API compatibile con OpenAI.

Domande frequenti