LLM-API-kosten halveren: een gids voor modelroutering voor workloads in productie in 2026

Het kostenprobleem dat in je factuur schuilgaat

Kijk naar de modelparameter in je productiecode. Voor de meeste teams die een LLM-werkbelasting draaien die de prototypefase is ontgroeid en echte traffic verwerkt, wordt die parameter één keer ingesteld (meestal op het sterkste model waartoe het team toegang had bij de release) en daarna nooit meer herzien. Elke query, ongeacht de complexiteit, gaat naar hetzelfde model. En precies daar zit de stille kostenoverschrijding.

In elke niet-triviale productie-werkbelasting zijn queries niet uniform moeilijk. Een klantenservice-assistent ziet misschien 80% aan vragen die simpele opzoekingen, classificaties of korte follow-ups zijn, en 20% die echt frontier-reasoning vereisen. Een code-assistent verwerkt mogelijk een gestage stroom kleine refactors en een long tail aan meerlaagse, over meerdere bestanden verspreide architectuurwijzigingen. Een contentpijplijn kan honderden samenvattingstaken verwerken voor elke taak die gestructureerd creatief schrijven vereist. De vorm van het werk is ongelijk, maar de routering naar het model niet.

Als je vandaag 100M tokens per maand draait op GPT-5.5 en 70% van die queries net zo goed zou worden beantwoord door een goedkoper model, betaal je ruwweg $600 per maand voor capaciteit die je niet gebruikt. Bij hogere volumes componeert hetzelfde patroon lineair: voor elke 1B tokens is het gat tussen een niet-geroute setup en een geroute setup enkele duizenden dollars per maand.

Routing is het technische antwoord op die asymmetrie. Het principe is eenvoudig: stuur elke query naar het goedkoopste model dat het aankan, en schaal alleen op naar een capabeler model wanneer dat nodig is. De implementaties zijn waar de interessante trade-offs zitten, en de meeste gepubliceerde richtlijnen behandelen ze slecht. Dit stuk behandelt de drie patronen die in productie wél werken, de kostenwiskunde die de businesscase maakt, de faalmodi die je zullen verrassen, en een migratieplaybook om van een single-model-setup naar een geroute setup te gaan zonder je applicatie te herschrijven.

De prijsdata waarop dit artikel steunt komt uit het bijbehorende stuk (de 2026 LLM API-prijsvergelijking), dat de per-model-tarieven vastlegt waarnaar hier wordt verwezen. Waar deze gids een kostencijfer noemt, is het afkomstig uit die data.

De drie routeringspatronen die in productie werken

Er zijn drie gevestigde patronen voor het routeren van LLM-verkeer. Ze verschillen in implementatiecomplexiteit, latency-overhead en de soorten kostenbesparingen die ze ontsluiten. De meeste productiesystemen gebruiken uiteindelijk een combinatie van alle drie; het begrijpen van de sterke punten van elk helpt je de werkzaamheden te sequencen.

Patroon 1: Statische regels

Het simpelste patroon. Je schrijft regels die queries naar verschillende modellen routeren op basis van observeerbare eigenschappen van het verzoek: invoerlengte, gebruikerstier, querytype (als je al een classifier hebt), API-endpoint of businesslogica. Korte queries gaan naar een goedkoop model; lange queries gaan naar een sterker model. Gratis-tier-gebruikers krijgen een goedkoper model dan betalende gebruikers. Codegeneratieverzoeken gaan naar een code-gespecialiseerd model; de rest gaat naar een general-purpose model.

Statische routing is voorspelbaar, debugbaar en voegt praktisch nul latency-overhead toe: de routeringsbeslissing is een paar regels code die lokaal draait. Het plafond is ook lager: je routeert op eigenschappen die je kunt observeren vóórdat het model draait, wat betekent dat je niet kunt routeren op “hoe moeilijk de query werkelijk is” omdat je dat nog niet weet. Voor werkbelastingen waar inputeigenschappen goed correleren met moeilijkheid (lange documenten zijn doorgaans moeilijker; code verschilt meestal van proza; betalende gebruikers hebben doorgaans veeleisendere queries), kan statische routing 30–50% van de beschikbare besparing vangen met zeer weinig engineeringinspanning.

Patroon 2: Cascade

Het breedst toepasbare patroon. Je stuurt de query eerst naar een goedkoop model; als de respons een kwaliteitsdrempel haalt, retourneer je die; als dat niet zo is, schaal je op naar een capabeler model en gebruik je diens respons in plaats daarvan. De kostenbesparing komt doordat je voor de queries die het goedkope model aankan, alleen de prijs van het goedkope model betaalt.

Het onderscheidende kenmerk van het cascadepatroon is dat de routeringsbeslissing wordt geïnformeerd door de output van het model, niet alleen de input: je laat het goedkope model het werk proberen en beoordeelt dan of de poging goed genoeg was. De beoordeling kan op verschillende manieren worden geïmplementeerd: vertrouwensscores van het model zelf, validatie van gestructureerde output (parseert de respons volgens het verwachte schema?), self-evaluatieprompts (een klein model vragen of de respons de vraag beantwoordt), of downstream-gedragssignalen (accepteerde de gebruiker het antwoord, of formuleerde hij het opnieuw en probeerde het nogmaals?).

Cascade is het patroon dat de meeste productiesystemen uiteindelijk adopteren omdat het kostenbesparingen oplevert die statische regels niet kunnen. De trade-off is dat je bij geëscaleerde queries betaalt voor zowel de call van het goedkope model als die van het vlaggenschip, dus de besparing hangt af van welk deel van de queries slaagt op de goedkope laag. Dit is het patroon dat we later in dit artikel in detail doorwerken.

Patroon 3: Classifier-gedreven routing

Het hoogste plafond en de meeste engineeringinvestering. Een klein, snel model (vaak een getunede versie van een sub-frontier-model, of een dedicated classifier) bekijkt elke binnenkomende query en voorspelt welk downstream-model deze moet afhandelen. De classifier kan beslissen op basis van querytype (“dit lijkt een codegeneratietaak; routeer naar het code-gespecialiseerde model”), moeilijkheidsschatting (“dit lijkt een moeilijke reasoning-query; routeer naar GPT-5.5”) of een getrainde routeringspolicy op basis van historische traffic en uitkomsten.

Classifier-gedreven routing kan beter presteren dan cascade omdat de routeringsbeslissing valt vóórdat een duur model draait, zodat je de “goedkoop-model-belasting” niet betaalt voor queries die toch altijd naar het vlaggenschip moesten. De kosten zijn het engineeringwerk om de classifier zelf te bouwen, trainen en onderhouden, plus de kleine latency-overhead van de routeringscall. Voor zeer hoog-volume werkbelastingen betaalt deze trade-off zichzelf terug; voor kleinere werkbelastingen meestal niet.

Welke patroon om mee te beginnen: eerst statische regels als je werkbelasting duidelijke routeringssignalen heeft (invoerlengte, gebruikerstier, endpoint). Cascade als dat niet zo is, of zodra je de voor de hand liggende statische regels hebt uitgeput. Classifier-gedreven pas nadat zowel statisch als cascade op hun plek staan en het volume van de werkbelasting de engineeringinvestering rechtvaardigt. Direct naar classifier-gedreven springen is een klassiek over-engineeringstrik waar de meeste teams spijt van krijgen.

Wat je moet meten voordat je begint met routeren

Je kunt niet optimaliseren wat je niet meet. Voordat je routeringslogica in een productiesysteem introduceert, instrumenteer je de huidige single-model-werkbelasting zodat je een baseline hebt om mee te vergelijken. De instrumentatie hoeft niet uitgebreid te zijn: een basale log van elk verzoek met een kleine set velden is genoeg om te beginnen.

De minimaal bruikbare instrumentatie:

• Per verzoek: gebruikt model, aantal inputtokens, aantal outputtokens, kosten (berekend uit tokenaantallen en tariefkaart), end-to-end-latency, responsstatus (succes / fout / gedeeltelijk), en een querytypelabel als je dat hebt.
• Per conversatie of per gebruiker: sessielengte, aantal retries (signaleert dat de gebruiker het eerste antwoord niet accepteerde), follow-upratio (signaleert dat het antwoord verduidelijking vereiste).
• Een apart gehouden evaluatieset: 100–500 representatieve queries die je op elk model kunt herdraaien, met referentieoutputs die je vertrouwt. Hiermee meet je of een kandidaat-goedkoper model acceptabele kwaliteit levert op jouw werkbelasting. Zonder dit is elke routeringsbeslissing giswerk.

De evaluatieset is waar de meeste teams onderinvesteren, en het is het single meest hefboomrijke stuk infrastructuur voor elk routeringsproject. Lichtgewicht tools zoals Promptfoo of Helicone evals kunnen het snel opzetten; voor vroege werkbelastingen is een handmatig samengestelde set van 50 queries met handmatig beoordeelde outputs ruim voldoende om te beginnen.

Eenmaal geïnstrumenteerd, draai je de werkbelasting zoals die nu is minstens een week om de baseline vast te stellen. De vorm van de data (hoe scheef is je distributie van invoerlengte, welk deel van de queries is kort en simpel, welk deel lijkt moeilijk) vertelt je met welk routeringspatroon je moet beginnen.

Het cascadepatroon in detail, met kostenwiskunde

Het cascadepatroon verdient de meeste ruimte omdat het het breedst toepasbaar is en het patroon dat de meeste teams als eerste of tweede zullen implementeren. De wiskunde is ook waar de case voor routing concreet wordt.

Neem een representatieve productie-werkbelasting die vandaag draait op Claude Sonnet 4.6: 100 miljoen tokens per maand, 80% input en 20% output, $475 maandelijkse factuur tegen lijstprijzen. Stel dat we er een cascade voor zetten: queries gaan eerst naar Claude Haiku 4.5, en schalen alleen op naar Sonnet 4.6 als Haiku’s respons faalt op een kwaliteitscheck. Haiku 4.5 staat geprijsd op $1.00 input en $5.00 output per miljoen tokens, een derde van Sonnet’s tarief.

De kostenwiskunde hangt af van twee parameters: welk percentage van de queries slaagt op de Haiku-laag (we noemen dit het succespercentage), en hoe de input/output-verhouding verschilt tussen succesvolle en geëscaleerde queries. Voor de eenvoud gaan we ervan uit dat de input/output-verhouding voor beide gelijk is, en dat het succespercentage 70% is, wat betekent dat Haiku’s respons goed genoeg is bij 70% van de queries en 30% opschaalt naar Sonnet.

Wat dit je vertelt. Zelfs bij een gematigd succespercentage van 70% (wat betekent dat Haiku het 7 van de 10 keer goed doet), halveert de cascade de rekening. De reden is dat de call naar het goedkope model zóveel goedkoper is dan de call naar het vlaggenschip, dat betalen voor beide bij de 30% van de queries die escaleren nog steeds veel minder is dan voor elke query het vlaggenschip betalen. Het break-evenpunt (waar cascade gelijk is aan single-modelkosten) ligt ruwweg bij een succespercentage van 33%. Daaronder kun je beter direct gaan; daarboven wint de cascade.

De minimaal bruikbare cascade-implementatie

Onderstaand de simpelste versie van het patroon, uitgedrukt in Python met de OpenAI-compatibele client (die werkt tegen elke provider die een OpenAI-compatibel endpoint aanbiedt, waaronder Claude via de compatibiliteitslaag van Anthropic, Gemini en het unified endpoint van CometAPI). De structuur is opzettelijk kaal; productie-implementaties voegen observability, foutafhandeling en meer verfijnde kwaliteitschecks toe.

from openai import OpenAI
import json

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.cometapi.com/v1",  # of je provider naar keuze
)

CHEAP_MODEL = "claude-haiku-4-5"
FLAGSHIP_MODEL = "claude-sonnet-4-6"


def cascade(messages, output_schema=None):
    """
    Voer een query door een cascade.
    Retourneert (response, model_used, escalated).
    """

    # Stap 1: probeer het goedkope model
    cheap_response = client.chat.completions.create(
        model=CHEAP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    cheap_text = cheap_response.choices[0].message.content

    # Stap 2: beoordeel of de goedkope respons goed genoeg is
    if is_acceptable(cheap_text, output_schema):
        return cheap_text, CHEAP_MODEL, False

    # Stap 3: schaal op naar het vlaggenschip
    flagship_response = client.chat.completions.create(
        model=FLAGSHIP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    flagship_text = flagship_response.choices[0].message.content

    return flagship_text, FLAGSHIP_MODEL, True


def is_acceptable(response_text, output_schema=None):
    """
    Kwaliteitshek.
    Retourneert True als de output van het goedkope model goed genoeg is.
    """

    if not response_text or len(response_text.strip()) < 10:
        return False

    if output_schema:
        # Gestructureerde output: moet te parsen zijn volgens het schema
        try:
            parsed = json.loads(response_text)
            return validate_schema(parsed, output_schema)

        except (json.JSONDecodeError, ValueError):
            return False

    # Voor vrije-tekst-antwoorden: plug je eigen kwaliteitsignaal in:
    # - vertrouwensscore van het model
    # - self-evaluatieprompt naar een klein model
    # - regelgebaseerde checks (lengte, formaat, weigeringspatronen)

    return True

Dit is een startpunt, geen afgewerkte implementatie. Drie dingen die je voor productie zou toevoegen:

• Een echt kwaliteitshek. De functie is_acceptable hierboven is bewust minimaal. In de praktijk is het hek het belangrijkste stuk van de cascade: te laks en je levert antwoorden van lage kwaliteit; te streng en je escaleert te vaak en verliest de besparing. De meeste productie-cascades gebruiken een combinatie van validatie van gestructureerde output, detectie van weigeringen (het goedkope model zegt “Ik kan dit niet beantwoorden”) en self-evaluatie door een klein model dat wordt geprompt om de respons te beoordelen.
• Per-verzoek-observability. Log welk model is gebruikt, of het verzoek escaleerde, de latency op elke laag en de kosten. Dit vertelt je, na een week draaien met de cascade, of het succespercentage is wat je aannam.
• Een kanariepad voor evaluatie. Stuur een klein percentage van het verkeer (zeg 5%) door het vlaggenschip, ook wanneer de cascade slaagt op de goedkope laag. Vergelijk de responses op een apart beoordelingsrubriek. Zo vang je stille kwaliteitsdegradatie; zie de volgende sectie.

Waar routing stukloopt

De kostenbesparende wiskunde hierboven is echt, maar het is ook het optimistische geval. Drie faalmodi verrassen teams, en ze eerlijk benoemen is wat een routeringsimplementatie die waarde componeert onderscheidt van een die stilletjes het product degradeert.

Latency-overhead bij geëscaleerde verzoeken

Wanneer een query escaleert, betaal je voor de call naar het goedkope model vóórdat de call naar het vlaggenschip begint. Als het goedkope model 800 ms duurt en het vlaggenschip 1,5 s, duurt de geëscaleerde query end-to-end 2,3 s. Voor latency-gevoelige werkbelastingen is dit relevant. De mitigaties zijn: kies een snel goedkoop model (Haiku 4.5 en Gemini 3 Flash zijn hiervoor ontworpen), stel agressieve time-outs in op de call naar het goedkope model en overweeg parallelle calls voor de queries waarvan je vermoedt dat ze het meest waarschijnlijk escaleren. Sommige teams accepteren de latencykosten omdat de dollarisering groot is; anderen gebruiken statische regels om te voorkomen dat evident moeilijke queries überhaupt door de cascade gaan.

Stille kwaliteitsdegradatie

De meest verraderlijke faalmodus. Het goedkope model produceert responses die je kwaliteitshek passeren maar subtiel slechter zijn dan de responses van het vlaggenschip: iets minder accuraat, iets minder behulpzaam, iets eerder geneigd om randgevallen te missen. Gebruikers klagen niet direct; de metric die je in de gaten houdt (responstijd, foutpercentage, hek-slaagpercentage) ziet er allemaal goed uit; maar downstream metrics (gebruikersretentie, conversieratio, support-escalaties) driften. Tegen de tijd dat je het merkt, heb je weken aan gedegradeerde kwaliteit verscheept.

De verdediging is het hierboven genoemde kanariepad: een apart percentage traffic dat parallel met de cascade door het vlaggenschip loopt, waarbij beide responses worden beoordeeld tegen een evaluatierubriek. De beoordeling kan door een model zelf worden gedaan (LLM-als-rechter), of door gesamplede menselijke review. Het punt is een continu kwaliteitsignaal te behouden dat onafhankelijk is van het hek van de cascade, zodat degradatie zichtbaar wordt als een drift in dat signaal in plaats van als een downstreamverrassing.

Complexiteitskosten in code en observability

Elk extra model in de routeringsgrafiek is een model om te evalueren, te monitoren en te updaten wanneer de provider een nieuwe versie uitrolt. Een tweelaagse cascade is beheersbaar; een vijf-model-classifier-router met aparte paden voor code, RAG, chat, agents en edgecases is wezenlijk complexer dan de single-model-setup die het verving. De complexiteit is de moeite waard wanneer het volume van de werkbelasting het rechtvaardigt; onder dat volume kan de engineeringtijd die in de routeringslaag wordt gestoken de kostenbesparingen overstijgen die het oplevert. Wees eerlijk over je volumebovengrens.

Hoe aggregators helpen (en waar ze dat niet doen)

LLM-aggregators (diensten die meerdere modellen achter één OpenAI-compatibele API aanbieden) interacteren met routing op twee onderscheiden manieren. Beide zijn het begrijpen waard, omdat het antwoord op “wil ik een aggregator in mijn routeringsstack?” afhangt van welke interactie je belangrijk vindt.

De echte hulp: de integratietaks wegnemen

Een cascade of classifier-gedreven router bouwen op directe provider-API’s betekent meerdere SDK’s beheren, meerdere authenticatiecredentials, meerdere factureringsoppervlakken en meerdere sets provider-specifieke eigenaardigheden (timeoutgedrag, foutformaten, rate-limitsemantiek). Voor een multi-model-routeringssetup is deze overhead reëel. Een aggregator zoals CometAPI biedt elk model achter één OpenAI-compatibel endpoint, wat betekent dat de codewijziging voor routing simpelweg het veranderen van de modelparameter is, zonder providerwissel, zonder aparte sleutels, zonder aparte observabilitylaag. Voor teams wiens primaire obstakel voor routing de integratiekosten zijn en niet de kwaliteitsbeoordeling, is dit doorslaggevend.

Waar je voorzichtig mee moet zijn: ingebouwde routeringslagen

Sommige aggregators bieden een “smart routing” of “model optimizer”-functie die het model voor je kiest op basis van de query. Dit kan nuttig zijn voor prototyping maar is doorgaans de verkeerde default voor productie. De reden is dat de routeringsbeslissing een van de meest werkbelasting-specifieke zaken in je stack is: wat telt als “moeilijk genoeg om op te schalen” hangt af van je evaluatiecriteria, je latencybudget, je kwaliteitslat en je kostendrempel. Een generieke routeringslaag kan geen van deze kennen. De meeste productiesystemen zijn beter af met een dunne, transparante aggregator (een die dezelfde modellen blootlegt als je direct zou benaderen, met één credential en één factuur) plus hun eigen routeringslogica erbovenop, dan met een blackbox-routeringslaag die ze niet kunnen tunen.

Het migratieplaybook

Een veilige, stapsgewijze route van een single-model-productiewerkbelasting naar een geroute setup. Het principe is steeds om veranderingen te maken die individueel omkeerbaar zijn en de impact van elke verandering te meten voordat je de volgende doet.

• Instrumenteer de huidige werkbelasting. Log elk verzoek met model, input/output-tokens, kosten, latency en een querytypelabel. Draai minimaal één week om een baseline vast te stellen. Zonder dit is elke volgende stap giswerk.
• Bouw de evaluatieset. Curateer 100–500 representatieve queries met referentieoutputs die je vertrouwt. Dit is de apart gehouden set die je gebruikt om de cascade bij elke stap te vergelijken met de single-model-baseline.
• Identificeer het querytype met het hoogste volume. Vind in de instrumentatiedata de categorie die het meeste verkeer veroorzaakt. Hier ga je de cascade pilotten. Het hoeft niet de makkelijkste categorie te zijn, alleen de grootste, want daar concentreren de besparingen.
• Bouw een cascadeprototype voor dat ene querytype. Twee lagen: eerst het goedkope model, het vlaggenschip als het faalt op het kwaliteitshek. Draai het eerst op de evaluatieset. Vergelijk kosten en kwaliteit met de single-model-baseline. Als de kwaliteit standhoudt en de kosten dalen, ga verder; als de kwaliteit daalt, maak het hek strenger en probeer opnieuw.
• Rol uit achter een traffic-percentage. Begin met 5–10% van de productie-traffic voor het gekozen querytype. Draai minstens een week. Monitor het escalatiepercentage van de cascade, de kosten per verzoek, de latency op elke laag en de kwaliteitsvergelijking van het kanariepad. Als de metrics overeenkomen met de voorspelling van het prototype, breid uit naar 25%, dan 50%, dan 100%.
• Herhaal voor het volgende querytype. Zodra het eerste querytype volledig is gemigreerd en de kostenbesparing is gerealiseerd, ga naar de volgende categorie met het hoogste volume. Elke cascade is een aparte beslissing; ga er niet van uit dat een patroon dat voor het ene querytype werkte, voor een ander ook werkt.
• Voeg een continu kwaliteitskanarie toe. Zodra meerdere querytypen op cascades draaien, zet het apart gehouden kanariepad permanent op, met 5% van de traffic die door het vlaggenschip loopt voor beoordeling. Dit is je vroegtijdige waarschuwingssysteem voor stille degradatie en het is wat de routeringslaag betrouwbaar houdt terwijl modellen updaten.

Wanneer routing het niet waard is

Eerlijke erkenning. Er zijn werkbelastingen waarbij de engineeringinvestering in routing zich niet terugverdient, en ze vooraf herkennen bespaart tijd:

• Single-model-werkbelastingen waar één model echt voor alles het juiste antwoord is. Als je evaluatieset een betekenisvolle kwaliteitsdaling laat zien op de goedkope laag over de hele werkbelasting, heeft de cascade niets om mee te werken. Een codegeneratiewerkbelasting die wordt begrensd door redeneercapaciteit is één voorbeeld: Haiku zal het hek te vaak niet halen om de cascade geld te laten besparen.
• Zeer laag-volume werkbelastingen. Onder grofweg $200/maand aan LLM-uitgaven overstijgt de engineeringtijd voor het bouwen en onderhouden van de routeringslaag doorgaans de besparingen. De drempel is werkbelasting-specifiek, maar reëel. Wees eerlijk over of je uitgaven hoog genoeg zijn om het werk te rechtvaardigen.
• Gereguleerde omgevingen waar “vendor of record” ertoe doet. Als je compliance vereist dat al het productie-verkeer via één specifieke providerrelatie loopt, maakt multi-model-routing dat gesprek complexer. Er zijn mogelijk nog wel routeringsopties binnen één provider (Sonnet → Opus bij Anthropic; GPT-5 nano → GPT-5.5 bij OpenAI), maar cross-provider-routing is lastiger te rechtvaardigen.

De eerlijke framing: routing betaalt zich terug wanneer je werkbelasting hoog-volume is, je queries niet uniform moeilijk zijn en je de evaluatie-infrastructuur hebt om te weten wanneer de cascade acceptabele kwaliteit levert. De meeste productiewerkbelastingen op enige betekenisvolle schaal passen in deze beschrijving; sommige niet, en verschepen sneller door bij één model te blijven. Beide keuzes zijn verdedigbaar.

Waar je hierna naartoe kunt: Als je de per-model-tariefkaart waar dit artikel op steunt nog niet hebt doorgenomen, is het bijbehorende stuk, The 2026 LLM API Pricing Comparison: GPT-5.5, Claude Sonnet 4.6, Gemini 3.5 Flash and DeepSeek V4, de basis. De prijsdata daar is wat de kostenwiskunde in deze gids concreet maakt voor jouw specifieke werkbelasting.