"500 models behind one key" klinkt als een marketingzin. Wat verandert er nu echt in je codebase, je authenticatielaag en je maandafsluiting wanneer je vijf providerintegraties samenvoegt tot één OpenAI-compatibel endpoint — en bij welke workloads de trade-off het niet waard is.
De mythe en de realiteit
De homepage van elke LLM-aggregator bevat een variant van dezelfde zin. "Toegang tot 500 modellen achter één sleutel." "Eén API voor elk LLM." "Wissel van provider zonder je code te veranderen." Als je er genoeg leest, gaan de zinnen op elkaar lijken — en een beetje hol klinken. Iedereen die daadwerkelijk een AI-stack met meerdere providers heeft beheerd, weet dat "één endpoint, elk model" een slogan is, geen beschrijving van hoe het systeem zich gedraagt.
De slogan dekt wél een echte architecturale keuze. Er is een wezenlijk verschil tussen je AI-workload draaien tegen vier afzonderlijke providerintegraties en diezelfde workload draaien tegen één geaggregeerd endpoint — en dat verschil is niet alleen gemak. Het verandert hoe je auth-laag eruitziet, hoe je facturering eruitziet, hoe je modelwisselproces eruitziet en hoe je incident response eruitziet. Geen van die veranderingen staat op de marketingpagina. Allemaal duiken ze een maand na je beslissing op in je codebase.
Dit stuk is de versie van dat gesprek waarvan we hadden gewild dat iemand het met ons had gevoerd voordat we onze eerste multi-provider-stack opzetten. Hieronder: de vier dingen die echt veranderen als je consolideert naar één endpoint, de drie dingen die niet veranderen (ondanks de slogan), een concreet codevoorbeeld van hoe "wissel van provider zonder je code te veranderen" er in de praktijk uitziet, en de workloads waarbij de trade-off de andere kant op slaat.
De korte versie: Eén endpoint klapt je auth-, billing- en modelwissel-oppervlak ineen tot één. Het klapt niet het onderliggende modelgedrag, de provider-rate-limits of je compliance-verplichtingen in. De keuze gaat over operationele vorm, niet over magie — en er zijn workloads waar de operationele winst echt is en workloads waar het de trade-off niet waard is.
De vier dingen die daadwerkelijk veranderen
Wanneer een team consolideert van directe toegang tot meerdere providers naar één OpenAI-compatibel endpoint, verschuiven er vier dingen echt. Dit zijn mechanische veranderingen, geen marketingclaims — ze duiken op in je code review, je maandelijkse reconciliatie en je stand-ups over welk model je deze week gebruikt.
1. Je authenticatielaag wordt teruggebracht tot één referentie
Bij directe multi-provider-toegang beheer je afzonderlijke referenties voor elke provider die je aanraakt. Een OpenAI-API-sleutel voor GPT-5.5-calls. Een Anthropic-API-sleutel voor Claude Sonnet 4.6-calls. Een Google AI Studio-credential voor Gemini 3.1 Pro. Misschien een Azure OpenAI-credential als je daar een enterprise-contract hebt. Elk met een eigen rotatiebeleid, een eigen item in je secrets-management, eigen scoperichtlijnen, eigen dashboard voor intrekking.
Bij een geaggregeerd endpoint klapt die hele laag in tot één referentie. Eén sleutel in je secrets manager, één rotatiebeleid, één dashboard voor intrekking. De referentie zelf is een opaque token dat toegang geeft tot de modellen die de aggregator aanbiedt — de auth-complexiteit verhuist van je applicatie naar de accountgrens van de aggregator.
Dit is de verandering die het makkelijkst is om als cosmetisch weg te wuiven en degene met de grootste tweede-orde-effecten. Elke referentie die je draagt is een potentieel lekvector, een rotatietaak, een onboardingstap voor nieuwe engineers en een configbestand waar je CI/CD van moet weten. Vier referenties beheren is niet vier keer zoveel werk als één — het is hetzelfde soort werk, vier keer uitgevoerd, met alle operationele oppervlakte die daarbij hoort.
2. Je SDK blijft hetzelfde — alleen base_url verandert
De belofte van "OpenAI-compatibel" is dat de SDK die je al gebruikt voor OpenAI-calls ook werkt tegen het geaggregeerde endpoint met één regel die verandert. Dit klopt in strikte mechanische zin, en de implicaties zijn het waard om precies te zijn.
Concreet: als je codebase de OpenAI Python SDK gebruikt om GPT-5.5 aan te roepen, vereist de switch naar het aanroepen van Claude Sonnet 4.6 via een aggregator twee veranderingen — de base_url en de model-parameter. De rest van de code — de requeststructuur, de response parsing, de foutafhandeling, de streamingpatronen — blijft identiek. Je tool-use-schema's werken. Je structured-output-requests werken. Je conversatiegeschiedenisformat werkt. Dezelfde code, gericht op een ander endpoint, roept een ander model aan.
Dit is het deel van de architecturale verandering dat engineers de eerste keer het meest verbaast. De aanname bij afzonderlijke providerintegraties is dat elk zijn eigen SDK, eigen responsevorm en eigen eigenaardigheden heeft. Het OpenAI-compatibele endpoint normaliseert dat — elk model achter het endpoint biedt zich via hetzelfde oppervlak aan.
3. Je facturering wordt teruggebracht tot één factuur
Bij directe multi-provider-toegang ziet de boekhouding aan het eind van de maand er zo uit: open het OpenAI-gebruikdashboard, exporteer de factuur, open de Anthropic-console, exporteer de factuur, open Google AI Studio-billing, exporteer de factuur. Daarna reconcilieer je de drie tegen je interne kostentracking, wijs je kosten toe aan de juiste productfeatures of klanten en betaal je de drie afzonderlijke facturen. Voor een klein team is dit een paar uur werk; voor een agency die meerdere klanten factureert, is het een betekenisvol deel van iemands maandafsluiting.
Bij een geaggregeerd endpoint klappen de drie (of vier, of vijf) facturen in tot één. Het kostenvlak volgt nog steeds de onderliggende provider-tarieven — de aggregator maakt calls niet magisch goedkoper — maar de factuur zelf is verenigd. Eén totaal om te betalen, één CSV om te importeren in je boekhoudsysteem, één set gebruiksrecords om toe te schrijven aan klanten of features. Tracking per sleutel, waar de aggregator dat ondersteunt, laat je die ene factuur automatisch opdelen per klant of workflow in plaats van handmatig te reconciliëren.
4. Modelwissels worden configuratiekeuzes, geen engineeringtaken
Dit is de verandering die na verloop van tijd de manier verandert waarop teams opereren, meer dan de andere. Wanneer een nieuw model wordt gelanceerd — en in 2026 gebeurt dit maandelijks — vereist het testen ervan tegen je workload in een directe multi-provider-setup: je aanmelden voor het relevante provideraccount als je dat nog niet hebt, de referentie toevoegen aan je secrets manager, de SDK van de provider integreren als die verschilt van wat je al gebruikt, het nieuwe model door je applicatielogica heen trekken en deployen. Voor een serieuze evaluatie is dit een halve dag tot twee dagen werk.
Bij een geaggregeerd endpoint vereist het testen van een nieuw model tegen je workload: de model-parameter in je code wijzigen, deployen. Misschien tien minuten. De drempel voor "is het de moeite waard om dit nieuwe model te proberen?" daalt drastisch. Teams die op geaggregeerde endpoints draaien testen meer modellen, wisselen vaker en eindigen met beter passende keuzes voor hun workload omdat de switch-kosten niet langer bepalend zijn.
De drie dingen die niet veranderen
De marketingtekst op aggregatorpagina's overschat de consolidatie vaak door te impliceren dat alles aan multi-provider-AI eenvoudiger wordt. Drie dingen veranderen opvallend níet, en het expliciet benoemen daarvan maakt de rest van het argument geloofwaardig.
- De kwaliteit van de onderliggende modellen. GPT-5.5 via een aggregator routeren verandert niet wat GPT-5.5 produceert. Het model is hetzelfde model. Aggregators verbeteren outputs niet (en serieuze doen ze ook niet slechter). Als je workload specifiek Claude Sonnet 4.6 vereist vanwege zijn tool-use-gedrag, dan blijft die eis bestaan of je Claude nu direct aanroept of via een aggregator — het model zelf doet het werk.
- Rate limits op providerniveau. Een aggregator poolt verzoeken via zijn eigen infrastructuur, maar de onderliggende providers handhaven nog steeds rate limits op modelniveau. Als OpenAI GPT-5.5 afknijpt op een bepaalde TPM (tokens per minuut), dan geldt dat plafond nog steeds voor verkeer via de aggregator — al hangt de toepassing ervan af van hoe de aggregator zijn providercapaciteit verdeelt over zijn klantenbestand. Voor workloads met hoog volume: vraag de aggregator hoe rate-limit-pooling werkt voordat je integreert; sommige aggregators geven elke klant dedicated quota, andere delen.
- Je compliance-verplichtingen. Als je applicatie gereguleerde data verwerkt (PHI, financiële transacties, EU-persoonsgegevens met specifieke residency-eisen), maakt de aggregator nu deel uit van je datastroom en moet die als zodanig worden beoordeeld. Een verenigd endpoint ontslaat je niet van dataresidency-regels, verwerkersovereenkomsten of vendor due diligence. Voor de meeste workloads is dit eenvoudig; voor gereguleerde workloads is het een betekenisvol stuk werk en de moeite waard om te doen voordat je migreert.
Dit expliciet benoemen is belangrijk omdat dit de beperkingen zijn die bepalen of de architectuur geschikt is voor jouw use case. De vier veranderingen die wél gebeuren zijn echt en waardevol voor de meeste workloads; de drie beperkingen die niet veranderen vertellen je wanneer je directe provider-toegang moet behouden.
Hoe "providers wisselen zonder je code te wijzigen" er in de praktijk uitziet
De duidelijkste manier om te laten zien hoe dit werkt, is dezelfde code te bekijken die drie verschillende modellen aanroept. Hieronder: hetzelfde Python-script, dezelfde OpenAI SDK, dezelfde requeststructuur — die GPT-5.5, Claude Sonnet 4.6 en Gemini 3.1 Pro aanroept door één string te wijzigen.
from openai import OpenAI
import os
# Eén client. Eén credential. Eén base-URL.
client = OpenAI(
api_key=os.environ["COMET_API_KEY"], # of vervang door je eigen API-sleutel
base_url="https://api.cometapi.com/v1"
)
prompt = "Vat de belangrijkste risico's in dit contract samen."
# Dezelfde code, drie verschillende modellen — wijzig alleen de modelstring.
for model in ["gpt-5.5", "claude-sonnet-4-6", "gemini-3.1-pro"]:
response = client.chat.completions.create(
model=model,
messages=[
{
"role": "user",
"content": prompt,
}
],
)
print(f"\n--- {model} ---")
print(response.choices[0].message.content)
Drie observaties over wat deze code wel en niet doet.
Het werkt zonder iets te herschrijven. De OpenAI SDK doet precies wat hij doet voor OpenAI-calls — de request body bouwen, ondertekenen met de API-sleutel, de response afhandelen. Het aggregator-endpoint spreekt het OpenAI-protocol, dus de SDK weet niet en het kan hem ook niet schelen dat hij met een andere service praat. Als je een bestaande codebase hebt die al is gestructureerd rond de OpenAI SDK, is dit een tweeregelige config-wijziging in je client-initialisatie.
Het werkt ook voor de patronen voorbij de simpele chat-call. Tool-use, structured outputs, streaming, functieaanroepen, vision-invoer — het OpenAI-compatibele protocol dekt dit alles, en serieuze aggregators implementeren het volledige oppervlak. Het voorbeeld hierboven is bewust minimaal, maar het patroon strekt zich uit tot de geavanceerdere gebruiken waar productieapplicaties op vertrouwen.
Het vlakt model-specifieke eigenaardigheden niet uit. Claude gaat anders om met system-prompts dan GPT-5.5. Gemini telt tokens anders. Deze verschillen zijn modelverschillen, geen SDK-verschillen, en ze blijven bestaan via de aggregator. Als je van model wisselt, werkt de API-call — maar het outputgedrag kan verschuiven op manieren die je in je prompt engineering moet ondervangen. Het begeleidende stuk, What No Benchmark Tells You, behandelt precies dat — de gedragspatronen die elk model vertoont en die benchmarks niet vangen.
Waar dit het snelst verlichting biedt
Niet elke workload profiteert in gelijke mate van consolidatie. Drie patronen waar de geaggregeerde-endpoint-benadering het snelst rendeert:
Productieworkloads met meerdere modellen
Als je applicatie al meer dan één provider aanroept — RAG met GPT-5.5 voor synthese en Claude voor re-ranking, bijvoorbeeld, of een contentpijplijn die Gemini gebruikt voor extractie en GPT voor samenvatting — haalt het geaggregeerde endpoint de operationele overhead weg van het afzonderlijk beheren van die providers terwijl de modelkeuzes ongewijzigd blijven. De besparingen zijn onmiddellijk: één referentie, één factuur, één set foutpatronen om te leren. Dit is het workloadpatroon waarvoor aggregators zijn ontworpen en waar de architecturale winst het meest direct is.
Prototyping- en evaluatiecycli
Teams die actief modellen evalueren — kiezen tussen providers voor een nieuwe feature, beslissen of ze migreren naar een nieuwe modelrelease, A/B-testen van twee modellen tegen dezelfde workload — profiteren enorm van het wegvallen van de setupkosten. Directe multi-provider-toegang vereist dat je accounts, referenties en integraties opzet voor elk model dat je wilt evalueren voordat je één vergelijking kunt draaien. Geaggregeerde toegang maakt evaluatie een config-wijziging. Teams die prototypen tegen geaggregeerde endpoints testen 3–5x meer modelopties dan teams met directe integraties, en de beter passende keuzes waar ze op uitkomen weerspiegelen dat.
Model-lanceringen
Wanneer een belangrijk nieuw model wordt gelanceerd — en in 2026 gebeurt dit meerdere keren per kwartaal — zijn de teams die het binnen enkele uren tegen hun productie-workload hebben draaien degenen op geaggregeerde endpoints. De aggregator voegt het nieuwe model toe aan zijn catalogus; de test is een wijziging van de model-parameter; de vergelijkingsdata zijn er aan het eind van de dag. Teams met directe providerintegraties moeten zich aanmelden bij de nieuwe provider (indien van toepassing), de integratie bouwen en het model door de applicatie heen trekken. Tegen de tijd dat ze een eerlijke vergelijking hebben, is de nieuwscyclus alweer verder.
Wanneer het aggregatorpatroon niet rendeert
De eerlijke tegenhanger. Drie workloadpatronen waar directe provider-toegang echt de juiste keuze is, en een geaggregeerd endpoint weinig toevoegt of tegen je werkt:
- Single-model-workloads op zeer hoge volumes. Als je 100% van je verkeer op het vlaggenschipmodel van één provider draait, op een volume dat groot genoeg is om een enterprise-contract met maatwerkprijzen te bedingen, is direct gaan goedkoper. De waarde van de aggregator zit in het ineenklappen van meerdere integraties; als er maar één is, valt er niets in te klappen. Het onderhandelde tarief van de provider verslaat het doorgeef-tarief van de aggregator.
- Gereguleerde omgevingen waar de vendor-of-record ertoe doet. Sommige compliancekaders vereisen dat je een directe contractuele relatie onderhoudt met de dataverwerker — en routeren via een aggregator introduceert een vierde partij (de aggregator zelf) in die relatie. Voor gereguleerde workloads in de zorg, financiën of specifieke overheidscontexten kan dit het vendor-due-diligence-gesprek zo compliceren dat directe toegang operationeel eenvoudiger is, zelfs al vergt het meer integratiewerk.
- Workloads die afhankelijk zijn van provider-specifieke features buiten het OpenAI-compatibele oppervlak. Als je applicatie Claude's tool_choice prompt-caching-modi gebruikt, Gemini's grounding-with-Google-Search of een andere mogelijkheid die buiten het OpenAI-compatibele API-oppervlak valt, dan kan een aggregator die alleen het OpenAI-compatibele subset blootstelt die features niet bereiken. Sommige aggregators stellen naast de OpenAI-compatibele API ook provider-native API's bloot; als je workload provider-specifieke mogelijkheden nodig heeft, controleer dan het oppervlak voordat je aanneemt dat geaggregeerde toegang dit dekt.
Geen van deze patronen is een showstopper — de meeste productieteams hebben een mix van workloads, waarvan sommige in het aggregatormodel passen en sommige niet. De eerlijke framing is dat de aggregator een tool is, geen doctrine. Gebruik hem waar hij rendeert; behoud directe provider-toegang waar de trade-off de andere kant op gaat.
De architecturale beslissing
De meeste teams komen laat uit bij de aggregatorvraag — nadat ze al met twee of drie providers direct hebben geïntegreerd, de operationele last voelen en zich afvragen of de consolidatie de migratie waard is. De juiste vraag in die situatie is niet "is de aggregator beter dan directe toegang?" maar "is mijn workload er een waarbij de consolidatie rendeert?"
Een praktische checklist met vier vragen:
- Met hoeveel providers ben ik nu geïntegreerd? Als het antwoord één is, voegt het aggregatorpatroon complexiteit toe zonder voordeel. Als het antwoord twee of meer is, gaat de consolidatielogica spelen.
- Hoe vaak wil ik modellen testen of wisselen? Als je workload vastzit aan één of twee modellen en waarschijnlijk de komende 12 maanden niet verandert, is het wisselkostvoordeel van aggregatie klein. Als je verwacht maandelijks of per kwartaal nieuwe modellen te evalueren, componeert het wisselkostvoordeel over het jaar.
- Factureer ik klanten of wijs ik kosten toe aan productfeatures? Zo ja, dan is de per-sleutel-billing die aggregators ondersteunen een betekenisvolle operationele besparing. Zo nee — ben je een solodeveloper met één product en één rekening — dan is het facturatievoordeel kleiner maar nog steeds reëel.
- Hebben een van mijn workloads compliance-, volume- of provider-specifieke-featurebeperkingen die directe toegang vereisen? Zo ja, identificeer op welke workloads ze van toepassing zijn en behoud voor die specifiek directe toegang. De rest kan naar de aggregator.
Het eerlijke antwoord voor de meeste productieteams in 2026 — die multi-model-workloads draaien, regelmatig nieuwe modelreleases evalueren en een zekere kostenattribuering per klant of feature doen — is dat het aggregatorpatroon rendeert. Het eerlijke antwoord voor solodevelopers met single-model-workloads, of voor teams met harde regulatoire beperkingen, is dat directe toegang de betere keuze blijft. De architectuur moet bij de workload passen, niet bij de marketing.
Waar dit je laat
"500 models behind one key" is een slogan die echt werk verricht voor de onderliggende architecturale beslissing. De slogan doet de marketing; de beslissing gaat erover of het ineenklappen van je auth-, facturatie- en modelwissel-oppervlakken je meer oplevert dan het kost aan compliance- en provider-specifieke-feature-trade-offs. Voor de meeste multi-model-productieworkloads is het antwoord ja; voor single-model-gereguleerde workloads is het antwoord nee. De eerlijke framing is weten welk type workload je hebt, en daar je architectuur op afstemmen.
Als je het aggregatorpatroon evalueert: de makkelijkste manier om de architecturale verandering te testen zonder te migreren is een nieuwe feature, of een niet-kritische workload, naar het geaggregeerde endpoint te wijzen en die een maand te draaien. De credential-wijziging is een paar regels code; de facturatiewijziging is zichtbaar aan het eind van de maand; de operationele verandering duikt op in je stand-ups wanneer iemand opmerkt dat hij deze week geen nieuw provideraccount hoefde op te zetten.
Klaar om betrouwbaar te integreren? Ga naar CometAPI en de API-documentatie voor naadloze toegang tot Claude Fable 5 naast andere frontiermodellen, verenigde billing en betrouwbaarheid op enterprise-niveau. Meld je vandaag aan en start met gulle credits voor nieuwe gebruikers — je volgende doorbraakproject wacht.