OpenRouter, la guida: scegliere i modelli e contenere i costi

Per usare l’intelligenza artificiale in azienda non serve sempre il modello più potente, né conviene affidare tutte le attività allo stesso.

Classificare le email dei clienti, riassumere un contratto e scrivere codice richiedono capacità differenti. Un modello avanzato può essere necessario per risolvere un problema difficile, ma troppo costoso per migliaia di operazioni semplici.

Qui entra in gioco OpenRouter, una piattaforma (comprata da Stripe ad agosto) che sta acquisendo crescente importanza. Permette di scegliere modelli diversi secondo il compito, confrontandone qualità e prezzo, oppure di affidare questa decisione a un sistema automatico.

OpenRouter può scegliere automaticamente il modello in funzione della richiesta e della fascia di costo desiderata. Con l’Auto Router aggiornato il 10 agosto 2026, il sistema distingue attività come assistenza clienti, programmazione o ricerca e individua un modello usando segnali aggregati sull’impiego dei diversi sistemi nei sette giorni precedenti. La selezione tiene conto del livello di spesa impostato. Non garantisce però che ogni risposta sia la migliore o che il costo sia sempre il minimo assoluto: un’impresa deve verificare i risultati sui propri casi d’uso.

Il vantaggio è poter sperimentare e cambiare modello senza rifare ogni integrazione tecnica. OpenRouter dà accesso a modelli di OpenAI, Anthropic, Google, DeepSeek e altri fornitori attraverso un catalogo con prezzi e caratteristiche, una chat per provarli e un’unica interfaccia di programmazione (API) per collegarli ai software aziendali. Si può quindi fissare un modello specifico quando servono risultati stabili, oppure delegare la scelta a un sistema di instradamento quando le richieste sono differenti e il contenimento dei costi è prioritario.

Che cos’è OpenRouter e come funziona

OpenRouter è un intermediario software tra l’applicazione che fa una domanda e i sistemi che eseguono il modello AI. La richiesta arriva a OpenRouter e viene inoltrata a un modello selezionato dall’utente oppure scelto tramite una funzione di instradamento. La risposta torna nello stesso formato generale, con un’unica chiave di accesso e una contabilità centralizzata. La guida ufficiale Quickstart illustra l’endpoint API e i principali metodi di integrazione.

Occorre distinguere modello e provider. Il modello è il sistema che genera il testo, per esempio Claude Sonnet 5.5; il provider è il servizio che lo mette materialmente in esecuzione, e può coincidere con il suo produttore oppure essere un’altra infrastruttura autorizzata. OpenRouter può instradare una richiesta dello stesso modello attraverso provider diversi, in base alle opzioni e alla disponibilità. La distinzione conta perché prestazioni, prezzi di alcune varianti e politiche di conservazione dei dati possono variare fra gli endpoint.

Quale funzione di OpenRouter usare per ogni esigenza

Funzioni e limiti descritti nelle guide ufficiali e nelle regole di fallback di OpenRouter.

Perché un’impresa dovrebbe usarlo e quando può farne a meno

Il primo vantaggio aziendale è poter usare la capacità di un modello dove serve, senza pagarla indiscriminatamente per tutte le richieste. Un servizio clienti può ricevere migliaia di domande ripetitive, che un modello economico riesce a gestire, ma anche reclami complessi, per i quali potrebbe essere necessario un modello più affidabile. Con OpenRouter l’impresa può associare manualmente un modello a ciascun processo oppure ricorrere ad Auto Router per scegliere in base al contenuto della singola richiesta. Il risparmio effettivo va misurato sulle risposte corrette, non soltanto sui token consumati.

Il secondo vantaggio riguarda l’integrazione tecnica e la continuità del servizio. Se un prodotto deve gestire più modelli, l’applicazione può chiamare un unico endpoint e modificare l’identificativo del modello quando è necessario. OpenRouter supporta anche meccanismi di fallback in caso di errore di un provider o di un modello. Ciò evita di costruire da zero parte della logica di instradamento, ma il passaggio a un altro modello può cambiare contenuto, formato e tempi di risposta: il risultato va sempre collaudato.

Non è necessariamente la scelta più economica o più semplice per tutti. Un’impresa che usa stabilmente un solo modello, ha già un contratto diretto soddisfacente e non richiede percorsi alternativi può preferire mantenere l’integrazione con il produttore. OpenRouter aggiunge un soggetto nel flusso tecnico e nella gestione amministrativa; chi tratta informazioni riservate deve verificarne gli accordi, il ruolo dei fornitori di inferenza e le condizioni di trasferimento dei dati.

Come usare OpenRouter senza scrivere codice

1. Creare un account e aprire la chat

Si comincia da OpenRouter, creando un account e aprendo la sezione Chat. Per fare una prima prova non è necessario sviluppare un’applicazione: si sceglie un modello disponibile e si formula una richiesta come in un normale chatbot. Il piano gratuito comprende modelli gratuiti con limiti d’uso; nella pagina Pricing OpenRouter indica 50 richieste al giorno per il livello Free, mentre i modelli a pagamento richiedono crediti.

2. Cercare il modello adatto e leggere il prezzo

In Models si può partire dal tipo di lavoro: elaborazione di testi, comprensione di immagini, programmazione o altre modalità. Non basta ordinare per prezzo più basso. Per esempio, un modello che deve leggere un documento illustrato deve accettare immagini in input; uno chiamato da un gestionale deve supportare i parametri richiesti dal software. Nella scheda del modello si controllano il prezzo per milione di token in ingresso e in uscita, la finestra di contesto e i provider disponibili.

3. Provare lo stesso compito con modelli diversi

Prima di pagare un’integrazione conviene costruire un piccolo test con dieci o venti richieste rappresentative del lavoro reale, prive di dati personali o segreti commerciali. Per un’attività di sintesi, si può chiedere: «Riassumi questo testo in cinque punti, cita i passaggi che sostengono ogni affermazione e segnala ciò che non si può stabilire dal documento». Si ripete la prova con gli stessi materiali e gli stessi criteri di valutazione, annotando errori, omissioni, tempo di risposta e spesa. Il numero proposto serve a iniziare, non costituisce un campione sufficiente per validare l’uso in produzione.

4. Creare una chiave API e fissare un tetto di spesa

Se il test funziona e occorre collegare OpenRouter a un sito, a un agente o a un’applicazione, si passa a Settings → API Keys. Una chiave API è la credenziale che autorizza il software a consumare il credito dell’account. Va creata per il progetto, conservata in un sistema per i segreti e mai pubblicata in una pagina web, in un repository o in uno screenshot. Dove previsto si applica un limite di spesa alla chiave; per i team, budget e guardrail permettono di limitare anche modelli, provider e importi.

5. Collegare un programma: la prima chiamata API

L’API impiega una richiesta HTTP indirizzata a un endpoint comune. Il software deve inviare la credenziale, l’identificativo del modello e i messaggi; non è necessario utilizzare un SDK proprietario. La documentazione OpenRouter riporta anche esempi in Python e TypeScript e la compatibilità con gli SDK OpenAI. Questa chiamata di esempio utilizza openrouter/free, il router dei modelli gratuiti.

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/free",
    "messages": [
      {"role": "user", "content": "Spiega in tre frasi che cos’è un token AI."}
    ]
  }'

Per passare a un modello specifico si sostituisce il valore di model, per esempio con openai/gpt-5.6-luna, verificandone prima costo e disponibilità. I nomi dei modelli sono identificativi tecnici: una differenza di carattere può generare un errore. L’elenco aggiornato si trova nel catalogo o nell’endpoint Models API. L’esempio è una configurazione da eseguire, non una chiamata realmente effettuata per la preparazione di questa guida.

Come far scegliere automaticamente il modello a OpenRouter

Per attivare la selezione automatica in un programma, al posto del nome di un modello specifico basta indicare openrouter/auto nella richiesta API. L’Auto Router classifica il lavoro, seleziona un modello idoneo fra quelli consentiti e inoltra la richiesta. La risposta riporta nel campo model il modello effettivamente usato: così il responsabile del progetto può verificarne costi e risultati. Non esiste una tariffa di inferenza fissa per il router: si paga il prezzo del modello selezionato, senza un supplemento specifico per questa funzione.

La scelta economica si regola con il parametro cost_tier. I valori disponibili sono low, medium, high, xhigh e max. Il predefinito low orienta la selezione verso modelli meno costosi ritenuti adeguati alla categoria del compito; max privilegia quelli più capaci e costosi. È una preferenza sulla fascia dei modelli, non un tetto monetario certo per singola chiamata. Un’azienda che ha un budget rigido deve aggiungere limiti di spesa e controllare i consumi.

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [
      {"role": "user", "content": "Classifica questo messaggio: richiesta di reso di un prodotto"}
    ],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

La distinzione è importante: la scelta automatica del modello e la scelta del provider non sono la stessa operazione. Con Auto Router può cambiare il modello impiegato per un’attività; con le preferenze di provider si può invece scegliere dove far eseguire un modello già determinato. Se un processo richiede prestazioni costanti, formati rigorosi o restrizioni contrattuali, è preferibile prima provare e delimitare i modelli ammessi. Le indicazioni tecniche di OpenRouter spiegano come applicare tali limitazioni.

Quanto costa OpenRouter: token, commissioni e una simulazione

OpenRouter fattura l’uso dei modelli sulla base dei token: si pagano separatamente quelli inviati al modello e quelli prodotti dalla risposta. Un prompt con documenti allegati può quindi costare più di una domanda breve, mentre una risposta lunga può pesare soprattutto sulla tariffa di output. I prezzi sono pubblicati per ciascun modello e possono cambiare anche in funzione del provider, della modalità di esecuzione, della cache e dei servizi aggiuntivi. La pagina di supporto precisa che i costi di inferenza sono trasferiti dai provider senza ricarico sulle tariffe dei modelli; la piattaforma applica invece una commissione all’acquisto dei crediti.

Alla data del 12 ottobre 2026, il listino OpenRouter indica una commissione di piattaforma del 5,5% per Standard e dell’8% per Business, oltre a condizioni differenti per i contratti Enterprise. Il modello Bring Your Own Key (BYOK), che usa credenziali già attive presso i fornitori, segue regole proprie: Standard e Business includono una soglia mensile senza commissioni pari a 25.000 dollari di costo di inferenza a listino, oltre la quale è indicata una commissione del 5%. Le imposte e gli eventuali costi accessori non sono inclusi nel confronto che segue.

Per rendere concreto il peso della scelta, ipotizziamo 1.000 richieste identiche, ognuna di 10.000 token inviati e 2.000 generati: nel complesso 10 milioni di token di input e 2 milioni di output. Applicando i prezzi standard esposti nelle schede di quattro modelli al momento della verifica, si ottengono i valori seguenti. È una simulazione di listino, non il risultato di un test sulle prestazioni o un preventivo garantito.

I listini di quattro modelli e la simulazione di spesa

Listini: pagine modello ufficiali OpenRouter (link per riga), consultate il 12 ottobre 2026. Simulazione di 1.000 chiamate identiche, 10.000 token di input e 2.000 di output per chiamata, costi arrotondati al centesimo; tariffe e disponibilità soggette a variazione.

Il costo teorico va quindi da 2,71 a 40 dollari per lo stesso volume di token. Non significa che i quattro modelli siano equivalenti: uno più economico potrebbe richiedere più tentativi o non raggiungere la qualità necessaria. Per valutare il prezzo di un processo aziendale bisogna misurare quanti compiti vengono completati correttamente al primo tentativo, non soltanto quanto costa una singola chiamata.

Routing e fallback: che cosa succede quando un provider non risponde

L’instradamento ha due livelli. Il fallback fra provider cerca un altro servizio in grado di eseguire lo stesso modello, mentre il fallback fra modelli sostituisce un modello con un altro. Il primo aiuta a fronteggiare errori e indisponibilità di un’infrastruttura; il secondo amplia le alternative ma può modificare in modo più evidente le risposte. La guida ai fallback spiega che un elenco di modelli alternativi viene tentato nell’ordine indicato in caso di errori, compresi i limiti di traffico e alcuni rifiuti di moderazione.

Per il provider si può lasciare la selezione automatica oppure impostare preferenze specifiche. Le opzioni :floor e :nitro privilegiano rispettivamente prezzo e velocità nei percorsi in cui sono supportate, come illustra la spiegazione ufficiale del routing. Diversamente da queste preferenze sul provider, Auto Router può cambiare il modello AI in base al tipo di richiesta e alla fascia di costo. La selezione è descritta nella sezione operativa precedente.

C’è anche un limite operativo: se un processo richiede un provider preciso per contratto, non basta avere un fallback disponibile. Occorre indicare i provider consentiti e disattivare il ripiego verso altri, altrimenti una richiesta potrebbe essere indirizzata a un’infrastruttura non prevista. E se un’applicazione deve produrre sempre dati strutturati, ogni modello candidato alla sostituzione va provato sul formato richiesto prima di abilitare il fallback.

Privacy, dati aziendali e trattamento nell’Unione europea

Un’unica API non rende automaticamente uniformi le regole sui dati. Secondo la documentazione sulla raccolta delle informazioni, OpenRouter non conserva di norma il contenuto dei prompt e delle risposte: il salvataggio dei testi e il loro utilizzo per migliorare il servizio sono opzioni da attivare espressamente, mentre i metadati delle chiamate vengono registrati. La richiesta, però, deve essere trasmessa al provider che esegue il modello, e quel provider può avere proprie condizioni di conservazione e utilizzo.

Nelle impostazioni di privacy dei provider si possono escludere i servizi che addestrano sui dati. Per applicazioni più restrittive, Zero Data Retention (ZDR) limita il routing agli endpoint che dichiarano di non conservare prompt e risposte. Il meccanismo ZDR può essere attivato per gruppi di modelli o singole richieste, ma non si estende automaticamente a strumenti esterni, come i servizi di ricerca collegati a una chiamata. Se non esiste un endpoint che rispetta i vincoli, la richiesta può fallire: è una limitazione intenzionale, utile a evitare instradamenti non autorizzati.

Per la localizzazione geografica, OpenRouter dichiara di offrire instradamento con trattamento in regione europea nei piani Business ed Enterprise, attraverso un endpoint regionale dedicato, come descrive nella guida In-Region Routing. La possibilità di selezionare un’area non sostituisce tuttavia le verifiche su contratto, soggetti coinvolti, trasferimenti, misure di sicurezza e basi giuridiche previste per il singolo trattamento. Prima di caricare dati di clienti o dipendenti in un servizio di prova è preferibile usare documenti sintetici o anonimizzati.

Come decidere se adottarlo in azienda

Per un progetto pilota la scelta può essere rapida: se lo scopo è confrontare modelli su un compito concreto, OpenRouter riduce il lavoro preliminare. Chi organizza il test deve però conservare le stesse richieste, annotare quale modello e quale provider le hanno elaborate e misurare errori, tempi e costo totale. Un confronto basato solo su qualche risposta brillante rischia di premiare risultati occasionali.

Quando il progetto diventa un servizio utilizzato da clienti o dipendenti, servono criteri più severi. La selezione deve tradursi in regole tecniche verificabili: modelli ammessi, budget, gestione e rotazione delle chiavi, formato dell’output, fallback approvati e politiche di trattamento dei dati. La dashboard Activity e i controlli di spesa aiutano a ricostruire quanto viene consumato e da quali chiavi; le prove dell’applicazione devono comunque accertare se il risultato rimane affidabile quando cambia il modello o il provider.

Il criterio economico conclusivo è semplice da applicare. Se un’alternativa costa meno a token ma richiede correzioni umane più frequenti, può costare di più sul lavoro reale. OpenRouter rende più agevole fare questa verifica con modelli differenti; la convenienza emerge soltanto dopo aver misurato qualità, costi, tempi e vincoli sui dati sul processo che l’impresa intende automatizzare.