Tutorial su Requesty: il gateway LLM unificato con failover automatici

La tua applicazione AI funziona alla grande con OpenAI finché il conto mensile non arriva a 2.000 $. Aggiungi Anthropic per un ragionamento migliore e Google per risparmiare, e ora stai gestendo tre API diverse, ciascuna con fatturazione e monitoraggio separati. Quando OpenAI va giù, la tua applicazione si rompe. Quando raggiungi i rate limit, gli utenti vedono errori. Ti serve un approccio più affidabile.

Requesty risolve il problema offrendo un gateway unificato con failover automatici e strumenti di ottimizzazione dei costi. Configura una volta sul dashboard le catene di failover e le preferenze di cache, e ogni richiesta API userà automaticamente quelle policy. 

Quando un provider ha un problema, Requesty passa al tuo modello di backup. Se abiliti la cache su provider supportati come Anthropic, riduci i costi sulle query ripetitive.

In questo tutorial vedremo le funzionalità principali di Requesty. Partirò dalle chiamate API di base tramite il gateway unificato e dallo streaming delle risposte. Poi configureremo i failover automatici per garantire l’uptime, abiliteremo la cache dei provider per ridurre i costi quando le query si ripetono e useremo il dashboard di analytics per monitorare la spesa e ottimizzare l’uso. Queste funzioni funzionano allo stesso modo sia che tu stia creando il tuo primo prototipo AI, sia che stia distribuendo sistemi in produzione su larga scala.

Che cos’è Requesty?

Requesty è un gateway LLM unificato che ti connette a oltre 300 modelli di provider come OpenAI, Anthropic, Google, Meta e AWS tramite una singola API. È un servizio gestito, quindi non devi ospitare nulla tu.

Panoramica e funzionalità principali

Requesty configura le policy di instradamento tramite un dashboard invece che con codice o file di configurazione. Imposti catene di failover, pesi di bilanciamento del carico e preferenze di cache tramite un’interfaccia web, e queste policy si applicano automaticamente a tutte le richieste API.

La configurazione via dashboard abilita:

• Cache nativa del provider: Abilita la cache su provider supportati come Anthropic e Gemini per riutilizzare parti del prompt e ridurre i costi per richieste ricorrenti.
• Failover automatici rapidi: La piattaforma passa automaticamente ai modelli di backup quando un provider ha problemi, con garanzia SLA al 99,99%.
• Analytics in tempo reale: Monitora token, costi, percentili di latenza, tassi di cache hit e frequenza dei failover per tutte le richieste tramite un dashboard unificato.

Queste funzionalità si combinano con policy di routing flessibili (catene di fallback, bilanciamento del carico, ottimizzazione della latenza), protezioni integrate per sicurezza contro PII e prompt injection e un tracciamento dettagliato dei costi.

OpenRouter offre un accesso unificato simile a più LLM ma con routing di base e senza dashboard di analytics. LiteLLM offre funzionalità comparabili ma richiede self-hosting e configurazione manuale in YAML per le policy di routing. Requesty si colloca nel mezzo come servizio gestito con configurazione guidata da dashboard.

Quando dovrei usare Requesty?

Se stai gestendo sistemi enterprise con requisiti di uptime stringenti, l’SLA al 99,99% è importante. Quando la tua applicazione va giù, perdi denaro. Funzionalità di sicurezza integrate come redazione PII e rilevamento di prompt injection gestiscono i requisiti di conformità senza dover costruire questi sistemi da zero. I team soggetti al GDPR possono abilitare l’hosting UE per mantenere i dati nelle giurisdizioni corrette.

I team di sviluppo che costruiscono applicazioni AI in produzione evitano il vendor lock-in cambiando provider tramite configurazione invece che riscrivendo il codice. I failover automatici eliminano la necessità di creare un’infrastruttura di affidabilità personalizzata.

I progetti attenti al budget beneficiano della cache del provider e del bilanciamento del carico strategico. Invece di scrivere tu stesso la logica di ottimizzazione, configuri le policy una volta e lasci che Requesty gestisca la riduzione dei costi.

Prerequisiti

Prepara il tuo ambiente di sviluppo. Richiede circa 5 minuti e copre i pacchetti Python, la chiave API e la configurazione di base.

Ti servirà Python 3.7 o successivo installato sul sistema. Verifica la versione:

import sys
print(f"Python {sys.version_info.major}.{sys.version_info.minor}")Offerto da

Installa i pacchetti richiesti con pip o uv:

pip install openai python-dotenv
# or with uv: uv add openai python-dotenvOfferto da

Ti serve il pacchetto openai per interagire con l’API di Requesty. Il pacchetto python-dotenv gestisce in modo sicuro le variabili d’ambiente.

Crea un account Requesty su app.requesty.ai. Una volta effettuato l’accesso, vai alla sezione API Keys e genera una nuova chiave. Copia questa chiave per l’autenticazione. Non dimenticare anche di aggiungere qualche dollaro al tuo account.

Conserva la tua chiave API in un file .env nella directory del progetto:

REQUESTY_API_KEY=your_api_key_hereOfferto da

Questo mantiene le credenziali fuori dal codice e rende più sicuro condividere il progetto senza esporre segreti.

Verifica che tutto funzioni caricando le variabili d’ambiente e controllando che la chiave API sia accessibile:

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
api_key = os.getenv("REQUESTY_API_KEY")

# Check your setup
if api_key:
   print("✓ API key loaded")
   client = OpenAI(
       api_key=api_key,
       base_url="https://router.requesty.ai/v1"
   )
   print("✓ Client configured")
else:
   print("✗ API key not found")Offerto da

Se vedi entrambe le spunte, sei pronto per fare la tua prima richiesta.

Prime mosse con Requesty: la tua prima chiamata API

Con l’ambiente configurato e la chiave API pronta, puoi effettuare la prima chiamata API. Requesty funziona come sostituzione immediata dell’SDK di OpenAI. Se hai già usato OpenAI, ti sembrerà familiare. L’unica differenza è puntare il client al router di Requesty.

Ecco come impostare il client:

import os
from openai import OpenAI
from dotenv import load_dotenv

load_dotenv()

client = OpenAI(
   api_key=os.getenv("REQUESTY_API_KEY"),
   base_url="https://router.requesty.ai/v1"
)Offerto da

Quel parametro base_url è ciò che instrada le richieste tramite Requesty invece che direttamente verso OpenAI. Puoi testarlo con una chiamata a GPT-5:

response = client.chat.completions.create(
   model="openai/gpt-5",
   messages=[
       {"role": "user", "content": "Explain recursion in one sentence"}
   ]
)

print(response.choices[0].message.content)Offerto da

Output:

Recursion is a technique where a function solves a problem by calling itself on smaller inputs until it reaches a base case.Offerto da

Il parametro model usa il formato provider/model-name. Qui è openai/gpt-5, che accede all’ultimo modello di OpenAI con funzionalità di ragionamento native e prestazioni migliorate nei task di coding e matematica. A parte il formato del modello e la base URL, l’SDK funziona in modo identico a quello di OpenAI.

Nota: Ogni chiamata API ha un costo. Requesty aggiunge un markup del 5% rispetto al prezzo base del provider, quindi GPT-5 costa leggermente di più tramite Requesty rispetto a chiamare direttamente OpenAI. Paghi per affidabilità, capacità di failover e dashboard unificato. Monitora l’uso tramite il dashboard di Requesty per tenere traccia della spesa.

L’oggetto di risposta contiene metadati utili oltre al contenuto del messaggio:

print(f"Model used: {response.model}")
print(f"Total tokens: {response.usage.total_tokens}")
print(f"Response: {response.choices[0].message.content}")Offerto da

Output:

Model used: gpt-5-2025-08-07
Total tokens: 108
Response: Recursion is a technique where a function solves a problem by calling itself on smaller inputs until it reaches a base case.Offerto da

Il conteggio dei token aiuta a monitorare i costi, dato che la tariffazione è tipicamente per token.

Passa a un provider diverso cambiando il nome del modello:

response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "user", "content": "Explain recursion in one sentence"}
   ]
)

print(f"Claude says: {response.choices[0].message.content}")Offerto da

Output:

Claude says: Recursion is a programming technique where a function calls itself to solve a problem by breaking it down into smaller, similar subproblems until it reaches a base case that stops the repetition.Offerto da

Claude 4 offre finestre di contesto estese e un ragionamento migliorato che lo rendono particolarmente forte per l’analisi di codice complesso. Tutti i modelli disponibili seguono lo stesso pattern provider/model-name:

# OpenAI GPT-4o
model = "openai/gpt-4o"

# Anthropic Claude
model = "anthropic/claude-sonnet-4"
Wrap your API calls in error handling before moving to production:
try:
   response = client.chat.completions.create(
       model="openai/gpt-5",
       messages=[{"role": "user", "content": "Hello!"}]
   )
   print(response.choices[0].message.content)
except Exception as e:
   print(f"Error: {e}")Offerto da

Questo intercetta timeout di rete, chiavi API non valide o modelli non disponibili senza mandare in crash l’applicazione.

Streaming per risposte in tempo reale in Requesty

Quando richiedi una risposta lunga, lo schermo si blocca per alcuni secondi mentre il modello genera migliaia di token. Poi tutto arriva in una volta sola. 

Gli utenti fissano uno schermo vuoto, chiedendosi se stia succedendo qualcosa.

Lo streaming risolve il problema inviando porzioni di risposta man mano che il modello le genera, così gli utenti vedono comparire le parole progressivamente, proprio come in ChatGPT. Questo rende le applicazioni reattive, soprattutto per risposte più lunghe come spiegazioni, generazione di codice o scrittura creativa.

Per abilitare lo streaming in Requesty, imposta il parametro stream su True:

response = client.chat.completions.create(
   model="openai/gpt-4o",
   messages=[
       {"role": "user", "content": "Explain recursion like I'm five years old"}
   ],
   stream=True
)

for chunk in response:
   if chunk.choices[0].delta.content is not None:
       print(chunk.choices[0].delta.content, end="", flush=True)Offerto da

La risposta arriva in streaming parola per parola:

Okay! Imagine you have a big basket of toys, and you're trying to find your favorite teddy bear. 
But instead of looking through the whole basket all at once, you call your little sibling and say, 
"Can you look in here and find my teddy bear? If you see more baskets inside, ask someone else to help in the same way!" …Offerto da

Il parametro stream=True trasforma la risposta da un singolo oggetto a un iteratore che produce chunk. Ogni chunk contiene un pezzo di testo in delta.content. Il parametro end="" evita le nuove righe tra i chunk e flush=True forza la visualizzazione immediata invece del buffering.

Le applicazioni in produzione spesso hanno bisogno sia dell’esperienza in streaming sia del testo completo per logging o analisi. Una funzione di supporto gestisce entrambe le cose:

def stream_and_capture(model, messages):
   """Stream response to user while capturing complete text."""
   response = client.chat.completions.create(
       model=model,
       messages=messages,
       stream=True
   )
  
   complete_text = ""
  
   for chunk in response:
       if chunk.choices[0].delta.content is not None:
           text = chunk.choices[0].delta.content
           complete_text += text
           print(text, end="", flush=True)
  
   print()  # Final newline
   return complete_text

# Use it
full_response = stream_and_capture(
   "anthropic/claude-sonnet-4",
   [{"role": "user", "content": "Write a haiku about debugging code at 3 AM"}]
)

print(f"\nCaptured {len(full_response)} characters")Offerto da

Output:

Blinking cursor waits
Coffee cold, eyes burning red,
One missing bracket.

Captured 74 charactersOfferto da

Lo streaming non è sempre la scelta giusta. Per risposte brevi o output strutturati come dati JSON, le richieste normali sono più semplici e veloci, perché l’overhead di elaborare i chunk supera il beneficio per l’esperienza utente.

Gli stream possono fallire a metà a causa di problemi di rete, rate limit o outage dei provider. Incapsula il codice di streaming in una gestione degli errori di base:

try:
   response = client.chat.completions.create(
       model="openai/gpt-4o",
       messages=[{"role": "user", "content": "Explain quantum entanglement in one sentence"}],
       stream=True
   )
  
   for chunk in response:
       if chunk.choices[0].delta.content is not None:
           print(chunk.choices[0].delta.content, end="", flush=True)
except Exception as e:
   print(f"\nError: {e}")Offerto da

Se uno stream fallisce, intercetti l’errore e puoi riprovare manualmente o effettuare il fallback su un modello diverso.

Failover automatici per l’affidabilità

Le applicazioni in produzione non possono permettersi downtime. Quando OpenAI raggiunge i rate limit nelle ore di punta, i tuoi utenti vedono errori. Quando Anthropic ha un outage, il tuo chatbot smette di funzionare. Questi guasti sono inevitabili quando dipendi da provider esterni.

Requesty gestisce la cosa tramite failover automatici. Quando il tuo modello primario fallisce, Requesty passa al backup in meno di 50 millisecondi.

Cosa sono i failover e perché contano

Un sistema di failover rileva quando il tuo modello primario non è disponibile e reindirizza la richiesta a un modello di backup senza necessità di modificare il codice. Il rilevamento avviene automaticamente quando un provider restituisce un errore, raggiunge i rate limit o va in timeout. Requesty quindi instrada la richiesta al modello successivo nella catena configurata.

Requesty garantisce un uptime del 99,99% tramite questo sistema. Sono circa 4 minuti di downtime al mese al massimo, contro potenzialmente ore se usi un singolo provider senza opzioni di backup.

Tre tipi di policy controllano il funzionamento dei failover:

• Fallback Chain: prova i modelli in ordine. Se il primo fallisce, prova il secondo. Se fallisce anche quello, prova il terzo. Funziona bene quando hai un modello preferito ma vuoi opzioni di backup.
• Load Balancing: suddividi il traffico tra più modelli in percentuale. Potresti inviare il 70% a GPT-5 e il 30% a Claude Sonnet 4 per ridurre il carico su un singolo provider. Quando un modello non è disponibile, Requesty instrada automaticamente tutto il traffico verso i modelli funzionanti.
• Latenza: instrada le richieste verso il modello che risponde più rapidamente. Requesty misura i tempi di risposta e invia il traffico all’opzione con latenza più bassa. Questo ottimizza la velocità rispetto ai costi.

La maggior parte dei team parte con Fallback Chain perché è prevedibile. Ottieni il tuo modello preferito quando è disponibile e backup automatici quando non lo è.

Configurare le catene di fallback

La configurazione dei failover avviene nel dashboard di Requesty. Vai alla sezione API Keys, poi clicca su Policies. Crea una nuova policy Fallback Chain. Vedrai un form in cui aggiungere i modelli in ordine di preferenza.

Ecco una catena di esempio che bilancia qualità, costo e disponibilità:

1. openai/gpt-5

2. anthropic/claude-sonnet-4

3. deepseek/deepseek-r1:free

Questa catena prova prima GPT-5 perché è veloce e capace. Se fallisce, prova Claude Sonnet 4 per una qualità simile. Se entrambi i modelli premium sono giù, fa fallback su DeepSeek R1, che è gratuito e quasi sempre disponibile.

Una volta salvata questa policy e associata alla tua chiave API, i failover avvengono senza modifiche al codice:

response = client.chat.completions.create(
   model="openai/gpt-5",
   messages=[{"role": "user", "content": "Explain how DNS works"}]
)

print(f"Model used: {response.model}")
print(response.choices[0].message.content)Offerto da

Il campo response.model mostra quale modello ha effettivamente gestito la richiesta. Il dashboard tiene traccia della frequenza dei failover così puoi vedere quando vengono usati i modelli di backup.

Output:

Model used: gpt-5-2025-08-07
DNS (Domain Name System) translates human-readable website addresses like "google.com" into IP addresses (like 142.250.80.46) that computers use to locate and connect to servers. This translation happens through a hierarchical system of DNS servers that cache and distribute this information globally for fast lookups.Offerto da

Se tutti i modelli nella tua catena falliscono, Requesty restituisce un errore dopo aver provato ciascuno. Riceverai una risposta di errore standard dell’API che indica che nessun modello era disponibile. È raro ma possibile durante outage diffusi.

Alcune linee guida funzionano bene quando costruisci catene di failover:

• Usa provider diversi: se metti openai/gpt-5 e openai/gpt-4o nella catena, potrebbero andare giù entrambi durante un outage di OpenAI. Mescola i provider per una migliore affidabilità.
• Ordina prima per qualità, poi per costo: metti il tuo miglior modello per primo. Se non è disponibile, prova il secondo migliore. L’ultimo fallback dovrebbe essere l’opzione più affidabile, anche se di qualità inferiore o gratuita.
• Includi almeno tre modelli: un solo backup significa due punti di guasto. Tre o più modelli offrono una copertura migliore.
• Testa la tua catena: effettua alcune richieste e controlla il dashboard di analytics per vedere quali modelli gestiscono il traffico. Così confermi che la policy funziona.

Mentre LiteLLM richiede una configurazione YAML manuale per i failover, Requesty gestisce tutto tramite le policy nel dashboard.

Caching per ridurre i costi

Ripetere la stessa query più e più volte costa. Se hai un chatbot per la documentazione che risponde sempre alle stesse domande, o un assistente di coding con lo stesso system prompt per ogni richiesta, paghi il prezzo pieno ogni volta. La cache risolve riutilizzando le parti del prompt che non cambiano.

Alcuni provider supportano nativamente il caching dei prompt. Anthropic e Gemini permettono di mettere in cache le porzioni invariate dei prompt e riutilizzarle tra le richieste. Questo riduce i costi quando hai schemi ripetuti perché paghi il prezzo pieno solo per le parti nuove.

Quando invii una richiesta con un lungo system prompt, il provider memorizza quel prompt nella sua cache. Alla richiesta successiva con lo stesso system prompt, lo recupera dalla cache invece di rielaborarlo. Paghi una tariffa ridotta di lettura cache invece del costo pieno di elaborazione.

Passa auto_cache nel campo extra_body con un oggetto requesty annidato:

response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": "You are a helpful documentation assistant. You answer questions about Python's asyncio library based on the official docs. Be concise and include code examples."},
       {"role": "user", "content": "How do I create a basic event loop?"}
   ],
   extra_body={
       "requesty": {
           "auto_cache": True
       }
   }
)

print(response.choices[0].message.content)Offerto da

Il system prompt resta uguale tra le richieste. Con auto_cache: True, Anthropic lo mette in cache dopo la prima richiesta. Le richieste successive riutilizzano il prompt in cache ed elaborano solo la domanda dell’utente.

Il parametro di caching accetta tre valori:

• True: abilita la cache per questa richiesta
• False: ignora esplicitamente la cache anche se il provider la supporta (utile per dati sensibili o contenuti time-sensitive in cui vuoi garantire un’elaborazione fresca)
• Omettilo: usa il comportamento predefinito (niente cache a meno che non sia configurata globalmente)

Attualmente solo Anthropic e Gemini supportano il caching dei prompt. Usare auto_cache con altri provider ricadrà silenziosamente sull’elaborazione normale senza errori.

Quando usare la cache

La cache funziona al meglio quando hai system prompt lunghi che restano invariati tra le richieste. Bot di documentazione e assistenti di coding sono buoni esempi. Anche bot per FAQ e sistemi di supporto clienti beneficiano quando gli utenti fanno domande simili. Le knowledge base con grandi documenti di riferimento che non cambiano sono un altro caso d’uso forte.

Evita la cache quando ogni richiesta necessita di dati aggiornati. App meteo e prezzi azionari rientrano in questa categoria. Le raccomandazioni personalizzate con prompt unici per ogni utente non trarranno beneficio. Il monitoraggio in tempo reale e i feed live cambiano troppo frequentemente per guadagnare dalla cache.

Questo esempio mostra un chatbot di documentazione per una libreria Python. Il system prompt include l’intero riferimento API. Gli utenti fanno domande diverse, ma il system prompt resta lo stesso:

# Simulate a long API documentation string
long_api_documentation = """
Python AsyncIO Library Reference:
- asyncio.run(): Execute async functions
- asyncio.create_task(): Schedule coroutines
- asyncio.gather(): Run multiple tasks
... (this continues for 5,000+ tokens)
"""

# First request - cache miss, pays full price
response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": long_api_documentation},
       {"role": "user", "content": "How do I authenticate?"}
   ],
   extra_body={"requesty": {"auto_cache": True}}
)

print(f"Tokens: {response.usage.total_tokens}")
# Output: Tokens: 5,247 (full processing)Offerto da

La seconda richiesta con lo stesso system prompt colpisce la cache:

# Second request - cache hit, reduced cost
response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": long_api_documentation},
       {"role": "user", "content": "What are rate limits?"}
   ],
   extra_body={"requesty": {"auto_cache": True}}
)

print(f"Tokens: {response.usage.total_tokens}")
# Output: Tokens: 312 (only new content processed, 5,000 tokens served from cache)Offerto da

Le tariffe di lettura cache riducono le spese dal 50 al 90% per le parti in cache.

Controlla il tasso di cache hit nel dashboard di Requesty nella sezione Analytics. Se è sotto il 40%, i tuoi prompt cambiano troppo spesso per beneficiare della cache. 

Cerca schemi in cui puoi standardizzare i system prompt o estrarre il contenuto variabile nei messaggi utente. Il dashboard mostra anche i risparmi totali dalla cache, suddivisi per provider e modello, così puoi vedere esattamente dove gli sforzi di ottimizzazione stanno dando frutti.

Tracciamento dei costi e analytics di Requesty

Il tuo dashboard al momento è quasi vuoto. Hai fatto qualche richiesta di test, speso forse 0,10 $. Non c’è ancora molto da analizzare. Questa sezione ti mostra cosa impostare ora e cosa diventa utile più avanti quando passi alla produzione.

Impostare limiti di spesa è una buona pratica anche per i test. Vai alla sezione API Keys nel tuo dashboard, clicca sulla tua chiave e trova “API Limits”. Imposta una soglia di budget mensile di 5 $. Requesty ti avviserà al 50%, 75% e 90% di quel limite. Per una protezione più rigida, imposta un cap di utilizzo che blocca tutte le richieste quando raggiungi il limite. Questo previene incidenti durante i test e ti protegge in produzione.

Con la crescita dell’uso, Requesty traccia cinque metriche chiave:

• Uso dei token: quanti token consuma ogni richiesta
• Tracciamento dei costi: spesa esatta per modello e provider
• Metriche di latenza: tempi di risposta P50, P95, P99
• Prestazioni della cache: tassi di hit che mostrano i risparmi
• Frequenza dei failover: quanto spesso sono stati usati i modelli di backup

Dopo qualche settimana di traffico in produzione, queste metriche mostrano pattern utili all’ottimizzazione. Usa il dashboard per individuare workflow costosi e passare a modelli più economici, scovare query ripetute e abilitare la cache con auto_cache: true, e monitorare i pattern di failover per regolare le catene di fallback. Un chatbot di documentazione ha ridotto i costi da 500 a 200 $ al mese abilitando la cache dopo che il dashboard ha mostrato che il 70% delle query era identico.

Monitoraggio, scalabilità e best practice operative diventano cruciali quando passi dal prototipo alla produzione. LLMOps copre l’intero ciclo di vita della gestione dei large language model in ambienti di produzione, incluse strategie di ottimizzazione dei costi che completano l’analytics integrato di Requesty.

Conclusione

Hai visto come Requesty funzioni come gateway unificato verso 300+ modelli AI tramite una singola API. Il setup è semplice: installa l’SDK di OpenAI, puntalo alla base URL di Requesty e sei connesso. Da lì, lo streaming offre risposte progressive, le catene di failover garantiscono l’uptime anche quando i provider falliscono e la cache può dimezzare i costi quando gestisci prompt ripetuti.

La scelta tra Requesty, LiteLLM e OpenRouter dipende dalle tue priorità. Se ti serve un’infrastruttura gestita con failover automatici e analytics integrati, Requesty si prende carico della complessità. I team a loro agio con il self-hosting e che vogliono controllo granulare possono usare l’approccio open-source di LiteLLM. OpenRouter offre un accesso unificato di base quando ti va bene selezionare i modelli manualmente e non ti servono policy di routing avanzate.

Inizia configurando una catena di fallback con tre modelli di provider diversi, poi abilita la cache sulle richieste con system prompt ripetuti. Per casi d’uso più avanzati, esplora le capacità di ragionamento di Claude Sonnet 4 o applica le pratiche LLMOps per i deployment in produzione.