Prezzi di OpenRouter Fusion: dimensione del panel e costo dei token

Una richiesta Fusion può sembrare gratuita nella pagina del modello su OpenRouter e costare invece diverse volte più di una normale completion. Il motivo è semplice: il prezzo di OpenRouter Fusion è la somma di più chiamate ai modelli sottostanti, non una tariffa autonoma per token. A determinare se il controllo aggiuntivo vale la spesa sono soprattutto la dimensione del panel e il volume di token.

OpenRouter Fusion: la scelta in breve

OpenRouter Fusion è in genere più costoso di una singola chiamata a un modello comparabile. La documentazione di OpenRouter sul Fusion Router descrive un panel predefinito di tre modelli e una chiamata all’analista, per un costo complessivo di circa 4–5 volte quello di una singola completion sullo stesso prompt.

Un panel economico può risultare preferibile a un modello premium se la qualità ottenuta riduce il lavoro di revisione. Fusion, però, è una scelta tra costo e verifica: non è automaticamente l’opzione più economica.

Il costo si calcola come uno stack, non come un singolo token Fusion

La pagina API di Fusion su OpenRouter presenta Fusion come un router e mostra prezzi pari a zero per prompt e completion dell’alias del router. Questo significa che Fusion non ha una tariffa autonoma separata; non significa che l’inferenza sottostante sia gratuita.

Il flusso documentato è il seguente:

1. Il prompt viene inviato a ciascun modello selezionato nel panel.
2. Le risposte del panel vengono confrontate da un modello analista o giudice.
3. Il modello esterno produce la risposta finale.

Per stimare il budget, usa questa formula:

Fusion cost = sum(panel model costs)
             + analyst/judge cost
             + any final outer-model cost shown for your integration

Il conteggio esatto dipende dal fatto che Fusion venga richiamato come alias del modello openrouter/fusion oppure come server tool openrouter:fusion. Non dedurre il costo finale dalla riga $0 mostrata dal router: verifica la generazione effettiva e il relativo record in OpenRouter Activity.

La documentazione di OpenRouter supporta da 1 a 8 modelli di analisi. Il panel predefinito ne usa tre. Le configurazioni Quality, Budget e personalizzate fanno sì che non esista un unico prezzo Fusion universale per milione di token.

La dimensione del panel fa crescere il conto in modo lineare, almeno finché non aumenta il lavoro del giudice

Se ogni modello del panel riceve lo stesso prompt e produce più o meno la stessa quantità di testo, aggiungere un membro significa aggiungere approssimativamente una chiamata al modello. OpenRouter afferma esplicitamente che il costo cresce linearmente con la dimensione del panel.

Il semplice numero di chiamate, però, sottostima il costo del giudice, perché il suo input cresce insieme alle risposte del panel:

C(n) = n × Cp + Cj(n) + Co

In questa formula, n è il numero di modelli nel panel, Cp è il costo medio della risposta di un modello del panel, Cj(n) è il costo del giudice, incluso l’input crescente, mentre Co è il costo della risposta esterna, quando previsto.

La stima di 4–5× una singola completion per il panel predefinito a tre modelli è quindi un riferimento più utile per il budget rispetto al $0 visualizzato dal router. Il moltiplicatore può aumentare se il giudice è costoso, se le risposte sono lunghe o se il modello esterno aggiunge un’altra completion a pagamento.

Un esempio pratico con tariffe modificabili

Usa questo schema con le tariffe aggiornate dei modelli che scegli. I valori sono puramente illustrativi e non corrispondono ai prezzi di OpenRouter: ipotizziamo 10.000 token di input, 2.000 token di output per ogni risposta del panel, 6.000 token di input per il giudice e 1.000 token di output del giudice.

Panel input  = 10,000 × sum(panel input rates)
Panel output = 2,000 × sum(panel output rates)
Judge input  = 6,000 × judge input rate
Judge output = 1,000 × judge output rate
Fusion total = panel input + panel output + judge input + judge output

Se il modello usato come riferimento elabora gli stessi 10.000 token di input e 2.000 di output, confronta direttamente il suo costo totale con quello calcolato in questo schema. Con un panel di tre modelli, in questo esempio il prompt viene addebitato tre volte e il giudice legge un contesto separato di 6.000 token. Modifica le ipotesi se i tuoi prompt o le tue risposte sono più lunghi.

In un’ipotesi semplificata di costi uguali, la forma del costo in base al numero di chiamate è questa:

Non sono prezzi di OpenRouter, ma mostrano perché il numero di modelli nel panel conta ancora prima di considerare le differenze tra le tariffe. Un giudice costoso può pesare più di un panel economico; al contrario, modelli frontier nel panel possono incidere più del giudice.

L’uso dei token cambia il confronto in due modi distinti

L’uso dei token incide su Fusion più che su una chiamata singola, perché il prompt viene elaborato più volte e il giudice riceve anche le risposte generate dal panel.

1. I token di input vengono replicati su tutto il panel

Sia I il numero di token del prompt e Pi il prezzo dell’input del modello i:

Panel input cost = I × (P1 + P2 + ... + Pn)

Un prompt da 10.000 token inviato a tre modelli del panel genera tre addebiti di input distinti, potenzialmente a tre tariffe diverse.

2. Anche i token di output vengono moltiplicati

Se ogni modello del panel produce O token di output, il panel genera circa n × O token. I token di ragionamento fatturati possono ampliare ulteriormente la differenza rispetto alla lunghezza visibile della risposta.

Il giudice deve poi leggere queste risposte:

Judge input ≈ original prompt + n × panel output + orchestration overhead

Una risposta più lunga può quindi aumentare il costo sia attraverso ciascuna risposta del panel sia tramite il contesto in input del giudice.

Una stima mensile utile è:

Total monthly cost ≈ requests × (panel input + panel output
                                  + judge input + judge output
                                  + outer response)

Per i modelli concreti del tuo panel, usa le tariffe aggiornate. “Budget” è il nome di un preset, non la garanzia che il suo costo totale sarà inferiore a quello di ogni singolo modello.

Budget, Quality o un solo modello?

Scegli un solo modello quando velocità, uniformità dei risultati e prevedibilità dei costi contano più di una revisione indipendente. È la scelta adatta per formattazione, estrazione, completamento automatico, riscritture ordinarie e molte richieste di coding.

Scegli Fusion quando un problema mancato può costare caro: ricerca ricca di fonti, valutazioni di esperti, due diligence o decisioni basate su evidenze in conflitto. Parti dal panel più piccolo in grado di rispondere alla domanda. Tre modelli sono il valore predefinito documentato; otto è il massimo, non una raccomandazione.

Il confronto da fare è questo:

incremental Fusion cost
versus
avoided correction cost + saved human review time + reduced error exposure

Nel suo annuncio separato sui benchmark, OpenRouter riporta una valutazione DRACO su 100 attività, con un risultato del 69,0% per una configurazione Fusion frontier e del 64,7% per un panel Budget. Questi dati supportano un caso d’uso legato alla ricerca approfondita, ma non rappresentano un tasso di successo valido per ogni prompt né dimostrano che un panel più grande sia sempre più conveniente.

Verifica i numeri prima di aumentare il volume

Considera la prima implementazione di Fusion come un test da misurare. Registra:

1. Gli ID dei modelli del panel e l’ID del modello giudice.
2. L’uso di token di input, output e ragionamento, quando disponibile.
3. I metadati del router che confermano l’esecuzione di Fusion.
4. Costo totale e latenza.
5. Se la risposta finale ha ridotto le correzioni umane.

La documentazione di Fusion specifica che i metadati della generazione possono includere "router": "openrouter/fusion". Il normale campo model identifica il modello concreto che gestisce la richiesta e non basta a dimostrare che Fusion sia stato effettivamente eseguito.

Un report di un utente evidenzia un possibile rischio di configurazione:

“this \"Fusion\" still calls Opus 4.8 as a judge. I see no way to disable it.” — @teortaxesTex on X

Si tratta di una testimonianza dell’utente, non di una regola sui prezzi di OpenRouter. Mostra però perché un panel economico non garantisca un’esecuzione economica, se il giudice è costoso o la configurazione non è quella attesa.

In produzione, fissa panel e giudice quando l’API lo consente, imposta limiti di budget e tratta Fusion come un percorso di escalation esplicito, invece di usarlo per ogni richiesta autonoma.

Domande frequenti sui prezzi di OpenRouter Fusion

Fusion costa meno di un singolo modello?

Di solito no, se il confronto è con un modello singolo di prezzo simile. Può costare meno di un modello premium quando un panel Budget offre una qualità sufficiente, ma il risultato dipende dalle tariffe del panel, dal costo del giudice e dal numero di token.

OpenRouter Fusion è gratuito?

L’alias del router può mostrare $0 nei campi relativi al prompt e alla completion. OpenRouter specifica separatamente che le completion dei modelli del panel e del giudice vengono fatturate: una richiesta Fusion normale non va quindi considerata gratuita.

Quante chiamate effettua una richiesta Fusion?

Il processo documentato prevede N chiamate ai modelli del panel più una chiamata all’analista; la risposta esterna finale dipende dall’integrazione. Per la configurazione predefinita a tre modelli, la documentazione indica un costo di circa 4–5 volte quello di una completion comparabile.

Un panel più grande migliora sempre il rapporto qualità-prezzo?

No. Aggiungere modelli può ampliare la copertura, ma aumenta anche i costi del panel, l’input del giudice, la latenza e gli errori correlati. Aumenta le dimensioni del panel solo quando i test su un set separato dimostrano che il miglioramento qualitativo fa risparmiare più di quanto costi.

Come posso stimare il costo di OpenRouter Fusion?

Elenca tutte le chiamate ai modelli sottostanti, moltiplica le tariffe aggiornate di input e output per i token previsti, includi l’input del giudice che contiene le risposte del panel e verifica il risultato in Activity dopo una richiesta reale. Un calcolatore di terze parti può aiutare a simulare diversi scenari, ma le tariffe aggiornate di OpenRouter e il record in Activity restano i riferimenti più autorevoli.

La scelta pratica

Usa un singolo modello come riferimento di base. Esegui un set di test con 20–50 prompt sia sul modello di riferimento sia su un piccolo panel Fusion. Mantieni Fusion solo se la riduzione delle correzioni fattuali, delle evidenze mancate o delle ore di revisione compensa i token aggiuntivi del panel e del giudice.

Per la maggior parte dei team, il rollout più attento ai costi è un solo modello per il traffico ordinario, Fusion con un panel piccolo per le decisioni incerte o ad alto costo e panel più grandi solo quando il miglioramento misurato giustifica il conto.