Routing dei provider OpenRouter: spiegazione e aggiornamento di ottobre 2026

Dal 28 ottobre 2026 il routing predefinito di OpenRouter funziona in modo diverso: il tempo al primo token è sceso del 16,9%, gli eventi 429 sono diminuiti complessivamente del 67%, ma le richieste costano circa il 6% in più. Il routing automatico può ancora spostare silenziosamente il traffico verso un provider più costoso: ecco perché il compromesso conta più del dato principale.

Il nuovo router di OpenRouter non sceglie più semplicemente il prezzo più basso per i token di input. Stima quanto costa ottenere una buona risposta — prezzo, attesa e retry compresi — e invia ogni richiesta al provider con il Routing Cost più basso.

Il verdetto in 30 secondi, numeri alla mano

Il routing dei provider OpenRouter ora ottimizza il Routing Cost, non il prezzo dei token del prompt. La modifica si applica automaticamente quando una richiesta non imposta esplicitamente provider.sort, provider.order, provider.only o provider.ignore, e riguarda circa il 77% del traffico diretto verso modelli serviti da più provider, secondo l'annuncio di OpenRouter.

I risultati arrivano da un test switchback durato una settimana, condotto su 24 milioni di richieste e 103 miliardi di token di input, divise equamente tra il vecchio e il nuovo router.

\*Le percentuali sulle richieste e le riduzioni nel numero di eventi sono entrambe riportate nell'annuncio: il 67% e il 47% si riferiscono al totale degli eventi 429 e dei retry, non al rapporto tra le percentuali di richieste coinvolte, perché una singola richiesta può generare più errori.

Secondo l'annuncio, il TTFT p95 misurato dal chiamante è passato da 6.032 ms a 4.504 ms, il p50 dell'intera richiesta è sceso da 4,00 s a 3,24 s e il tempo sprecato nei tentativi falliti è diminuito da 349 ms a 242 ms per richiesta.

In sintesi: il nuovo comportamento predefinito è la scelta giusta per chat interattive e agenti, se si può accettare un costo superiore di circa il 6%; per grandi job batch, dove ogni centesimo pesa, conviene invece tornare al routing basato solo sul prezzo.

Routing Cost spiegato senza tecnicismi inutili

Per ogni provider, il Routing Cost risponde a due domande: quanto costa un tentativo e con quale frequenza va a buon fine. L'esempio di OpenRouter è questo: un tentativo da $0.40 più $0.60 di attesa fanno $1.00; dividendo il risultato per una probabilità di successo dell'80% si arriva a $1.25 per risposta valida. Il traffico tende quindi a concentrarsi sul costo più basso.

Il calcolo usa tre componenti:

1. Prezzo effettivo, non quello di listino. OpenRouter stima i token di input e output sulla base del traffico recente, poi applica il reale tasso di cache hit e i prezzi dei token di ciascun provider. L'esempio dell'annuncio: 40K input non in cache a $2.00/M ($0.080), più 60K input in cache a $0.50/M ($0.030), più circa 4K output a $8.00/M ($0.032), per un totale di $0.142. Un provider con input economici ma token cached o output costosi perde qui il suo vantaggio.
2. Il tempo di attesa convertito in dollari. Il throughput è calcolato end-to-end in token di output al secondo e include il tempo al primo token (esempio: 5 s prima del primo token più 500 token nei 5 s successivi = 50 tok/s). Il router converte l'attesa usando un valore per modello, basato sui costi e sulle velocità tipiche dei provider. Il tempo al primo token pesa di più perché le catene di tool call degli agenti devono aspettarlo a ogni passaggio.
3. Il costo dei malfunzionamenti. Un 429 significa che il provider ha rifiutato la richiesta: bisogna attendere il rifiuto e poi inviarla di nuovo altrove (esempio: 2.50 di attesa più una penalità × un tasso dello 0,4% aggiunge 0.01). Gli errori di affidabilità hanno una penalità maggiore, circa 8 volte superiore: un tasso di errore dell'1% aumenta il costo di circa l'8%. I provider molto peggiori dei concorrenti smettono di ricevere traffico fino al recupero. Al momento la qualità verifica soprattutto che le tool call siano ben formate (un tasso del 95% aumenta il costo di circa il 5%); i provider segnalati vengono limitati al traffico di test, secondo l'annuncio.

Due meccanismi impediscono che tutto il traffico finisca su un solo vincitore, come spiega l'annuncio: ogni provider continua a ricevere una piccola quantità di richieste, così il recupero resta visibile, mentre il router riduce il traffico verso i provider in difficoltà, impara i limiti di capacità di ciascuno e distribuisce altrove l'eccedenza.

Perché il routing predefinito può ancora creare problemi in produzione

Le segnalazioni degli utenti mostrano quattro problemi ricorrenti che il semplice prezzo per token non riesce a catturare.

I passaggi delle tool call possono rompere gli schemi

Per me è stato il passaggio intermedio durante la richiesta a rompere davvero le tool call, non il prezzo indicato per un singolo provider.

— u/Michael_Jeffords, discussione r/openrouter sui provider da evitare

Oggi il punteggio di qualità si basa soprattutto sulle tool call ben formate e sui flag relativi all'accuratezza dei benchmark, come indicato nell'annuncio. Un cambio di provider nel mezzo della conversazione può comunque modificare la quantizzazione o il comportamento in caso di rifiuto, perché la qualità varia da provider a provider e alcuni servono varianti quantizzate in modo più aggressivo.

La perdita della cache fa lievitare il conto

Una discussione documenta contesti da circa 700K token in cui richieste cached attese a $0.20 sono state fatturate quasi $2.00 dopo un cambio di provider: è il meccanismo alla base del problema descritto come «pagare 10-32 volte di più a causa di una cache difettosa». Il nuovo router mantiene una conversazione sul provider originale finché la cache è calda e seleziona algoritmicamente il provider solo per la prima richiesta, secondo il routing cache-aware di OpenRouter; tuttavia, il vincolo salta se il fallback porta a un altro provider. Gli utenti che hanno risolto il problema hanno fissato un provider usando sessioni persistenti.

Credo che sia un difetto piuttosto fondamentale di OR il fatto di dover configurare tutto manualmente in anticipo.

— u/welcome_to_milliways, discussione r/openrouter sulla cache non funzionante

Fallback costosi e invisibili

Un report di produzione ha rilevato che una parte del traffico passava silenziosamente da Sonnet a Opus, a un prezzo indicato circa 5 volte superiore. L'uptime restava verde, mentre la spesa complessiva oraria saliva da $184/hr a $412/hr, secondo @CarbonOnX. Il nuovo router rende esplicito questo compromesso: un provider più rapido e affidabile può legittimamente superare quello più economico.

I 429 arrivano anche sugli account a pagamento

Un saldo OpenRouter a pagamento non aumenta la capacità disponibile a monte, come osservano gli utenti in questa discussione sui 429. Un 429 riflette il pool condiviso di quel provider per il modello in questione. Nei test, la ricostruzione ha ridotto gli eventi 429 del 67%, ma in produzione la soluzione resta fissare o ignorare il provider che sta applicando il rate limit. Per iniziare, consulta come risolvere gli errori 429 di OpenRouter e, per il vecchio comportamento predefinito basato sul prezzo, la guida a OpenRouter Auto Router.

Tre configurazioni di routing che reggono davvero in produzione

La scelta dipende dalla priorità: velocità senza interventi manuali, limiti di costo rigidi o comportamento deterministico. Tutte usano lo stesso oggetto provider: provider.order bypassa la nuova logica e prova i provider nell'ordine esatto; provider.only e provider.ignore filtrano i candidati, lasciando poi al nuovo algoritmo la scelta tra quelli rimasti; qualsiasi provider.sort esplicito (price, throughput, latency) sostituisce il nuovo criterio.

1. Mantieni il nuovo comportamento predefinito (chat interattive e agenti)

Non serve modificare il codice. È la configurazione adatta a chat rivolte agli utenti e agenti con più passaggi, dove ogni tool call deve attendere il primo token: si accetta un costo superiore di circa il 6% in cambio di latenza e retry migliori. Per una settimana registra il provider che ha servito ogni richiesta (il dato è restituito nella risposta API e nella pagina delle attività), insieme a TTFT p50 e tasso di 429. Se la quota di 429 resta vicina al nuovo valore di riferimento, circa il 4%, e il tasso di cache hit rimane stabile, puoi mantenere questa configurazione; se un provider concentra gli errori o le cache hit crollano, passa alla configurazione 3.

2. Blocca il percorso più economico (job batch e attività con budget rigido)

Ci sono tre modi per privilegiare il prezzo quando il costo conta più della velocità:

{ "provider": { "sort": "price" } }

In alternativa, aggiungi :floor allo slug del modello (meta-llama/llama-4-maverick:floor) oppure imposta il sort predefinito su price nelle impostazioni dell'account, come indicato nelle FAQ dell'annuncio. Attenzione: :floor include anche gli endpoint flex-tier, mentre il semplice sort non lo fa, secondo la guida al routing di OpenRouter.

Abbinalo a un tetto massimo:

{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }

È una buona scelta per prompt lunghi, output brevi e retry economici.

3. Fissa un provider stabile (produzione con cache o tool call)

Fissa il provider quando correttezza, cache hit o requisiti di conformità contano più dell'ottimizzazione richiesta per richiesta:

{
  "provider": {
    "order": ["deepinfra", "together"],
    "allow_fallbacks": true,
    "require_parameters": true
  }
}

require_parameters evita soltanto gli endpoint privi dei parametri obbligatori per la richiesta; non garantisce tool call o comportamento degli schemi identici tra provider diversi. Usa order con allow_fallbacks: false solo per esigenze di conformità o scenari BYOK in cui un'interruzione del servizio è preferibile al ricorso a un provider non approvato. Nella maggior parte delle applicazioni conviene consentire i fallback, restringere la scelta con only/ignore e passare un session_id stabile per riutilizzare la cache calda (sticky routing). Se un provider è instabile, bloccalo nelle regole di protezione e confronta le API del provider diretto: diversi utenti riferiscono che il passaggio diretto ha eliminato lentezza e problemi di cache una volta scelto il modello (discussione di esempio).

Il routing automatico è migliorato. Non sostituisce però il pinning quando un passaggio sbagliato costa più di una settimana di prezzi per token leggermente superiori.

FAQ

Devo modificare il codice per usare il nuovo routing?

No. Le richieste senza sort, order, only o ignore espliciti per il provider usano automaticamente il nuovo router.

Come mantengo il routing basato solo sul prezzo?

Imposta provider.sort su "price", aggiungi :floor oppure imposta il sort predefinito dell'account su price.

Il nuovo routing sovrascrive l'ordine dei miei provider?

No. order lo bypassa; only/ignore filtrano prima, poi il nuovo algoritmo sceglie tra i candidati rimasti.

Il nuovo routing costerà di più?

La tabella del verdetto è chiara: nei test, +6,0% per 1.000 richieste e +7,3% per M di token.

Come posso vedere quale provider ha effettivamente servito la richiesta?

Controlla il campo provider nella risposta API e la pagina delle attività, come indicato nella documentazione OpenRouter.

Perché ricevo ancora 429 su un account a pagamento?

Il problema sono i limiti del pool condiviso a monte, non il saldo dell'account. Fissa o ignora il provider che sta applicando il rate limit.