Dalle chiamate API dirette a un unico endpoint governato
La maggior parte dei team inizia chiamando OpenAI o Anthropic direttamente dalle applicazioni, con una chiave del provider nell'ambiente di ogni servizio. È il modo giusto di cominciare. Questa guida serve quando non basta più: spostate le applicazioni dietro Wäg una alla volta, senza riscriverle, e ogni passo si annulla rimettendo a posto una riga.
Cosa cambia
- L'URL di base a cui ogni applicazione invia le richieste
- La chiave che invia: una chiave del gateway per applicazione al posto di quella del provider
- Dove risiedono le chiavi dei provider: in Wäg, non in ogni servizio
Cosa no
- Il vostro SDK — openai, langchain, llamaindex e gli altri
- I vostri prompt, i formati di richiesta e la gestione delle risposte
- Streaming, chiamata di strumenti, visione e output strutturati
- I nomi dei modelli che il codice già usa
- I vostri account e contratti con i provider
Non siete sicuri di avere già bisogno di un gateway? Qui si spiega cosa fa, e quando chiamare direttamente il provider resta la scelta migliore: Che cos'è un AI gateway?
Cinque passi, un'applicazione alla volta
1 · Avviate Wäg e aggiungete i provider
Collegate ogni provider al vostro account esistente e date agli alias i nomi dei modelli che il codice già invia. Così nessun riferimento a un modello, in nessuna applicazione, deve cambiare.
# waeg.yaml — aliases named after the models your code already asks for
providers:
openai:
provider: openai
api_key_env: OPENAI_API_KEY
anthropic:
provider: anthropic
api_key_env: ANTHROPIC_API_KEY
models:
- name: gpt-4o
deployments:
- provider: openai
model_id: gpt-4o
- name: claude-haiku-4-5
deployments:
- provider: anthropic
model_id: claude-haiku-4-5Le chiavi vengono risolte dall'ambiente o dal vostro vault, mai scritte nel file.
2 · Emettete una chiave del gateway per applicazione
Ogni applicazione riceve una propria chiave virtuale al posto di quella del provider. È ciò che rende possibili il costo per applicazione, i limiti per team e la revoca di un singolo servizio — cose che una chiave del provider condivisa non permette.
3 · Cambiate l'URL di base e la chiave
Wäg espone la superficie compatibile con OpenAI — chat completions, l'API Responses (stateless), embeddings, immagini, audio, video, OCR, moderazione, rerank, file, batch, realtime e modelli — con streaming SSE reale, più /v1/mcp e /v1/a2a per gli agenti. Nell'applicazione cambiano due righe:
client = OpenAI(
- api_key=os.environ["OPENAI_API_KEY"],
+ base_url=os.environ["WAEG_BASE_URL"], # e.g. https://waeg.internal/v1
+ api_key=os.environ["WAEG_KEY"], # this application's gateway key
)Sono supportate anche le applicazioni costruite sugli SDK di Anthropic o di Gemini: /v1/messages e /v1beta di Gemini sono formati di richiesta di prima classe, non solo traduzioni del formato OpenAI.
4 · Verificate, poi passate all'applicazione successiva
Inviate una richiesta normale, una in streaming e una con chiamata a strumenti, poi leggete gli header di risposta: x-waeg-routed-model dice quale modello l'ha servita, x-waeg-route-reason perché (con il routing intelligente), x-waeg-cache se ha risposto una cache. La richiesta è già nella console con token e costo.
Un ordine sensato: prima gli strumenti interni, poi i carichi batch e offline, poi un servizio di produzione, poi tutto il resto.
5 · Togliete le chiavi dei provider dalle applicazioni
Quando ogni applicazione passa da Wäg, ruotate le chiavi dei provider e cancellatele dagli ambienti applicativi, dai segreti della CI e dai file di configurazione. Da quel momento le custodisce solo Wäg — ed è la maggior parte del vantaggio in termini di sicurezza, e il passo che i team dimenticano più spesso.
Rimettete l'URL di base e la chiave com'erano. Wäg non trattiene alcuno stato da cui dipendano le vostre applicazioni, quindi fino al passo 5 è tutta la procedura. Fate il passo 5 per ultimo, quando siete sicuri — dopo, tornare indietro significa riconsegnare di nuovo le chiavi dei provider alle applicazioni.
Cosa avete guadagnato
- Il costo per applicazione, team e utente, mentre accade — non ricostruito da una fattura.
- Budget che fermano la spesa prima che il provider venga chiamato, non dashboard che diventano rosse dopo.
- Failover su un altro provider o modello quando uno è fuori servizio.
- Regole sui dati — mascherare, oscurare, bloccare — applicate a ogni prompt, anche nelle applicazioni che nessuno ha toccato.
- Una traccia di ogni richiesta: chi, quale modello, perché, quanto è costata, quali regole sono state applicate.
- Modelli aggiunti o sostituiti dalla configurazione, senza rilasciare di nuovo ogni applicazione.
Cosa vi costa
- Un servizio in più da gestire. La modalità embedded non richiede nulla di esterno, ma è a nodo singolo e in memoria, per le prove; la produzione gira su Postgres e OpenFGA, più Redis quando le repliche sono più d'una.
- Un salto di rete in più. Pochi millisecondi a fronte di chiamate ai modelli da centinaia di millisecondi a secondi — e i riscontri in cache tornano più in fretta di qualsiasi provider.
- Qualcuno deve occuparsene. Di solito il team di piattaforma, le stesse persone che gestiscono le altre infrastrutture condivise.
Domande ricorrenti
Devo modificare il codice applicativo?
Due righe per applicazione: l'URL di base e la chiave. Se le vostre applicazioni leggono entrambi dall'ambiente, nemmeno quelle — cambiate l'ambiente.
Possiamo spostare una sola applicazione?
Sì. Le applicazioni che chiamano ancora direttamente il provider continuano a funzionare. Spostarle una alla volta è il percorso consigliato.
Streaming e chiamata di strumenti funzionano ancora?
Sì. Lo streaming è fatto di veri Server-Sent Events, e chiamata di strumenti, visione e output strutturati sono preservati sui formati di richiesta OpenAI, Anthropic e Gemini.
I nostri dati vanno a bitkaio?
No. Wäg gira nella vostra infrastruttura e parla solo con i provider che configurate. Nessuna telemetria, nessun phone-home, e la licenza è un token firmato offline senza server di licenze.
Cosa serve per farlo girare?
Per una prima applicazione, un container in modalità embedded. In produzione, Postgres e OpenFGA, più Redis per mantenere budget e limiti di frequenza coerenti tra le repliche. Lo installa un operator Kubernetes proprietario o un chart Helm; i database restano vostri.
Un endpoint. Tutti i modelli. Controllo completo.
Gestitelo nella vostra infrastruttura
Tutto ciò che serve per gestire una control plane in produzione è sotto Apache-2.0 e lo resterà — routing, alta disponibilità, cache, failover, budget, policy, MCP, job e osservabilità. Self-hosted, senza account, senza chiamate verso l'esterno.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Non è un pull funzionante: le immagini non sono ancora pubbliche. I partner di progettazione ricevono i dettagli del registry in forma privata.
Avvia in 5 minutiContribuite come design partner
Wäg non è ancora disponibile pubblicamente. Lavoriamo con un piccolo gruppo di team che gestiscono IA multi-provider in produzione e prendono sul serio governance e sovranità, per irrobustire la control plane su carichi reali.
- Tutte le funzioni Enterprise incluse, senza costi di licenza
- Migrazione assistita — la facciamo insieme a voi, anche da LiteLLM
- Una linea diretta con gli ingegneri e un'influenza reale su ciò che arriva dopo