Wäg e LiteLLM: la stessa API, un livello diverso

Non un concorrente sullo stesso livello

La stessa superficie API compatibile OpenAI. La stessa configurazione, importabile.

Gratuito qui. Enterprise lì.

Entrambi i progetti sono open source con un livello commerciale. La domanda non è mai stata se esista un'edizione a pagamento, ma dove ciascuno traccia la linea. La documentazione Enterprise di LiteLLM elenca ciò che la loro chiave di licenza abilita, e gran parte di quell'elenco in Wäg è Apache-2.0. Sulla multi-tenancy la differenza è strutturale: nel loro schema di database pubblicato un'organizzazione porta un budget, i totali di spesa e un elenco di membri, e un team vi fa riferimento con una chiave esterna opzionale, il che ne fa un livello di raggruppamento sopra i team. In Wäg un'organizzazione è un confine di autorizzazione verificato a ogni richiesta. Dove anche noi mettiamo la stessa funzione dietro una licenza, la tabella lo dice.

Per correttezza: il loro livello Enterprise comprende anche liste di IP consentiti e un rapporto SOC 2 Type II. Oggi non abbiamo né l'uno né l'altro.

La colonna LiteLLM viene dalla loro documentazione Enterprise, che indica come una chiave di licenza abiliti le funzioni elencate. Non indicato significa che una funzione non è nominata in quella pagina, il che non equivale a impossibile. La colonna Wäg riflette la ripartizione di licenza che il gateway applica: una funzione Enterprise è un modulo che una licenza firmata deve nominare. Le righe sugli agenti segnate Non indicato sono un caso diverso: il loro gateway per agenti non è affatto una funzione Enterprise, quindi quelle funzioni mancano dal loro prodotto anziché essere comprese nella licenza.

Entrambi offrono un gateway per agenti. Solo uno governa l'agente.

LiteLLM ha aggiunto un gateway di agenti A2A, e fa bene le cose ovvie: registrare gli agenti, controllare quali team e chiavi possono raggiungerli, attribuire il costo. Due righe sono vera parità. Le altre sono il punto in cui i due prodotti smettono di essere la stessa cosa.

La colonna LiteLLM riporta quanto mostrano la loro documentazione e il loro repository pubblico. Non documentato significa che la funzione non vi è descritta, il che non equivale a dire che sia impossibile. Tre righe meritano il dettaglio. Il loro arresto di emergenza invia un webhook al runtime dell'agente e lascia, con le loro parole, l'agente registrato e attivo dal lato LiteLLM; il nostro rifiuta l'agente al gateway, su ogni replica e regione, e chiude uno stream già in corso. Il loro require_approval è il campo di OpenAI: impostato su qualcosa di diverso da never, la chiamata torna al client perché la esegua — nulla viene trattenuto, nessuno viene nominato, nulla viene registrato. E per i pagamenti degli agenti, una ricerca nel codice del loro repository per x402 e AP2 non restituisce nulla. Per le API di terze parti la differenza non è l'inoltro. I loro endpoint pass-through instradano verso qualsiasi API esterna con una credenziale scritta nella configurazione, e i permessi per chiave e team sono una funzione Enterprise. Manca la decisione: la destinazione è una rotta statica e non qualcosa che un dato agente può o non può raggiungere, nessuna regola legge gli argomenti della chiamata, nessuna approvazione può trattenerla, non porta etichette di flusso e non conta in un'esecuzione.

Come funziona la governance degli agenti in Wäg

I casi in cui LiteLLM è la risposta giusta

Sinceramente. Se vi riconoscete qui, adottare una control plane vi porta soprattutto complessità operativa di cui non avete ancora bisogno.

• Un team, uno o pochi servizi, e volete il multi-provider oggi.
• Usate import litellm nel codice applicativo per il suo routing in-process e le callback, ed è proprio ciò che apprezzate.
• Avete callback Python personalizzati nel ciclo di vita della richiesta la cui riscrittura sarebbe un lavoro vero.
• Il vostro elenco di provider comprende un caso raro che Wäg non copre ancora.
• I vostri requisiti di governance sono davvero soddisfatti da budget per chiave.

I sintomi, non l'elenco di funzionalità

• I budget devono rispecchiare l'organigramma. Limiti per chiave non possono esprimere «questo team ha 4.000 €, nessun singolo utente oltre 500 €, e gli esperimenti del marketing non devono consumare la capacità dell'ingegneria».
• La policy deve valere per applicazioni che non hanno mai aderito. Una regola applicabile solo dove qualcuno si è ricordato di inserirla non è un controllo.
• Gli agenti hanno allargato molto la superficie. Un turno utente diventa N chiamate a modelli e strumenti verso server MCP remoti. Autenticazione per server, ACL sugli strumenti e audit per passaggio smettono di essere opzionali.
• Qualcuno ha chiesto quanto è costata l'IA, per team, lo scorso trimestre. E rispondere ha richiesto un progetto sui dati anziché una dashboard.
• La conformità chiede prove, non intenzioni. Dal 2 agosto 2026 i poteri di esecuzione GPAI e gli obblighi di trasparenza dell'articolo 50 del regolamento europeo sull'IA comportano un'esposizione a sanzioni. Logging e tracciabilità devono essere dimostrabili.
• Il gateway è diventato portante. Quando ogni percorso di prodotto ci passa dietro, un processo Python con interprete e albero delle dipendenze risolto al deploy è una questione di rischio diversa da quella di dieci richieste al minuto.

Cosa non cambia affatto

Scelte progettuali, non un conteggio di funzionalità

Le tabelle di funzionalità invecchiano in un trimestre. Queste sono scelte strutturali che non cambiano da una release all'altra.

Se LiteLLM fa il suo lavoro, tenetelo. Se ciò che è davvero sotto pressione è la governance anziché il routing, si tratta di un altro livello — ed è quello per cui Wäg è costruito.