OpenRouter BYOK: costi, fallback e rotazione delle chiavi (2026)

Una chiave OpenAI può essere valida, la richiesta può andare a buon fine e il saldo OpenRouter può comunque diminuire. Con OpenRouter BYOK non esiste un singolo interruttore di fatturazione: costo del provider, commissione della piattaforma e capacità di fallback seguono percorsi distinti. Inoltre, la regola attuale ha sostituito il vecchio riferimento a un milione di richieste.

Prima di tutto, identifica quale addebito stai analizzando

OpenRouter BYOK permette di eseguire una richiesta con una credenziale del provider salvata nel tuo workspace, mantenendo però OpenRouter come livello API e di routing. Da qui derivano tre flussi di costo separati:

La prima domanda diagnostica non è «Ho aggiunto la mia chiave?», ma «Quale provider ha effettivamente servito questa richiesta?». Una chiave configurata può fallire per limiti di velocità, fondi insufficienti presso il provider, autorizzazioni mancanti o un'interruzione temporanea. Se il fallback è attivo, OpenRouter può completare la richiesta tramite un altro provider e addebitare quel percorso al tuo saldo OpenRouter, come spiegato nel suo articolo di supporto sugli addebiti BYOK.

Cosa cambia davvero con OpenRouter BYOK

BYOK instrada il traffico idoneo attraverso la credenziale del tuo provider, conservando il livello API e di routing di OpenRouter. Nella sua documentazione BYOK, OpenRouter afferma che le credenziali sono crittografate e vengono usate per richieste indirizzate al provider specificato.

BYOK non rende gratuita l'inferenza: il provider continua a contabilizzare l'uso del modello e OpenRouter può applicare una commissione separata dopo la franchigia applicabile. Fornire una chiave personale non aggira nemmeno le regole di privacy a livello di workspace, account o singola richiesta; se non resta alcun endpoint idoneo, la richiesta fallisce anche con una credenziale valida.

La commissione BYOK attuale dipende dal valore dell'inferenza, non dal numero di richieste

L'attuale pagina dei prezzi OpenRouter definisce la franchigia BYOK senza commissioni in base al valore a prezzo di listino dell'inferenza, non al numero di richieste:

La franchigia viene calcolata sul costo che lo stesso modello e provider avrebbero normalmente su OpenRouter, non necessariamente sulla fattura negoziata con il provider. Superata la soglia, la commissione BYOK del 5% viene sottratta dai crediti OpenRouter; l'addebito del provider resta separato.

Tre voci di costo da tenere su registri distinti

1. Costo dell'inferenza del provider: il provider fattura l'account associato alla credenziale BYOK.
2. Commissione di piattaforma BYOK: OpenRouter applica il 5% oltre la franchigia del piano corrente, usando i crediti OpenRouter.
3. Costo dell'inferenza in fallback: i crediti OpenRouter pagano un percorso che usa capacità del provider finanziata da OpenRouter anziché il percorso BYOK previsto.

Le commissioni per l'acquisto di crediti sono un'altra voce ancora: i prezzi OpenRouter indicano una commissione di piattaforma Pay-as-you-go del 5.5%. Un addebito per una ricarica non dimostra che una specifica richiesta abbia usato il fallback.

Perché nei risultati di ricerca compare ancora la soglia di 1M richieste

L'annuncio di OpenRouter dell'ottobre 2025 parlava di un milione di richieste BYOK mensili senza commissione di piattaforma, seguito da una commissione del 5%. Era la policy storica riportata nell'annuncio datato; la pagina ora segnala che i prezzi BYOK sono cambiati nell'agosto 2026. Per le stime, usa la franchigia basata sull'inferenza a prezzo di listino riportata nella pagina prezzi corrente e annota la data della verifica.

Il fallback stabilisce se BYOK è un confine rigido

L'obiettivo predefinito del routing OpenRouter è portare a termine la richiesta. La guida BYOK descrive chiavi prioritarie, endpoint OpenRouter condivisi e chiavi di fallback come posizioni diverse nel percorso:

• Le chiavi BYOK prioritarie vengono provate nell'ordine configurato.
• Se questi tentativi falliscono, può essere usata la capacità condivisa di OpenRouter.
• Le chiavi BYOK contrassegnate come fallback vengono provate dopo gli endpoint condivisi.
• Più chiavi corrispondenti per lo stesso provider possono essere provate in ordine.

L'ordine dei provider aggiunge un'altra variabile: gli endpoint BYOK corrispondenti vengono tentati prima degli endpoint condivisi anche quando quel provider appare più tardi nell'array order richiesto. Una richiesta può quindi usare una chiave BYOK prima di quanto suggerirebbe la regola generale di ordinamento dei provider.

Affidabilità o certezza dei costi: scegli la priorità

L'opzione della dashboard Usa sempre per questo provider impedisce a OpenRouter di usare la propria credenziale condivisa per quello stesso provider. Non è però un interruttore globale per «non usare mai crediti OpenRouter». L'articolo di supporto di OpenRouter spiega che una richiesta può comunque passare da una chiave BYOK Anthropic a un altro provider compatibile, come Google Vertex, se il fallback tra provider rimane disponibile.

Se ti serve certezza sulla fatturazione, limita direttamente la richiesta:

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [
    { "role": "user", "content": "Summarize this document." }
  ],
  "provider": {
    "only": ["anthropic"]
  }
}

Con provider.only, un errore Anthropic diventa un errore API anziché instradare silenziosamente la richiesta verso un altro provider. È la scelta corretta per carichi regolamentati, accordi sui dati specifici per provider o report dei costi che devono associare ogni richiesta a un solo account upstream. È invece una scelta poco adatta come impostazione predefinita per un prodotto interattivo, dove la disponibilità conta più della proprietà rigorosa del provider.

Un utente reale di r/openrouter ha descritto lo stesso controllo:

«puoi specificare provider order/only direttamente nella richiesta per forzare l'uso esclusivo delle tue chiavi BYOK.» — u/Randomdotmath, Discussione Reddit

Se il fallback fa parte della tua strategia di affidabilità, preventivane il costo; se non lo è, disabilitalo al confine della richiesta.

Controlla il percorso in Activity prima di attribuire la causa alla commissione

Le FAQ di OpenRouter indicano che Activity può mostrare la cronologia di utilizzo e filtrarla per modello, provider e chiave API. Verifica:

1. Provider servente: corrisponde al provider associato alla tua credenziale BYOK?
2. Modello ed endpoint: il router ha scelto un altro endpoint compatibile?
3. Chiave API dell'applicazione: quale chiave di ambiente o workspace ha effettuato la richiesta?
4. Detrazione di crediti: l'importo riguarda spesa per inferenza, commissione BYOK o una variazione del saldo legata alla ricarica?

Se il provider in Activity differisce da quello BYOK, indaga sul fallback prima di modificare la credenziale. Se il provider coincide e il volume si avvicina alla franchigia del piano, esamina la commissione di piattaforma BYOK. Così eviti di ruotare una chiave valida per risolvere un problema di policy di routing.

Un'architettura delle chiavi pronta per la rotazione in produzione

Tratta la chiave applicativa OpenRouter e la credenziale BYOK upstream come segreti distinti, con proprietari diversi:

Configurare e testare una credenziale BYOK

Prima di analizzare il traffico di produzione, segui questo percorso rapido:

1. Aggiungi la credenziale del provider nelle impostazioni BYOK del workspace oppure creala tramite l'API di gestione BYOK.
2. Assegnale un nome che identifichi provider, ambiente e finalità.
3. Applica filtri per modello, chiave API OpenRouter o membro prima di condividere la credenziale del workspace.
4. Inserisci la chiave nella sezione prioritaria e aggiungi una chiave di fallback soltanto se il suo ruolo nei costi e nelle interruzioni è esplicito.
5. Invia una richiesta di test, controlla in Activity il provider servente, quindi decidi se lasciare attivo il fallback condiviso.

Per i provider cloud, le credenziali non sono intercambiabili:

Questi vincoli provengono dalla documentazione BYOK specifica per provider di OpenRouter. Un segreto valido associato al tipo di risorsa, regione, deployment o autorizzazione errati indica un errore di configurazione, non che BYOK non sia supportato.

Le impostazioni BYOK di OpenRouter supportano filtri per slug dei modelli, hash delle chiavi API OpenRouter e membri del workspace. Per rendere idonea una credenziale, ogni filtro attivo deve corrispondere; la documentazione consente fino a 100 voci per filtro. Usa allowlist esplicite e separa i team numerosi in workspace diversi, invece di mantenere una sola credenziale sempre più ampia.

Ruotare la chiave applicativa OpenRouter senza ruotare le chiavi del provider

Il cookbook sulla rotazione delle chiavi API di OpenRouter descrive le credenziali BYOK dei provider come associate all'account OpenRouter, non a una specifica chiave applicativa. La sequenza senza downtime è:

1. Crea una chiave applicativa OpenRouter sostitutiva con un nome descrittivo e un limite appropriato.
2. Salvala nel tuo secrets manager e distribuiscila a ogni servizio, job e ambiente che usa la vecchia chiave.
3. Conferma in Activity che il traffico di produzione stia usando la chiave sostitutiva.
4. Elimina la vecchia chiave soltanto dopo aver completato la migrazione.

La documentazione della Management API specifica che le chiavi Management API sono credenziali amministrative e non possono chiamare gli endpoint di completion. La chiave sostitutiva deve essere disponibile prima di revocare la vecchia chiave applicativa.

Ruotare separatamente la credenziale del provider

La rotazione della chiave del provider è una modifica distinta. Segui la policy di credenziali del provider e testa esattamente modello, regione, autorizzazioni e quota usati dal carico di lavoro.

1. Crea upstream la credenziale sostitutiva con le autorizzazioni minime necessarie.
2. Aggiungila alla connessione BYOK OpenRouter con un nome distinto e una priorità controllata.
3. Invia una richiesta di test e controlla Activity.
4. Porta la sostituta in posizione primaria e monitora errori e utilizzo presso il provider.
5. Revoca upstream la vecchia credenziale dopo la finestra di sovrapposizione.

Questa sequenza è una raccomandazione operativa basata sul comportamento di priorità documentato da OpenRouter; restano vincolanti le regole di revoca del provider. L'API di creazione BYOK di OpenRouter accetta una credenziale non elaborata, ma indica che viene crittografata a riposo e non restituita nelle successive risposte API. Conserva la credenziale sorgente nel tuo secrets manager: OpenRouter non è una copia di recupero.

Quando OpenRouter BYOK non dovrebbe essere la scelta predefinita

L'accesso diretto al provider è una scelta migliore quando contano più del routing unificato i log nativi di un singolo provider, il comportamento esatto degli endpoint o gli strumenti del vendor. BYOK è più adatto quando usi account presso più provider, crediti o capacità impegnata già esistenti presso i provider e controlli a livello di workspace.

FAQ su OpenRouter BYOK

OpenRouter addebita ancora costi se uso la mia chiave?

Sì. Il provider può fatturare l'inferenza tramite la credenziale BYOK; OpenRouter può sottrarre dai crediti una commissione di piattaforma BYOK del 5% oltre la franchigia del piano corrente; inoltre, il fallback può far pagare ai crediti OpenRouter un percorso presso un altro provider.

«Usa sempre per questo provider» blocca ogni fallback?

No. Impedisce a OpenRouter di usare la propria credenziale condivisa per quel provider, ma non impedisce a una richiesta di passare a un provider compatibile differente. Usa provider.only quando questo percorso tra provider deve essere impossibile.

Come dovrebbe gestire un'azienda sicurezza e budget BYOK?

OpenRouter afferma che le credenziali sono crittografate, che le chiavi raw dei provider non vengono restituite tramite la Management API e che, per impostazione predefinita, la spesa BYOK è esclusa dai budget di guardrail e workspace. La documentazione BYOK indica di attivare Include BYOK spend o include_byok_in_budgets quando serve un budget combinato; i team enterprise dovrebbero inoltre usare credenziali con privilegi minimi, separazione dei workspace, filtri, custodia nel secret manager, rotazione e revisione di Activity.

La configurazione predefinita deve riflettere il tipo di errore che puoi accettare

Scegli controlli di routing e budget in base al requisito su cui non puoi scendere a compromessi: completamento della richiesta, proprietà del provider o visibilità dei costi.