OpenRouter instrada le richieste per risparmiare: ma lo stesso endpoint può dare risposte diverse

Lo stesso endpoint di OpenRouter può comportarsi in modi diversi da una chiamata all’altra perché la richiesta finisce su provider differenti. Mohamed Moustafa lo segnala come rischio concreto per chi usa il routing automatico del servizio¹.

OpenRouter dichiara che “gestisce automaticamente i fallback e sceglie l’opzione più conveniente per ogni richiesta”. L’idea è chiamare un unico endpoint per un modello e farsi instradare verso il provider di backend “migliore” disponibile in quel momento¹. Questo elimina la necessità di scegliere un provider a priori per ogni invocazione.

Qui nasce il problema. Provider diversi usano software di serving differenti, con ottimizzazioni e impostazioni proprie. Ne consegue che lo stesso endpoint OpenRouter può servire richieste che si comportano in modo diverso, perché dietro cambiano le condizioni di esecuzione tra un provider e l’altro¹.

La discrepanza tocca anche capacità precise. Alcuni provider, pur esponendo modelli “vision”, non offrono in pratica la funzione di visione. In parallelo, l’opzione di “reasoning effort” può venire elaborata in modo diverso a seconda del provider. Due chiamate allo stesso endpoint, ma su provider differenti, possono quindi mostrare differenze nel modo in cui il modello elabora l’input e applica le opzioni, non per il contenuto della richiesta ma per le scelte lato serving¹.

C’è un modo per limitare la variabilità. Si può controllare il provider verso cui instradare la richiesta usando l’opzione provider.only. Così si forza OpenRouter a usare un singolo provider per quell’endpoint, evitando il rimpallo automatico tra alternative¹.

Per sapere chi è disponibile su un modello specifico, esiste un metodo dedicato. L’endpoint /endpoints restituisce l’elenco dei provider disponibili per uno specifico model ID. Questo consente di vedere in anticipo le opzioni e decidere se bloccare il routing su un nome preciso tramite provider.only¹.

Il punto, sottolinea Moustafa, è che la promessa di un endpoint unico comporta compromessi sul comportamento. Non basta il nome del modello per prevedere la risposta: contano anche il software di serving e le impostazioni del provider a cui OpenRouter instrada la chiamata. Se i provider differiscono per ottimizzazioni e settaggi, anche le risposte possono differire a parità di endpoint¹.

Il post che riporta queste note è dell’11 settembre 2026, nel link blog di Simon Willison. Il messaggio è netto: l’instradamento con fallback e scelta dell’opzione più conveniente semplifica le chiamate, ma può introdurre differenze non banali tra esecuzioni. Per chi ha bisogno di coerenza tra invocazioni, la strada è usare provider.only e consultare /endpoints per scegliere in modo esplicito il provider su cui fissarsi¹.

Questo richiede una scelta progettuale: accettare l’instradamento automatico “al provider migliore” per ogni chiamata, oppure limitare il routing a un solo provider per stabilizzare il comportamento, sapendo che le differenze tra provider esistono e incidono sul risultato osservato allo stesso endpoint¹.