LLM Router: Routeer Verzoeken, Bespaar 60% [2026]

LLM Router: Routeer Verzoeken, Bespaar 60% [2026]

Een LLM router is een dunne laag tussen je app en meerdere taalmodellen die bepaalt welk model elk verzoek afhandelt. Hij inspecteert het verzoek (taaktype, complexiteit, tokenbudget), stuurt het door naar het best passende model en valt terug op een backup als dat model een fout geeft. Het doel: passend grote antwoorden tegen de laagste tokenkosten.

Een frontiermodel laten betalen voor het antwoord op "wat is jullie retourbeleid?" is hoe rekeningen oplopen. AWS mat in april 2025 het alternatief: een classifier-router die 0,53 seconden latency toevoegt, een semantische router die 0,10 seconden toevoegt, en tot 30% korting op de rekening bij routing binnen één modelfamilie. Bouw je die som opnieuw over vendors heen met de lijstprijzen van juli 2026, zoals wij hieronder doen, dan loopt de besparing op tot 70%. Het grootste deel van de winst komt uit één beslissing, genomen voordat er ook maar één token is gegenereerd.

Belangrijkste punten

• Een LLM router bepaalt welk model elk verzoek afhandelt, op basis van taaktype, kosten of gemeten kwaliteit.
• Er zijn vijf strategieën: regelgebaseerd, kostenbewust, latency-bewust, semantisch (embeddings) en LLM-classifier-routing.
• Regelgebaseerde routing voegt ~0 ms en $0 toe; classifier-routing voegt per verzoek 300-800 ms plus de tokenkosten van de classifier toe.
• Routing kan de tokenuitgaven tot 60% verlagen wanneer het meeste eenvoudige verkeer naar een 10-20x goedkoper model gaat.
• Eén provider, minder dan 10k verzoeken per dag, geen kostendruk? Sla de router over. Gewone fallbacks zijn genoeg.

Wat doet een LLM router eigenlijk?

Een LLM router voert vóór elke modelaanroep een kleine beslisstap uit: lees het verzoek, score het tegen een routingregel, kies een model, verstuur de aanroep en probeer het opnieuw op een fallback als het eerste model fout gaat. Verder verandert er niets aan je app. Je stuurt nog steeds één verzoek en krijgt één antwoord terug.

De levenscyclus van een verzoek, op volgorde:

1. Verzoek komt binnen op het router-endpoint, precies zoals bij een model-API.
2. Analyseren. De router inspecteert de prompt: trefwoorden, tokenaantal, een embedding of een classifier-score.
3. Selecteren. De routingstrategie koppelt dat signaal aan een modelniveau (goedkoop, midden, frontier of lokaal).
4. Doorsturen. De aanroep gaat naar het gekozen model via een OpenAI-compatibele API.
5. Fallback. Bij een timeout, rate limit of fout probeert het systeem het verzoek opnieuw op het volgende niveau in de keten.

Mensen zoeken op "llm gateway vs router" omdat de documentatie van vendors de termen door elkaar haalt. Eén zin lost het op: de gateway is de pijp; de router is de beslissing. Het zijn lagen, geen rivalen, en de meeste gateways hebben een router ingebouwd.

Volgens de documentatie van LiteLLM draait dezelfde proxy die je virtuele sleutels beheert ook de router. Specifiek de tools op pijp-niveau vergelijken? Onze roundup van de beste LLM gateway-tools rangschikt er tien.

Heb je eigenlijk wel een LLM router nodig?

De meeste kleine apps niet. Een router verdient zichzelf terug wanneer het verkeer zich splitst in duidelijk verschillende taaktypes, wanneer de tokenrekening je grootste infra-kostenpost is, of wanneer je meer dan één provider draait en failover nodig hebt. Onder die drempels kopen gewone retries plus één fallbackmodel je de betrouwbaarheid zonder het bewegende onderdeel.

We zeggen het ronduit, omdat niemand anders in deze ruimte dat doet: draai je één provider met minder dan 10k verzoeken per dag, dan is een router overhead die je niet nodig hebt. Gewone fallbacks winnen.

Waarom zo bot? Elke route is een bewering ("deze taakklasse is veilig op het goedkope model") die veroudert naarmate modellen, prijzen en je product veranderen. Koop die onderhoudskosten alleen wanneer de besparing ze duidelijk overtreft.

De 5 LLM-routingstrategieën (en wanneer je welke gebruikt)

Elke LLM-routingstrategie beantwoordt één vraag: welk signaal vertrouw je genoeg om een model te kiezen? Regels vertrouwen op trefwoorden. Kostenrouting vertrouwt op het tokenbudget. Latency-routing vertrouwt op een timer. Semantische routing vertrouwt op embeddings. Classifier-routing vertrouwt op een andere LLM. De afweging heeft altijd dezelfde vorm: meer signaalkwaliteit, meer toegevoegde latency en kosten per verzoek.

Autocomplete geeft deze zoektermen als "llm routing strategies", "llm task routing", "llm intent routing" en "llm dynamic routing". Ze komen uit op vijf patronen:

Eén patroon snijdt door alle vijf heen: de cascade, ook wel model tiering genoemd. Begin goedkoop en escaleer alleen bij falen of lage zekerheid. Een supportbot antwoordt vanuit een model van $0,25 per miljoen tokens; zakt zijn zekerheid onder de 0,7, dan probeert hetzelfde verzoek het opnieuw op een frontiermodel. Je betaalt voor intelligentie alleen wanneer het goedkope niveau toegeeft dat het vastzit.

Voor academische diepte: de LLMRouter-bibliotheek van ulab-uiuc catalogiseert meer dan 16 onderzochte routingalgoritmen (KNN, SVM, MLP, matrixfactorisatie, Elo, graph en BERT-achtige). Kies je voor semantische routing, dan bepalen de voorbeeld-embeddings vrijwel alles; onze gids over de beste embeddingmodellen behandelt welke standhouden op echte corpora.

Hoe bouw je een LLM router in Python?

Je bouwt er een met ongeveer 80 regels gewone Python tegen elk OpenAI-compatibel endpoint. Geen framework nodig. De vier routers hieronder lopen op in verfijning: trefwoordregels, een kostendrempel, embedding-overeenkomst en een classifier-model met failover. Elke router print het gekozen model, zodat je de beslissing kunt zien gebeuren.

Heb je gezocht op "how to build an llm router" en alleen AWS CDK-stacks en academische repos gevonden, dan is deze sectie het nuchtere antwoord. De referentie-implementatie van AWS is solide, maar vastgelast aan Bedrock, Lambda en CDK. De onze draait overal waar de OpenAI-client heen wijst: OpenAI, Anthropic via een proxy, Ollama op een laptop, vLLM op een GPU-machine. Dit is de router die we eerst voor klanten schetsen.

Stap 1: Regelgebaseerde router (trefwoorden naar modellen)

De zero-latency basislijn. Een regex-kaart beslist; alles wat niet matcht gaat naar het frontier-niveau.

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))

Invoer: een supportvraag. Beslissing: regex-match op "cancel". Gekozen model: gpt-5-mini. Er is geen API-aanroep nodig om het te routeren, en daarom blijft dit de standaard.

Stap 2: Kostenbewuste router (tokenbudget-drempel)

Hetzelfde idee, maar het signaal is de grootte van het verzoek in plaats van trefwoorden. Korte prompts met een klein outputbudget gaan goedkoop; al het andere gaat naar 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

Grof? Ja. Effectief? Ook ja, want tokenvolume correleert beter met taakgrootte dan de meeste mensen verwachten. Dit is de volledige strategie achter verschillende betaalde "cheap llm router"-producten.

Stap 3: Semantische router (embeddings naar voorbeelden)

Voor wazige gebruikersinvoer die trefwoorden ontwijkt: embed de prompt en vergelijk hem met ingebedde voorbeeldprompts. Het dichtstbijzijnde cluster krijgt het verzoek.

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

De routing-aanroep kost één embedding (een paar honderd tokens) en 50-150 ms. Bereken de centroïden vooraf bij het opstarten, niet per verzoek.

Stap 4: LLM-classifier-router met fallback

Het sterkste signaal: een goedkoop model leest de prompt en scoort de moeilijkheid. Dit is de strategie die AWS mat op 0,53 seconden toegevoegde latency, dus we wikkelen hem in een fallback-keten.

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

Dat is het hele llm-router-voorbeeld: vier functies, één client, geen infrastructuur buiten wat je al draait. Productie-hardening is de volgende sectie.

Hoeveel bespaart LLM-routing eigenlijk?

AWS mat de router-overhead op $107,90-$188,90 per maand per 100.000 vragen per dag, waarbij classifier-routing 0,53 seconden per verzoek toevoegt en semantische routing 0,10 seconden. De besparingskant overtreft die overhead ruim. Ons uitgewerkte voorbeeld hieronder, gebouwd op de lijstprijzen van juli 2026, komt uit op een kostenverlaging van 70,7%. De vangst is de verkeersmix: het grootste deel van de verzoeken moet in aanmerking komen voor het goedkope niveau.

Twee tabellen. Eerst wat de router zelf je kost per 1.000 verzoeken:

De blogpost van AWS uit april 2025 is de enige onafhankelijk gepubliceerde metingenreeks in deze ruimte, dus we ankeren eraan en labelen onze uitbreidingen als schattingen, niet als getallen die we zelf hebben gemeten. Bedrock Intelligent Prompt Routing verlaagde de kosten binnen één familie met tot 30%, aldus AWS.

Twee: het uitgewerkte besparingsvoorbeeld dat onze kop onderbouwt:

Aannames, gelabeld: 100.000 verzoeken per maand; gemiddeld 800 input- plus 200 output-tokens per verzoek; een verdeling van 80% eenvoudig / 20% complex; lijstprijzen van de prijspagina van Anthropic en de prijspagina van OpenAI per juli 2026, met de volledige tarieventabel in onze LLM API-prijsvergelijking. Rekensom per verzoek: Sonnet 4 kost 800 x $3/M + 200 x $15/M = $0,0054; GPT-5 mini kost 800 x $0,25/M + 200 x $2/M = $0,0006.

Het resultaat is een verlaging van 70,7%, en daar komt de 60% in onze titel vandaan, met ruimte over. Eerlijke kanttekeningen: dit is een uitgewerkt voorbeeld, geen benchmark die we hebben gedraaid. Het neemt aan dat je goedkope niveau 10-20x goedkoper is en dat 80% van het verkeer echt in aanmerking komt. Routing binnen één familie, het scenario van AWS, blijft rond de 30%. En routing is één van vele hendels; prompt-caching en trimmen verdienen zich vaak sneller terug, en onze gids over manieren om LLM API-kosten te verlagen rangschikt alle twaalf.

Routingpatronen voor productie

Een speelgoedrouter kiest een model. Een productierouter doet ook retries, load balancing, caching van herhalingen en isoleert API-sleutels per team. Voorbij een paar duizend verzoeken per dag: stop met zelf bouwen en draai een gateway met een ingebouwde router.

De vier patronen die ertoe doen:

• Fallback-ketens. Goedkoop niveau eerst, frontier bij fout of timeout. Het patroon met de meeste waarde; het grootste deel van je betrouwbaarheid komt hier alleen vandaan.
• Load balancing. Spreid aanroepen over dubbele deployments of API-sleutels om rate limits per sleutel te omzeilen.
• Antwoord-caching. Identieke prompts geven gecachete antwoorden terug. Supportverkeer herhaalt meer dan je zou denken; hitrates van 10-30% zijn normaal.
• Virtuele sleutels en budgetten. Geef sleutels per team met maandplafonds, zodat één op hol geslagen loop niet de hele rekening kan opbranden.

Dit komt dicht bij de configuratie die we draaien op onze staging-agentstack (bestand: litellm-router.yaml, gemount in de LiteLLM-proxy-container):

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

Waar elke tool past, met onze mening:

• LiteLLM. Kies als je self-hosted en open source wilt en al Docker draait. Onze handleiding voor het opzetten van een LiteLLM-proxy loopt de volledige deploy door, inclusief sleutels en budgetten.
• OpenRouter. Kies als je honderden modellen achter één sleutel wilt en nul beheer. Hun rankings-pagina doet dubbel dienst als throughput-data.
• Portkey. Kies als enterprise-eisen (SSO, auditlogs, compliancerapporten) de beslissing sturen.
• Eigen code uit dit artikel. Kies als je onder de ~50k verzoeken per dag zit en nul nieuwe infrastructuur wilt.

Welke je ook kiest, de roundup van LLM gateway-tools vergelijkt er tien rechtstreeks met elkaar.

Kun je routeren tussen lokale modellen en gehoste API's?

Ja, en de tokenrekensom is verleidelijk: een lokaal model rekent $0 per token, dus elk verzoek dat Ollama of vLLM beantwoordt is pure besparing. De afweging is latency en kwaliteit per watt. Lokaal wint voor eenvoudige taken met hoog volume op hardware die je al hebt; de gehoste API vangt alles op wat een frontier-brein nodig heeft.

De techniek is een anticlimax, en dat is precies de bedoeling. Ollama biedt een OpenAI-compatibel endpoint op localhost:11434/v1 en vLLM serveert dezelfde vorm. Elke router hierboven werkt dus ongewijzigd: wijs base_url naar de lokale server, zet qwen3:8b in het goedkope slot en houd gpt-5 als fallback-niveau. Voor een self-hosted router-machine wordt LiteLLM als Docker-image geleverd, de "llm router docker"-opstelling waar mensen naar zoeken.

Twee eerlijkheidsnotities. Een 70B-model op één A100 serveert ruwweg 30-40 tokens per seconde; gehoste API's verslaan dat op burst-throughput, dus lokale routing past beter bij gestage achtergrondtrafiek dan bij piekerige chat met gebruikers. En lokale 8B-modellen struikelen over meerstaps tool-aanroepen, dus houd de moeilijke routes op de cloud gericht. Kies je de serving-engine zelf, dan benchmarkt vLLM vs SGLang de twee.

Routing drijft ook multi-model setups voor coding-agents aan. Een proxy in LiteLLM-stijl laat Claude Code met lokale en gehoste modellen praten via één endpoint; zie hoe je verschillende modellen in Claude Code gebruikt voor de exacte bedrading.

Hoe weet je of routing werkt?

Je meet het, of je gokt. Log welk model elk verzoek heeft beantwoord, score een steekproef van outputs tegen een rubric en voed de scores terug in de routingregels. Teams die deze stap overslaan eindigen met een statische configuratie die stilletjes veroudert terwijl modellen en prijzen eronder veranderen.

Het groeipad loopt via regels, dan kosten, dan gemeten kwaliteit:

1. Log de route. Sla het gekozen model, de latency en het tokenaantal per verzoek op als één kolom in je bestaande traces.
2. Score outputs wekelijks. Een LLM-judge of een menselijke steekproef, geslaagd/gezakt per verzoekklasse. Vijftig beoordeelde outputs per klasse zijn genoeg om op te sturen.
3. Stel opnieuw af. Haalt het goedkope niveau 95%+ in een klasse, verbreed dan zijn regel om meer van dat verkeer te vangen. Zakt het onder de 90%, maak hem dan strakker.

Dit is de zin die we tegen klanten blijven herhalen: een router die je nooit opnieuw afstelt is gewoon een statische configuratie met extra latency. Log het gekozen model, score outputs, voed scores terug.

Die loop is evals plus observability toegepast op routing. Onze LLM-evaluatiegids behandelt de scoring-rubrics; de AI-observability-gids behandelt waar de traces wonen.

Waar gaat LLM-routingonderzoek naartoe?

De academische lijn behandelt routing als een leerprobleem, niet als een configuratiebestand. LLMRouter van ulab-uiuc, de bibliotheek die als eerste rankt op dit zoekwoord, implementeert meer dan 16 algoritmen (KNN, SVM, MLP, matrixfactorisatie, Elo, graph, BERT en RL-routers) met een benchmark-pijplijn over 11 datasets. Het meest geciteerde recente paper, RouteLLM (Ong et al., arXiv:2406.18665), traint routers op menselijke voorkeursdata en rapporteert meer dan 2x kostenverlaging zonder kwaliteitsverlies op MMLU en MT-Bench. De nieuwste wending: prefill-activation-routers, de "prefill is all you need"-lijn, die de interne activaties van een model lezen tijdens de prefill om moeilijkheid te voorspellen voordat het genereren begint. De richting is routers die zichzelf trainen op jouw eval-data, wat precies de feedbackloop uit de vorige sectie is.

Hoe Techsy dit aanpakt: de agentstacks die we voor B2B-klanten opleveren draaien precies dit patroon, een kostenniveau-router met fallback-ketens die in de gateway zijn bedraad, plus eval-gedreven herafstemming. Overweeg je of routing bij je stack past, vraag dan een gratis consult aan en we brengen je verkeersmix samen in kaart.

Veelgestelde vragen

Wat is een LLM router?

Een LLM router is een laag tussen je applicatie en meerdere taalmodellen die bepaalt welk model elk verzoek afhandelt. Hij controleert het taaktype, de grootte of de moeilijkheid van het verzoek en stuurt het dan door naar het best passende model, met een fallback als dat model faalt. Zie het als een verkeersleider voor je model-API-aanroepen.

Hoe werkt LLM-routing?

LLM-routing werkt in vijf stappen: het verzoek komt binnen, de router inspecteert het (trefwoorden, tokenaantal of een embedding), een strategie kiest een modelniveau, de aanroep wordt doorgestuurd en een fallbackmodel vangt eventuele fouten op. De hele beslissing valt vóór het genereren, dus hij voegt milliseconden toe, geen seconden, tenzij een classifier-model de scoring doet.

Is een LLM router hetzelfde als een LLM gateway?

Nee. Een gateway is de pijp: API-sleutels, rate limits, budgetten en logs. Een router is de beslissing: welk model antwoordt. Het zijn lagen, geen rivalen, en de meeste gateways (LiteLLM, Portkey, OpenRouter) hebben een router ingebouwd. Je kunt een router zonder gateway draaien, maar in productie wil je meestal beide samen.

Bespaart modelrouting echt geld?

Ja, wanneer het grootste deel van je verkeer in aanmerking komt voor een veel goedkoper niveau. Ons uitgewerkte voorbeeld verplaatst 80% van de verzoeken van een model van $3/$15 per miljoen tokens naar een model van $0,25/$2 en verlaagt de rekening met 70,7%. AWS rapporteerde tot 30% voor routing binnen één modelfamilie. Is je verkeer uniform complex, dan krimpt de besparing richting nul.

Wat is de beste open-source LLM router?

Voor productie: LiteLLM, self-hosted, actief onderhouden, en hij combineert een gateway met een router. Voor algoritmen op onderzoeksniveau implementeert LLMRouter van ulab-uiuc meer dan 16 routingstrategieën uit de academische literatuur. RouteLLM is de sterkste router qua kwaliteit per dollar, getraind op voorkeursdata. De meeste teams kunnen beginnen met LiteLLM en alleen naar de onderzoeksbibliotheken grijpen als ze eigen scoring nodig hebben.

Hoe bouw ik een LLM router in Python?

Begin met de OpenAI-client en ongeveer 80 regels code: een regelkaart van trefwoorden naar modellen, een kostendrempel op tokenaantallen, embedding-overeenkomst met voorbeeldprompts, of een goedkoop classifier-model dat moeilijkheid scoort. Alle vier de patronen staan in de bouwsectie hierboven, zonder aanpassingen draaibaar tegen OpenAI, Ollama of vLLM.

Kan ik routeren tussen lokale modellen en cloud-API's?

Ja. Zowel Ollama (localhost:11434/v1) als vLLM biedt OpenAI-compatibele endpoints, dus dezelfde routercode wijst naar een lokaal model voor goedkoop verkeer en een gehoste API voor moeilijk verkeer. Lokale tokens kosten $0, maar je bezit de hardware en de latency. Dit is het patroon achter de meeste multi-model Claude Code-setups.

Wat is semantische routing?

Semantische routing embedt elke binnenkomende prompt en vergelijkt die met ingebedde voorbeeldprompts, waarna het verzoek naar het model gaat dat het dichtstbijzijnde voorbeeldcluster bezit. Het handelt wazige, geparafraseerde gebruikersinvoer af die trefwoordregels missen, tegen een prijs van 50-150 ms plus embedding-tokens per verzoek. AWS mat het op 0,10 seconden toegevoegde latency.

Hoeveel latency voegt een LLM-classifier-router toe?

AWS mat 0,53 seconden toegevoegde latency voor LLM-ondersteunde classificatie, tegenover 0,10 seconden voor semantische routing. Regelgebaseerde en kostenbewuste routing voegen ruwweg nul toe, omdat het gewone codepaden zijn. Heeft je product een strakke responstijd-SLA, geef dan de voorkeur aan regels, kostendrempels of embeddings en bewaar de classifier voor offline of queued workloads.

Bronnen

• Seifi, N. en 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/ (geraadpleegd 30 juli 2026)
• AWS-voorbeeldcode: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (geraadpleegd 30 juli 2026)
• LiteLLM-documentatie. https://docs.litellm.ai (geraadpleegd 30 juli 2026)
• Anthropic-prijzen. https://www.anthropic.com/pricing (geraadpleegd 30 juli 2026)
• OpenAI API-prijzen. https://openai.com/api/pricing (geraadpleegd 30 juli 2026)
• ulab-uiuc LLMRouter. https://github.com/ulab-uiuc/LLMRouter (geraadpleegd 30 juli 2026)
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (geraadpleegd 30 juli 2026)
• OpenRouter-rankings. https://openrouter.ai/rankings (geraadpleegd 30 juli 2026)