Router LLM: Instrada le Richieste, Taglia i Costi del 60% [2026]

Router LLM: Instrada le Richieste, Taglia i Costi del 60% [2026]

Un router LLM è un sottile strato software tra la tua app e diversi modelli linguistici che sceglie quale modello gestisce ogni richiesta. Ispeziona la richiesta (tipo di task, complessità, budget di token), la inoltra al modello più adatto e passa a un backup se quel modello va in errore. L'obiettivo: risposte calibrate al task, al costo per token più basso.

Pagare un modello frontier per rispondere a «qual è la vostra politica di rimborso?» è il modo in cui le fatture esplodono. AWS ha misurato l'alternativa nell'aprile 2025: un router a classificatore aggiunge 0,53 secondi di latenza, un router semantico 0,10 secondi, e fino al 30% di sconto sulla fattura per il routing dentro una singola famiglia di modelli. Rifacendo quei calcoli tra vendor diversi con i prezzi di listino di luglio 2026, come facciamo qui sotto, il taglio arriva al 70%. La maggior parte del risparmio viene da una singola decisione, presa prima che venga generato anche un solo token.

Punti Chiave

• Un router LLM decide quale modello gestisce ogni richiesta, in base al tipo di task, al costo o alla qualità misurata.
• Esistono cinque strategie: routing a regole, basato sul costo, basato sulla latenza, semantico (embedding) e a classificatore LLM.
• Il routing a regole aggiunge ~0 ms e 0 $; il routing a classificatore aggiunge 300-800 ms più il costo in token del classificatore per richiesta.
• Il routing può tagliare la spesa in token fino al 60% quando la maggior parte del traffico semplice passa a un modello 10-20 volte più economico.
• Un solo provider, meno di 10k richieste al giorno, nessuna pressione sui costi? Salta il router. Bastano i fallback semplici.

Cosa Fa Davvero un Router LLM?

Un router LLM esegue un piccolo passaggio decisionale prima di ogni chiamata al modello: legge la richiesta, la valuta rispetto a una regola di routing, sceglie un modello, invia la chiamata e riprova su un fallback se il primo modello va in errore. Tutto il resto della tua app resta uguale. Fai sempre una richiesta e ricevi una risposta.

Il ciclo di vita della richiesta, in ordine:

1. La richiesta arriva all'endpoint del router, esattamente come arriverebbe all'API di un modello.
2. Analisi. Il router ispeziona il prompt: parole chiave, numero di token, un embedding o il punteggio di un classificatore.
3. Selezione. La strategia di routing mappa quel segnale a una fascia di modello (economica, intermedia, frontier o locale).
4. Inoltro. La chiamata va al modello scelto tramite un'API compatibile con OpenAI.
5. Fallback. In caso di timeout, rate limit o errore, la richiesta viene ritentata sulla fascia successiva della catena.

Le persone cercano «llm gateway vs router» perché la documentazione dei vendor confonde i termini. Una frase risolve: il gateway è il tubo; il router è la decisione. Sono livelli, non rivali, e la maggior parte dei gateway incorpora un router al proprio interno.

Secondo la documentazione di LiteLLM, lo stesso proxy che custodisce le tue chiavi virtuali esegue anche il router. Vuoi confrontare proprio gli strumenti a livello di tubo? La nostra rassegna dei migliori strumenti LLM gateway ne classifica dieci.

Ti Serve Davvero un Router LLM?

Alla maggior parte delle piccole app non serve. Un router si ripaga quando il traffico si divide in tipi di task chiaramente diversi, quando la fattura dei token è la tua prima voce di costo infrastrutturale, o quando usi più di un provider e ti serve il failover. Sotto quelle soglie, retry semplici più un modello di fallback ti comprano l'affidabilità senza la parte mobile.

Lo diciamo senza giri di parole, perché nessun altro in questo settore lo farà: se usi un solo provider sotto le 10k richieste al giorno, un router è overhead che non ti serve. I fallback semplici vincono.

Perché tanta franchezza? Ogni rotta è un'affermazione («questa classe di task è sicura sul modello economico») che decade man mano che modelli, prezzi e il tuo prodotto cambiano. Compra quel costo di manutenzione solo quando i risparmi lo superano chiaramente.

Le 5 Strategie di Routing LLM (E Quando Usare Ciascuna)

Ogni strategia di routing LLM risponde a una domanda: a quale segnale ti affidi abbastanza da scegliere un modello? Le regole si affidano alle parole chiave. Il routing sul costo si affida al budget di token. Il routing sulla latenza si affida a un timer. Il routing semantico si affida agli embedding. Il routing a classificatore si affida a un altro LLM. Il compromesso ha sempre la stessa forma: più qualità del segnale, più latenza e costo aggiunti per richiesta.

L'autocompletamento le fa emergere come «llm routing strategies», «llm task routing», «llm intent routing» e «llm dynamic routing». Corrispondono a cinque schemi:

Uno schema le attraversa tutte e cinque: la cascata, detta anche model tiering. Parti dall'economico e scala solo in caso di errore o bassa confidenza. Un bot di supporto risponde da un modello da 0,25 $ per milione di token; se la sua confidenza scende sotto 0,7, la stessa richiesta viene ritentata su un modello frontier. Paghi per l'intelligenza solo quando la fascia economica ammette di essere bloccata.

Per la profondità accademica, la libreria LLMRouter di ulab-uiuc cataloga oltre 16 algoritmi di routing studiati nella ricerca (KNN, SVM, MLP, fattorizzazione di matrici, Elo, grafi e varianti BERT). Se scegli il routing semantico, gli embedding esemplari decidono quasi tutto; la nostra guida ai migliori modelli di embedding spiega quali reggono su corpus reali.

Come Si Costruisce un Router LLM in Python?

Ne costruisci uno con circa 80 righe di Python semplice, contro qualsiasi endpoint compatibile con OpenAI. Nessun framework richiesto. I quattro router qui sotto crescono in sofisticazione: regole a parole chiave, una soglia di costo, similarità di embedding e un modello classificatore con fallback. Ciascuno stampa il modello che ha scelto, così puoi guardare la decisione mentre avviene.

Se hai cercato «how to build an llm router» e hai trovato solo stack AWS CDK e repository accademici, questa sezione è la risposta semplice. L'implementazione di riferimento di AWS è solida ma saldata a Bedrock, Lambda e CDK. La nostra gira ovunque punti il client OpenAI: OpenAI, Anthropic tramite proxy, Ollama su un portatile, vLLM su una macchina con GPU. Ecco il router che abbozziamo per primo con i clienti.

Passaggio 1: Router a regole (dalle parole chiave ai modelli)

Il baseline a latenza zero. Decide una mappa di regex; tutto ciò che non corrisponde va alla fascia frontier.

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

Input: una domanda di supporto. Decisione: corrispondenza regex su "cancel". Modello scelto: gpt-5-mini. Nessuna chiamata API necessaria per instradarla, ed è per questo che resta il default.

Passaggio 2: Router basato sul costo (soglia sul budget di token)

Stessa idea, ma il segnale è la dimensione della richiesta invece delle parole chiave. Prompt corti con piccoli budget di output vanno sull'economico; tutto il resto va sul frontier.

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

Grezzo? Sì. Efficace? Anche, perché il volume di token correla con la dimensione del task meglio di quanto molti si aspettino. Questa è l'intera strategia dietro diversi prodotti a pagamento «cheap llm router».

Passaggio 3: Router semantico (dagli embedding agli esemplari)

Per input utente sfumati che schivano le parole chiave, trasforma il prompt in un embedding e confrontalo con prompt esemplari a loro volta incorporati. Il cluster più vicino si prende la richiesta.

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

La chiamata di routing costa un embedding (poche centinaia di token) e 50-150 ms. Pre-calcola i centroidi all'avvio, non per ogni richiesta.

Passaggio 4: Router a classificatore LLM con fallback

Il segnale più forte: un modello economico legge il prompt e ne valuta la difficoltà. Questa è la strategia che AWS ha misurato a 0,53 secondi di latenza aggiunta, quindi la avvolgiamo in una catena di fallback.

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

Qui finisce l'intero esempio di router LLM: quattro funzioni, un client, nessuna infrastruttura oltre a quella che già gestisci. Il rafforzamento per la produzione è la sezione successiva.

Quanto Fa Risparmiare Davvero il Routing LLM?

AWS ha misurato l'overhead del router tra 107,90 $ e 188,90 $ al mese ogni 100.000 domande al giorno, con il routing a classificatore che aggiunge 0,53 secondi per richiesta e il routing semantico 0,10 secondi. Il lato dei risparmi sovrasta quell'overhead. Il nostro esempio svolto qui sotto, costruito sui prezzi di listino di luglio 2026, atterra a una riduzione del 70,7% della spesa. L'ostacolo è il mix di traffico: ti serve che la maggior parte delle richieste si qualifichi per la fascia economica.

Due tabelle. Prima, quanto ti costa il router stesso ogni 1.000 richieste:

Il post di AWS dell'aprile 2025 è l'unico insieme di misurazioni pubblicato in modo indipendente in questo spazio, quindi ci ancoriamo a quello ed etichettiamo le nostre estensioni come stime, non come numeri che abbiamo eseguito. Il Bedrock Intelligent Prompt Routing ha tagliato il costo dentro una famiglia fino al 30%, secondo AWS.

Secondo, l'esempio di risparmio svolto che sostiene il nostro titolo:

Ipotesi, etichettate: 100.000 richieste al mese; 800 token in input più 200 in output per richiesta in media; una divisione 80% semplice / 20% complesso; prezzi di listino dalla pagina dei prezzi di Anthropic e dalla pagina dei prezzi di OpenAI a luglio 2026, con la tabella completa delle tariffe nel nostro confronto dei prezzi delle API LLM. Calcolo per richiesta: Sonnet 4 costa 800 x 3 $/M + 200 x 15 $/M = 0,0054 $; GPT-5 mini costa 800 x 0,25 $/M + 200 x 2 $/M = 0,0006 $.

Il risultato è una riduzione del 70,7%, da cui viene il 60% del nostro titolo, con margine che avanza. Avvertenze oneste: questo è un esempio svolto, non un benchmark che abbiamo eseguito. Suppone che la tua fascia economica costi 10-20 volte meno e che l'80% del traffico si qualifichi davvero. Il routing dentro una famiglia, lo scenario di AWS, resta vicino al 30%. E il routing è una leva tra molte; il prompt caching e la rifinitura dei prompt spesso si ripagano più in fretta, e la nostra guida ai modi per ridurre i costi delle API LLM li classifica tutti e dodici.

Schemi di Routing per la Produzione

Un router giocattolo sceglie un modello. Un router per la produzione ritenta anche, bilancia il carico, mette in cache le ripetizioni e isola le chiavi API per team. Oltre qualche migliaio di richieste al giorno, smetti di scriverli a mano e usa un gateway che incorpora un router.

I quattro schemi che contano:

• Catene di fallback. Prima la fascia economica, la frontier in caso di errore o timeout. Lo schema di gran lunga più prezioso; la maggior parte della tua affidabilità viene solo da questo.
• Bilanciamento del carico. Distribuisci le chiamate tra deployment o chiavi API duplicati per schivare i rate limit per chiave.
• Cache delle risposte. Prompt identici restituiscono risposte in cache. Il traffico di supporto si ripete più di quanto crederesti; tassi di hit del 10-30% sono comuni.
• Chiavi virtuali e budget. Emetti chiavi per team con tetti mensili, così un loop fuori controllo non può bruciare l'intera fattura.

Questa è vicina alla configurazione che usiamo sul nostro stack di agenti in staging (file: litellm-router.yaml, montato nel container del proxy LiteLLM):

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

Dove si colloca ciascuno strumento, con le nostre opinioni:

• LiteLLM. Sceglilo se vuoi self-hosted e open source e gestisci già Docker. La nostra guida alla configurazione del proxy LiteLLM percorre l'intero deploy, incluse chiavi e budget.
• OpenRouter. Sceglilo se vuoi centinaia di modelli dietro una chiave e zero operations. La loro pagina delle classifiche funge anche da dati di throughput.
• Portkey. Sceglilo se sono i requisiti enterprise (SSO, log di audit, report di conformità) a guidare la decisione.
• Codice custom da questo post. Sceglilo se stai sotto le ~50k richieste al giorno e vuoi zero nuova infrastruttura.

Qualunque tu scelga, la rassegna degli strumenti LLM gateway ne confronta dieci testa a testa.

Si Può Fare Routing tra Modelli Locali e API Ospitate?

Sì, e la matematica dei token è seducente: un modello locale fattura 0 $ per token, quindi ogni richiesta a cui Ollama o vLLM rispondono è puro risparmio. Il compromesso è latenza e qualità per watt. Il locale vince per task semplici ad alto volume su hardware che già possiedi; l'API ospitata cattura tutto ciò che ha bisogno di un cervello frontier.

La meccanica è anticlimatica, ed è proprio questo il punto. Ollama espone un endpoint compatibile con OpenAI su localhost:11434/v1, e vLLM serve la stessa forma. Quindi ogni router qui sopra funziona senza modifiche: punta base_url al server locale, metti qwen3:8b nello slot economico e tieni gpt-5 come fascia di fallback. Per una macchina router self-hosted, LiteLLM viene distribuito come immagine Docker, che è la configurazione «llm router docker» che le persone cercano.

Due note di onestà. Un modello 70B su una A100 serve circa 30-40 token al secondo; le API ospitate lo battono sul throughput di picco, quindi il routing locale si adatta meglio al traffico di fondo costante che alle chat rivolte agli utenti con picchi. E i modelli locali da 8B inciampano sulle chiamate tool multi-passo, quindi tieni le rotte difficili puntate sul cloud. Se stai scegliendo il motore di serving in sé, vLLM vs SGLang fa il benchmark dei due.

Il routing alimenta anche le configurazioni di agenti di coding multi-modello. Un proxy in stile LiteLLM lascia che Claude Code parli con modelli locali e ospitati tramite un endpoint; guarda come usare modelli diversi in Claude Code per il cablaggio esatto.

Come Capisci Se il Routing Sta Funzionando?

Lo misuri, o stai tirando a indovinare. Registra quale modello ha risposto a ogni richiesta, valuta un campione di output rispetto a una rubrica e reinserisci i punteggi nelle regole di routing. I team che saltano questo passaggio finiscono con una configurazione statica che marcisce in silenzio mentre modelli e prezzi cambiano sotto di lei.

L'arco di maturazione percorre regole, poi costo, poi qualità misurata:

1. Registra la rotta. Salva il modello scelto, la latenza e il conteggio dei token per richiesta come una colonna nelle tue trace esistenti.
2. Valuta gli output ogni settimana. Un giudice LLM o un campione umano, promosso/bocciato per classe di richiesta. Cinquanta output valutati per classe bastano per guidare.
3. Ricalibra. Se la fascia economica supera il 95% su una classe, allarga la sua regola per catturare più di quel traffico. Se scende sotto il 90%, restringi.

Ecco la frase che ripetiamo di continuo ai clienti: un router che non ricalibri mai è solo una configurazione statica con latenza extra. Registra il modello scelto, valuta gli output, reinserisci i punteggi.

Quel loop è eval più osservabilità applicati al routing. La nostra guida agli eval LLM copre le rubriche di punteggio; la guida all'osservabilità AI copre dove vivono le trace.

Dove Sta Andando la Ricerca sul Routing LLM?

La linea accademica tratta il routing come un problema di apprendimento, non come un file di configurazione. LLMRouter di ulab-uiuc, la libreria che si posiziona prima per questa parola chiave, implementa oltre 16 algoritmi (KNN, SVM, MLP, fattorizzazione di matrici, Elo, grafi, BERT e router RL) con una pipeline di benchmark su 11 dataset. Il paper recente più citato, RouteLLM (Ong et al., arXiv:2406.18665), addestra router su dati di preferenza umani e riporta oltre 2x di riduzione del costo senza perdita di qualità su MMLU e MT-Bench. La novità più recente: i router ad attivazione di prefill, la linea «prefill is all you need», che leggono le attivazioni interne di un modello durante il prefill per prevedere la difficoltà prima che inizi la generazione. La direzione di marcia sono router che si addestrano da soli dai tuoi dati di eval, che è esattamente il loop di feedback della sezione precedente.

Come Techsy affronta tutto questo: gli stack di agenti che forniamo ai clienti B2B eseguono esattamente questo schema, un router a fasce di costo con catene di fallback cablate nel gateway, più ricalibrazione guidata dagli eval. Se stai valutando se il routing si adatta al tuo stack, richiedi una consulenza gratuita e mapperemo il tuo mix di traffico insieme a te.

Domande Frequenti

Cos'è un router LLM?

Un router LLM è un livello tra la tua applicazione e più modelli linguistici che decide quale modello gestisce ogni richiesta. Controlla il tipo di task, la dimensione o la difficoltà della richiesta, poi la inoltra al modello più adatto, con un fallback se quel modello fallisce. Pensalo come un controllore del traffico per le tue chiamate API ai modelli.

Come funziona il routing LLM?

Il routing LLM funziona in cinque passaggi: la richiesta arriva, il router la ispeziona (parole chiave, numero di token o un embedding), una strategia sceglie una fascia di modello, la chiamata viene inoltrata e un modello di fallback cattura qualsiasi errore. L'intera decisione avviene prima che inizi la generazione, quindi aggiunge millisecondi, non secondi, a meno che sia un modello classificatore a fare il punteggio.

Un router LLM è la stessa cosa di un gateway LLM?

No. Un gateway è il tubo: chiavi API, rate limit, budget e log. Un router è la decisione: quale modello risponde. Sono livelli, non rivali, e la maggior parte dei gateway (LiteLLM, Portkey, OpenRouter) incorpora un router al proprio interno. Puoi usare un router senza un gateway, ma in produzione di solito li vuoi entrambi insieme.

Il routing dei modelli fa davvero risparmiare?

Sì, quando la maggior parte del tuo traffico si qualifica per una fascia molto più economica. Il nostro esempio svolto sposta l'80% delle richieste da un modello da 3 $/15 $ per milione di token a uno da 0,25 $/2 $ e taglia la fattura del 70,7%. AWS ha riportato fino al 30% per il routing dentro una singola famiglia di modelli. Se il tuo traffico è uniformemente complesso, il risparmio si riduce verso lo zero.

Qual è il miglior router LLM open source?

Per la produzione, LiteLLM: self-hosted, mantenuto attivamente, e combina un gateway con un router. Per algoritmi di livello accademico, LLMRouter di ulab-uiuc implementa oltre 16 strategie di routing dalla letteratura di ricerca. RouteLLM è il router più forte per qualità per dollaro addestrato su dati di preferenza. La maggior parte dei team dovrebbe partire con LiteLLM e arrivare alle librerie di ricerca solo se serve punteggio custom.

Come costruisco un router LLM in Python?

Parti con il client OpenAI e circa 80 righe di codice: una mappa di regole dalle parole chiave ai modelli, una soglia di costo sul numero di token, similarità di embedding con prompt esemplari, o un modello classificatore economico che valuta la difficoltà. Tutti e quattro gli schemi sono nella sezione di costruzione qui sopra, eseguibili contro OpenAI, Ollama o vLLM senza modifiche.

Posso fare routing tra modelli locali e API cloud?

Sì. Ollama (localhost:11434/v1) e vLLM espongono entrambi endpoint compatibili con OpenAI, quindi lo stesso codice del router punta a un modello locale per il traffico economico e a un'API ospitata per il traffico difficile. I token locali costano 0 $, ma l'hardware e la latenza sono tuoi. Questo è lo schema dietro la maggior parte delle configurazioni multi-modello di Claude Code.

Cos'è il routing semantico?

Il routing semantico trasforma ogni prompt in arrivo in un embedding e lo confronta con prompt esemplari incorporati, inviando la richiesta al modello che possiede il cluster esemplare più vicino. Gestisce input utente sfumati e parafrasati che le regole a parole chiave mancano, al costo di 50-150 ms più token di embedding per richiesta. AWS lo ha misurato a 0,10 secondi di latenza aggiunta.

Quanta latenza aggiunge un router a classificatore LLM?

AWS ha misurato 0,53 secondi di latenza aggiunta per la classificazione assistita da LLM, contro 0,10 secondi del routing semantico. Il routing a regole e quello basato sul costo aggiungono circa zero, perché sono puri percorsi di codice. Se il tuo prodotto ha un SLA sui tempi di risposta stretto, preferisci regole, soglie di costo o embedding, e riserva il classificatore ai workload offline o in coda.

Fonti

• Seifi, N. e Chugh, M. (2025-04-09). "Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ (consultato il 30 luglio 2026)
• Codice di esempio AWS: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (consultato il 30 luglio 2026)
• Documentazione di LiteLLM. https://docs.litellm.ai (consultato il 30 luglio 2026)
• Prezzi di Anthropic. https://www.anthropic.com/pricing (consultato il 30 luglio 2026)
• Prezzi delle API di OpenAI. https://openai.com/api/pricing (consultato il 30 luglio 2026)
• LLMRouter di ulab-uiuc. https://github.com/ulab-uiuc/LLMRouter (consultato il 30 luglio 2026)
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (consultato il 30 luglio 2026)
• Classifiche di OpenRouter. https://openrouter.ai/rankings (consultato il 30 luglio 2026)