“Ondersteunt dit model tool calls?” klinkt als een vraag over het model. Dat is het niet. Het is een vraag over het model en het endpoint waarop je het aanroept — en hetzelfde model kan op het ene ja antwoorden en op het andere nee. Deze pagina legt uit waarom, en hoe Entity Enricher de vraag beslecht door te meten in plaats van een catalogus te geloven.
Stuur de gpt-6-familie van OpenAI een verzoek met function tools naar het klassieke /v1/chat/completions-endpoint en het verzoek wordt regelrecht geweigerd:
400 Bad Request Function tools with reasoning_effort are not supported. Use /v1/responses or set reasoning_effort to 'none'.
Stuur hetzelfde model, dezelfde tools en dezelfde prompt naar /v1/responses en het antwoordt gewoon — op beide kanalen voor gestructureerde uitvoer, met of zonder reasoning effort. Aan het model is niets veranderd. Alleen het adres.
Het gevolg
Een mogelijkheid is geen eigenschap van een model alleen. Het is een eigenschap van een (model, endpoint)-paar. Elke catalogus die één true/false per model opslaat, antwoordt daarom op een vraag die hij niet werkelijk kan zien.
Een route is simpelweg het endpoint waarnaar een verzoek wordt gestuurd. Zelfde provider, zelfde model, zelfde API-sleutel — maar een ander wire-formaat, een andere vorm van het verzoek en andere regels over wat gecombineerd mag worden. OpenAI biedt er twee, en de rest van de industrie kopieerde grotendeels de oudere.
| Route | Vorm van de uitwisseling | Wie het spreekt |
|---|---|---|
Chat Completions /v1/chat/completions2023 | Stateless: je stuurt de volledige lijst met berichten, je krijgt het volgende bericht terug. Tussen aanroepen wordt er niets op de server bewaard. | OpenAI, en de de-facto industriestandaard die vrijwel iedereen heeft gekopieerd — xAI, DeepSeek, Alibaba, Groq, Together, Ollama en de meeste OpenAI-compatibele gateways. |
Responses API /v1/responses2025 | Geeft een lijst met getypeerde items terug — een reasoning-item, een bericht, een function-tool-aanroep, een hosted-tool-aanroep — houdt de state server-side bij en kan reasoning van de ene beurt meenemen naar de volgende. | Alleen OpenAI. Een look-alike endpoint dat de vorm van Chat Completions spreekt, biedt deze niet automatisch ook aan. |
Daarom is “de OpenAI API” tegenwoordig dubbelzinnig: er zijn er twee, ze overlappen, en ze hanteren niet dezelfde regels.
Reasoning-modellen hebben het berichtenmodel gebroken. De interne reasoning van een model is geen bericht: het is niet iets wat het tegen jou heeft gezegd, en niet iets wat jij tegen het model hebt gezegd. Chat Completions heeft alleen een lijst met berichten en dus nergens een plek voor reasoning — en wat het niet kan weergeven, laat het tussen twee beurten vallen.
De Responses API is rond dat gat ontworpen. Reasoning is een volwaardig item in de teruggegeven lijst; het kan versleuteld terugkomen en bij de volgende beurt opnieuw worden meegestuurd, zodat het model verdergaat met zijn eigen denkwerk in plaats van het te reconstrueren.
Een function-tool call is een round trip: het model vraagt om een tool, jouw code antwoordt, het model gaat verder. Op Chat Completions is er geen plek om de reasoning over die round trip te bewaren, dus de voortzetting zou er stilzwijgend zonder hervatten — het model zou het denkwerk waarvoor je al betaald hebt opnieuw moeten doen, en zou dat waarschijnlijk anders doen.
Daarom weigert de provider de combinatie in plaats van stilletjes minder te leveren. De foutmelding is geen beperking van het model; het is de oudere API die toegeeft dat hij geen plek heeft voor wat dit model produceert.
Als elke mogelijkheid hetzelfde endpoint verkoos, zou een route een implementatiedetail zijn waar niemand over hoefde na te denken. Dat is niet zo.
Gestructureerde uitvoer via het tool-kanaal is precies de combinatie die Chat Completions weigert bij een reasoning-model, en de door de provider gehoste web-search-tool wordt alleen daar geaccepteerd.
Ruwe audiobytes meesturen kan de Responses API-route niet aan, dus een model dat audio ondersteunt is alleen via het oudere endpoint bereikbaar.
Eén model, twee mogelijkheden, twee verschillende endpoints. Er bestaat geen enkele true/false die over beide eerlijk is — daarom legt Entity Enricher een mogelijkhedenkaart per route vast, en daarom wordt een run die twee mogelijkheden nodig heeft die op twee verschillende routes leven met naam en toenaam geweigerd in plaats van er stilletjes één te verliezen.
De mogelijkhedentest stuurt geen kunstmatig, handgeschreven verzoek. Hij doorloopt het echte agent-pad — dezelfde code die een verrijkingsrun neemt — met de te testen mogelijkheid geforceerd aan, en laat het antwoord van de provider beslissen. Wat er gemeten wordt, is dus wat de applicatie daadwerkelijk kan, niet wat de API theoretisch zou kunnen accepteren.
De hele reeks — kanalen voor gestructureerde output, vision, PDF, audio, websearch, reasoning en de effort-instelling per aanvraag — draait eenmaal per route die de router kan kiezen. Bij vrijwel elke provider is dat één route, en kost de probe precies evenveel als altijd; alleen de OpenAI-achtige providers, die echt op twee manieren bereikbaar zijn, worden twee keer gemeten.
Een route die zijn eerste platte-tekstaanroep niet beantwoordt, wordt simpelweg niet gemeten, en een getest model wordt daarna alleen naar de routes gerouteerd die wél antwoordden — er is geen terugval op een ander endpoint, niet bij de selectie en niet wanneer een run mislukt. Een model waarvoor geen enkele route antwoordt, wordt buiten gebruik gesteld, en dat geldt ook voor een model waarvan de routes geen van beide structured-output-kanalen dragen: tekst is nooit een terugval, dus zo'n model zou geen enkele verrijking kunnen uitvoeren. Alleen een latere test die een kanaal aantoont, brengt het terug. Mogelijkheden worden nooit gewijzigd omdat een run is mislukt — de test is het enige dat ze meet.
De aanvraag werd geaccepteerd en het model leverde het verwachte soort antwoord.
Vastgelegd als een gemeten true voor die route — en dat weegt zwaarder dan elke gescrapete claim.
De provider heeft de capability expliciet geweigerd, of de client weigerde de aanvraag überhaupt op te bouwen.
De enige uitkomst die een false mag wegschrijven. Een afwijzing is bovendien gratis: er wordt nooit voor gefactureerd.
Iets anders: een rate limit, een ontbrekend toegangsniveau, een timeout, een 5xx van de provider, een onbekende fout.
Er wordt niets vastgelegd, en de volgende test kan het uitsluitsel geven.
De twee fouten kosten niet hetzelfde. Een onterechte unknown kost één hertest: de capability wordt later gewoon opnieuw gemeten. Een onterechte no is stil en permanent — het degradeert het model overal, haalt het uit de keuzelijsten en uit de routeringsbeslissing, en niemand komt ooit te weten waarom. Een niet-herkende fout bewijst dus niets, en wordt ook vastgelegd als iets dat niets bewijst.
Een HTTP 200 bewijst dat het verzoek is geaccepteerd. Het bewijst niet dat het model de bijlage daadwerkelijk heeft gelezen — een provider kan een afbeelding vrolijk accepteren en die doorgeven aan een model dat er nooit naar kijkt. Daarom draagt elke test met een payload er één mee waarvan het antwoord gecontroleerd kan worden:
| Mogelijkheid | Verzonden payload | Gestelde vraag |
|---|---|---|
| Vision | Een effen rode afbeelding | “Welke kleur is dominant?” |
| PDF-invoer | Een PDF met precies één woord | “Welk woord staat er in het document?” |
| Audio-invoer | Een audiobestand met een telbaar aantal tonen | “Hoeveel afzonderlijke piepjes?” |
Twee aparte resultaten, met opzet
Het inhoudelijke antwoord wordt naast het oordeel vastgelegd en zet nooit de mogelijkheidsvlag om. Een klein model dat een rood vierkant verkeerd leest, ondersteunt nog steeds vision — het transport werkte, de modaliteit werd meegenomen, het model was simpelweg zwak. “kan niet” verwarren met “deed het slecht” zou stilletjes een werkende mogelijkheid wissen om één verkeerd woord; door ze apart te houden weet je beide dingen tegelijk.
Publieke modelcatalogi zoals LiteLLM of PricePerToken vermelden mogelijkheden als een plat feit over een model, zonder endpoint erbij. Dat is geen slordigheid — er is geen veld voor. Maar het betekent dat een claim in het algemeen volkomen juist kan zijn en toch onjuist voor het endpoint dat jouw run gebruikt.
“Dit model ondersteunt tool calls.” Ergens waar. Zwijgt over waar. Nuttig als startpunt voor een model dat nog niemand heeft getest.
“Op dit endpoint accepteerde dit model op dit moment tool calls.” Het noemt zijn route, zodat het vergeleken kan worden met de route die een run daadwerkelijk neemt.
De route benoemen is ook wat een meting op termijn eerlijk houdt. Een oordeel dat is gemeten op een endpoint dat het model niet langer gebruikt, is geen beter bewijs dan een claim — het is bewijs over iets anders. Zonder de route die erbij is vastgelegd, zou een oude meting niet te onderscheiden zijn van een actuele en zou die de catalogus overtroeven voor het verkeerde endpoint. Met de route vastgelegd is de meting simpelweg niet van toepassing, en blijft de claim gelden totdat een meting op het juiste endpoint hem vervangt.
Zowel de modelcatalogus in de app als de publieke modelcatalogus heeft een Route-selector naast de filters. Die bepaalt voor welke route de mogelijkheidsiconen op elke rij antwoord geven.
Elke rij geldt voor het endpoint waarop dat model daadwerkelijk wordt aangeboden. Dit is de weergave die overeenkomt met wat je krijgt wanneer je een verrijking uitvoert, en de weergave die je moet lezen tenzij je een specifiek endpoint onderzoekt.
Zet de hele tabel vast op één endpoint en de iconen gelden alleen voor dat endpoint — zo zie je een mogelijkheid verschijnen of verdwijnen terwijl je ertussen wisselt, en zo vergelijk je twee modellen op gelijke voet.
Een model met slechts één bereikbare route toont helemaal geen selector: er is niets te kiezen, en de iconen geven al antwoord voor het enige endpoint dat het heeft. De selector verschijnt precies wanneer de ambiguïteit echt is.
Meestal niets — en dat is precies de bedoeling. Je kiest nooit een route. Je kiest een model en beschrijft je run, en de router kiest het endpoint dat kan bieden wat de run nodig heeft: tools en webzoekopdrachten gaan naar waar ze worden geaccepteerd, een audiobijlage gaat naar waar audio wordt ondersteund.
Het enige geval dat je zult merken, is een echt conflict — bijvoorbeeld websearch vragen én een audiobestand meesturen naar hetzelfde OpenAI-model, omdat geen enkel endpoint beide bedient. Die run wordt expliciet geweigerd, met vermelding van de twee capabilities en wat elke route aankan, in plaats van te draaien en er stilletjes één te laten vallen. Laat één eis vallen of kies een model dat beide bedient, en het gaat gewoon door.
En wanneer een mogelijkheidsicoon je verrast, is de Route-selector de verklaring: je kijkt bijna altijd naar een model waarvan het antwoord afhangt van waar de vraag is gesteld.