← terug

10 juni 2026

OpenAI-compatible APIs, de stekker die overal in past

Een ontwikkelaar liet me laatst zien hoe hij zijn applicatie van OpenAI naar een zelf gehost open-source model omzette. Ik verwachtte een middag werk. Het waren twee regels: een andere URL en een andere API-key. De rest van de code bleef exact hetzelfde. De applicatie wist niet eens dat er iets veranderd was.

Dat is geen toeval en geen handigheidje van die ene ontwikkelaar. Het is het gevolg van iets dat de afgelopen jaren stilletjes is gebeurd: het API-formaat van OpenAI is de feitelijke standaard geworden voor praten met taalmodellen. Bijna elke serieuze inference server en bijna elke modelprovider kan ermee overweg. Niet omdat er ooit een commissie over heeft vergaderd, maar omdat iedereen er gewoon mee begon.

Wie begrijpt hoe dat werkt, begrijpt ook waarom wisselen van model of leverancier veel minder eng is dan het klinkt. En waarom het soms toch tegenvalt.

Hoe een productkeuze een standaard werd

Toen OpenAI begin 2023 de API achter ChatGPT openstelde, bouwde de halve wereld er tools omheen. Bibliotheken, frameworks, no-code platforms, plugins: allemaal gingen ze ervan uit dat je met een model praat via het formaat van OpenAI. Een verzoek naar een endpoint dat chat completions heet, met een lijst berichten erin, en een antwoord in een vaste JSON-structuur terug.

Toen er daarna concurrenten en open-source modellen kwamen, stonden die voor een keuze. Een eigen API-formaat verzinnen en hopen dat ontwikkelaars hun code aanpassen? Of het formaat van OpenAI nabouwen, zodat al die bestaande tools meteen werken? De meesten kozen het tweede. Logisch: je wilt dat ontwikkelaars met twee regels code naar jou kunnen overstappen, niet met twee weken refactoren.

Het resultaat zie je nu overal. Open-source inference servers zoals vLLM en llama.cpp serveren modellen via een OpenAI-compatible endpoint. Ollama en LM Studio op je laptop doen het. Europese en Amerikaanse providers zoals Mistral, Together en Groq doen het. Zelfs partijen met een eigen API, zoals Google en Anthropic, bieden er een compatibiliteitslaag naast aan. En model gateways zoals LiteLLM gebruiken het formaat als gemeenschappelijke taal om tientallen providers achter één interface te hangen.

Vergelijk het met een stopcontact. Niemand vindt het ontwerp van een stopcontact spannend. Maar omdat iedereen dezelfde stekker gebruikt, kun je elk apparaat in elke kamer aansluiten. Het API-formaat van OpenAI is het stopcontact van de modellenwereld geworden.

Wat er technisch in zo'n API zit

Het hart van de standaard is het chat completions endpoint. Je stuurt een HTTP-verzoek naar een adres dat eindigt op /v1/chat/completions, met een API-key in de header en een JSON-body. In die body staan drie dingen die ertoe doen.

Ten eerste de modelnaam: welk model moet dit afhandelen. Ten tweede de berichten: een lijst met wie wat zei, elk bericht met een rol (system, user of assistant) en de inhoud. De hele gespreksgeschiedenis gaat elke keer opnieuw mee, want het model onthoudt zelf niets tussen verzoeken. Ten derde de instellingen: hoeveel tokens het antwoord maximaal mag zijn, hoe creatief het model mag zijn, dat soort knoppen.

Het antwoord komt terug in een vaste structuur: het bericht van het model, de reden waarom het stopte, en een telling van hoeveel tokens erin en eruit gingen. Die telling is meteen je kostenadministratie, want providers rekenen per token af.

Dan streaming. Niemand wil dertig seconden naar een lege pagina staren tot het hele antwoord klaar is. Daarom kun je in het verzoek stream: true meegeven. Het model stuurt dan het antwoord in kleine brokjes terug zodra ze gegenereerd zijn, via een techniek die server-sent events heet. Dat woord-voor-woord verschijnen van tekst dat je uit ChatGPT kent, dat is streaming. Voor de gebruiker voelt het snel. Voor de bouwer betekent het dat je code brokjes moet samenvoegen in plaats van één keurig antwoord te ontvangen, en dat is precies waar implementaties onderling beginnen te verschillen. Daarover zo meer.

En dan tool calls, vroeger function calling genoemd. Je vertelt het model welke functies jouw applicatie kan uitvoeren: zoek een klant op, plan een afspraak, haal het weer op. Het model kan dan in plaats van een tekstantwoord een verzoek teruggeven: roep deze functie aan met deze argumenten. Jouw applicatie voert de functie uit, stuurt het resultaat terug, en het model formuleert daarmee zijn antwoord. Dit is het mechanisme onder vrijwel elke AI-agent. Dat dit in het standaardformaat zit, betekent dat agent-frameworks in principe met elk compatibel model kunnen werken.

Naast chat completions horen er meestal nog een paar endpoints bij: een voor embeddings (tekst omzetten naar vectoren, de basis onder RAG) en een om op te vragen welke modellen er beschikbaar zijn.

Dat is het, in de kern. Geen magie. Een afgesproken vorm voor verzoeken en antwoorden, meer niet. Maar juist omdat het zo simpel is, kon iedereen het nabouwen.

Waarom dit voor organisaties uitmaakt

Dit klinkt als een onderwerp voor ontwikkelaars. Het is een onderwerp voor iedereen die beslissingen neemt over AI.

Stel, een advocatenkantoor heeft een interne assistent laten bouwen die dossiers samenvat. Gebouwd op de API van een Amerikaanse provider, want daar begon iedereen. Een jaar later wil het kantoor om vertrouwelijkheidsredenen naar een open-source model dat in Europa draait, op eigen of gehuurde infrastructuur.

In een wereld zonder gedeeld API-formaat was dat een herbouwproject: andere bibliotheek, andere datastructuren, alles opnieuw testen. In de huidige wereld zet je een inference server zoals vLLM op met een open model erop, wijs je de applicatie naar de nieuwe URL en test je of de kwaliteit voldoet. Het meeste werk zit niet meer in de code, maar in het evalueren of het nieuwe model de taak goed genoeg doet. Bij HostYourAI zien we dat patroon constant: de technische overstap naar een Europees gehost model is klein, juist omdat de API hetzelfde spreekt.

Dat verandert je onderhandelingspositie. Een leverancier die weet dat je binnen een week weg kunt, gedraagt zich anders dan een leverancier die weet dat vertrekken je een half jaar kost. En het verandert je architectuur: je kunt verschillende modellen voor verschillende taken inzetten, of gevoelige data naar een eigen model routeren en de rest naar een commerciële provider, zonder per model aparte code te schrijven.

Waar de compatibiliteit ophoudt

Nu de eerlijke kant, want compatibel betekent niet identiek.

Het basisverkeer (berichten erin, antwoord eruit, streaming, tool calls) werkt vrijwel overal. Maar aan de randen rafelt het.

Niet elke parameter wordt overal ondersteund. Sommige servers negeren stilletjes instellingen die ze niet kennen. Je code draait, er komt antwoord, en pas later merk je dat die ene instelling waar je op rekende nooit iets deed. Stilletjes genegeerd worden is verraderlijker dan een foutmelding.

Tool calling is op papier hetzelfde, in de praktijk niet. Of een model betrouwbaar tools aanroept, hangt af van het model zelf en van hoe de server het afdwingt. En streaming gecombineerd met tool calls is een bekende plek waar implementaties van elkaar afwijken: de brokjes komen net anders binnen, en code die bij provider A vlekkeloos werkt, struikelt bij provider B.

Daarnaast heeft elke provider eigen uitbreidingen die buiten de standaard vallen. Strikte structured outputs, waarbij het antwoord gegarandeerd aan een JSON-schema voldoet. Aparte velden voor de redeneerstappen van reasoning-modellen. Prompt caching met eigen regels. Afbeeldingen en audio in berichten. Hoe meer van die extra's je gebruikt, hoe meer je toch weer aan één partij vastgroeit, ook al heet de API compatibel. En OpenAI zelf bouwt inmiddels verder aan een nieuwer eigen formaat, de Responses API, terwijl de rest van de wereld op chat completions is gestandaardiseerd. De standaard is dus een momentopname, geen vaststaand contract.

Tot slot het belangrijkste: hetzelfde API-formaat betekent niet hetzelfde gedrag. Een prompt die maandenlang is bijgeschaafd voor het ene model kan bij een ander model matige antwoorden geven. De stekker past, maar het apparaat aan de andere kant is anders. Wisselen van model is dus nooit alleen een URL aanpassen. Het is een URL aanpassen plus opnieuw evalueren.

Wat dit betekent voor vendor lock-in

De gangbare misvatting is hier: "Alles is toch OpenAI-compatible, dus lock-in bestaat niet meer." Dat klopt maar half.

De lock-in op API-niveau is grotendeels opgelost. Dat is winst, en geen kleine. Maar de lock-in is verhuisd naar andere lagen. Naar je prompts, die op één specifiek model zijn afgestemd. Naar je embeddings, want wissel je van embeddingmodel, dan moet je al je documenten opnieuw door het nieuwe model halen. Naar fine-tunes, die je niet meeneemt naar een andere provider. Naar de providerspecifieke features die net even handiger waren. En naar je evaluaties: als je nooit hebt vastgelegd wat "goed genoeg" is voor jouw taak, kun je een alternatief model niet eens beoordelen, en blijf je dus waar je zit.

Een paar vragen om je eigen situatie te toetsen:

Wie deze vragen kan beantwoorden, heeft echte keuzevrijheid. Wie ze niet kan beantwoorden, heeft alleen het gevoel van keuzevrijheid.

Conclusie

Het API-formaat van OpenAI is de standaard geworden zonder dat iemand het zo besloten heeft, en de hele modellenwereld profiteert ervan. Het is de reden dat je vandaag bij een Amerikaanse provider kunt zitten en volgende maand op een open-source model in Europa, zonder je applicatie te herbouwen. Voor data-soevereiniteit is dat misschien wel de belangrijkste technische ontwikkeling van de afgelopen jaren: de uitweg is geen herbouwproject meer.

Maar de stekker is niet het apparaat. Compatibiliteit op API-niveau lost de code-kant van lock-in op, niet de gedragskant en niet de feature-kant. Wisselen kan, mits je je prompts, je evaluaties en je providerspecifieke afhankelijkheden op orde hebt.

Mijn advies is daarom simpel. Bouw alsof je gaat wisselen, ook als je dat niet van plan bent. Eén configureerbare base URL, een eigen testset, en terughoudendheid met features die maar op één plek bestaan. Dan is de standaard niet alleen een mooi verhaal, maar een deur die voor jou ook echt openstaat. 

↘︎ ALLE ARTIKELEN