De model-ID-loterij: dezelfde aanvraag, verschillende trekking

Achter een multi-provider gateway specificeert een model-ID niet welke service jouw aanvraag afhandelt. Het verwijst naar een set van implementaties met verschillende configuraties voor het serveren, en tenzij je één provider vastzet, is elke aanvraag een trekking uit die set. Wij hebben dit op de harde manier gemeten: tijdens onze evaluatie van moonshotai/kimi-k2.5 via OpenRouter (186 calls, gestart op 2026-04-22, laatste rondes in de dagen erna), produceerde dezelfde aanvraagconfiguratie, dezelfde model-ID, dezelfde provider: { sort: "latency" }-hint, dezelfde set van tien prompts, een mediaan van 312 ms tijd-tot-eerste-token met nul gestreamde redenatie-tekens in één ronde, 10 van de 10 calls, en 3.073 ms met een mediaan van 2.627 tekens aan redenatie in een latere ronde, opnieuw 10 van de 10. Een andere provider diende dezelfde ID af met materieel ander gedrag, zonder dat wij onze code hadden aangepast. De metadata van het antwoord noemt de gebruikte provider, mits je dat logt; niets geeft aan dat het gedrag veranderd is.

De scherpere bevinding is dat de routeringsvlag die we verwachtten om dit precies te voorkomen, dat in onze tests niet deed. Als jouw product afhankelijk is van de diepgang van de redenatie, dan is de model-ID in jouw configuratie niet wat je hebt ingezet. Wat je hebt ingezet, is een loterijbriefje, en de routeringscontroles van de gateway zijn hints om te verifiëren, niet contracten om op te vertrouwen.

Dezelfde aanvraag, twee keer

Wij waren bezig met het benchmarken van kandidaat-modellen voor een compliance-assistent, dus elke configuratie draaide dezelfde prompt-sets: tien standaard compliance-prompts (leg ISO 27001 Annex A.5.1 uit, GDPR Artikel 32, SOC 2 CC6.1, etc.) en vijf moeilijke prompts gebouwd voor multi-framework synthese, het soort vraag waarbij de diepgang van de redenatie echt zichtbaar wordt. Voor elke call registreerden we tijd-tot-eerste-token, totale tijd, gestreamde redenatie-tekens, gestreamde inhouds-tekens en het provider-veld dat OpenRouter teruggeeft in elk stream-chunk.

Met sort: "latency" stuurde een vroege ronde alle tien de standaard-set calls naar één hostende provider (BaseTen): 312 ms mediaan tot het eerste token, nul gestreamde redenatie-tekens bij elke call. In een latere ronde, dagen later, stuurde dezelfde aanvraagconfiguratie alle tien de calls naar een andere provider (ModelRun): 3.073 ms mediaan, 2.627 redenatie-tekens mediaan. Een nog latere ronde stuurde terug naar de eerste. Dit is wat sort: "latency" in ontwerp doet. De documentatie van OpenRouter over provider-routering (geraadpleegd op 2026-07-15) zegt dat met een expliciete sort, "load balancing wordt uitgeschakeld en de router zal providers in volgorde proberen", gerangschikt op gemeten latentie. Gemeten latentie verandert, dus de volgorde verandert, en daarmee in onze tests, of er überhaupt redenatie-output verschijnt.

Een vertienvoudiging van de latentie is vervelend. Een gedrag dat onder een stabiele model-ID aan en uit gaat, is een ander soort probleem, omdat niets je dat vertelt. Elk antwoord was een HTTP 200 met vloeiende inhoud en plausibele token-telling.

De vlag die we verwachtten om het te vangen

Wij accepteerden het resultaat zonder redenatie niet zomaar. We probeerden de redenatie af te dwingen op het snelle pad met elke parameter die de API biedt: reasoning: { enabled: true }, reasoning: { effort: "high" }, reasoning: { max_tokens: 1024 }. Nul gestreamde redenatie-tekens, elke keer, telkens wanneer de aanvraag werd afgehandeld door die provider.

Toen grepen we naar de routeringscontrole. De documentatie van OpenRouter beschrijft require_parameters als volgt: "Wanneer je require_parameters op true zet, wordt de aanvraag niet eens naar die provider gerouteerd", verwijzend naar providers die niet alle parameters in jouw aanvraag ondersteunen (documentatie over provider-routering, geraadpleegd op 2026-07-15). We zetten require_parameters: true naast reasoning: { effort: "high" }. De aanvraag werd toch naar dezelfde provider gerouteerd, en het antwoord bevatte opnieuw geen redenatie-tekst.

Voordat we conclusies trokken, verifieerden we onze parameterindeling tegen bekende-werkende implementaties, omdat "het model redeneert niet" en "deze endpoint biedt geen redenatie" er vanaf de buitenkant hetzelfde uitzien. Gepind naar DeepInfra produceerde dezelfde model-ID 3.116 redenatie-tekens zonder vlag en 3.807 met reasoning: { enabled: true }. Gepind naar Novita: 3.460 tekens. Die runs lossen de vraag op die ertoe doet: de model-familie redeneert, onze aanvraagsyntaxis was geldig, en de serverende endpoint, niet het model, was de variabele.

Om precies te zijn over wat dit laat zien en wat niet: require_parameters is gedocumenteerd als een filter voor providers op basis van parameterondersteuning, en aan de hand van de antwoorden alleen kunnen we niet zeggen of onze resultaten zonder redenatie weerspiegelden dat de endpoint de capaciteitsmetadata van de provider had, de parameterafhandeling aan de provider-kant, of een serverende configuratie die simpelweg geen redenatie-tekst exposeert. Een endpoint dat geen redenatie exposeert kan een bewuste en legitieme keuze zijn; een 312 ms eerste token is een echt product om aan te bieden, en nul gestreamde redenatie-tekens bewijst alleen dat er geen redenatie aan ons werd getoond, niet dat er geen berekening plaatsvond. Wat we kunnen zeggen is beperkter en nuttiger: in onze tests van april 2026 zorgde het declareren van de redenatie-parameter als vereist er niet voor dat we naar een endpoint werden gerouteerd waarvan de antwoorden redenatie-output bevatten. Wat de mechanismen ook zijn, het praktische contract dat we dachten te hebben, hield niet stand, en alleen outputmeting vertelde het ons.

Waarom een compliance-product het opmerkt, en waarom dat bij jou misschien niet zo is

Hier komt het ongemakkelijke deel, ronduit gesteld: op onze vijf moeilijke prompts zag de configuratie zonder redenatie er nog steeds competent uit. Vraag om control overlaps en een conflict tussen ISO 27001, GDPR Artikel 32 en PCI DSS voor een SaaS-bedrijf met 50 medewerkers, en het produceerde gestructureerde analyse met specifieke clausuleverwijzingen, zoals vastgelegd in onze run-notes: ISO 27001 Annex A controls A.9.1 tot A.9.4, GDPR Art. 32(1)(a), PCI DSS requirements 3.4 en 4.1. Let op de rimpel in de vloeiendheid: A.9.x is de nummering van de vervallen ISO/IEC 27001:2013-editie; de revisie van 2022 herstructureerde Annex A. Het antwoord las autoritair en droeg een veroudering op editieniveau met zich mee die niets in het antwoord markeert; wij zagen het alleen door de nummering te controleren tegen de revisie van 2022. Dat is de vorm van falen in het klein: vloeiend, gestructureerd, specifiek, en stilzwijgend niet het gedrag dat je had geconfigureerd. Als onze evaluatie "kijk even naar een paar antwoorden op duidelijke fouten" was geweest, was het verlies van redenatie-output onzichtbaar gebleven. Het kwam aan het licht omdat we redenatie-tekens per call als eersteklas metric logden, en de kolom ging naar nul.

De rest van de kimi-familie-scan versterkte hoe verschillend elke route faalt. De dedicated thinking-variant (moonshotai/kimi-k2-thinking) produceerde redenatie-output bij elke moeilijke prompt (mediaan 4.103 tekens), maar raakte 178.618 ms tot het eerste token bij één diep-redenerende prompt, drie minuten starend naar een spinner. Gepind naar kimi-k2.5 op een redenatie-capabele provider (Inceptron) produceerde echte redenatie, maar faalde 2 van de 5 moeilijke prompts ronduit: het antwoord verbruikte het volledige 2.048-token budget aan redenatie en gaf nul inhoud. Snel zonder redenatie-output, redenatie zonder begrensde latentie, of redenatie die de inhoud uithongert. Drie faalmodi binnen één model-familie, en geen van hen zichtbaar in de IDs. We zijn weggegaan van elk van deze paden voor productie.

Voor een compliance-assistent zijn de inzetten specifiek: het antwoord voedt een risicobeoordeling of een audit-antwoord, en een antwoord kan autoritair overkomen terwijl het precies de veroudering draagt waar een auditor naar zoekt. "Vloeiend, maar niet het gedrag dat je hebt geconfigureerd" is de ergste vorm van falen in dit domein, omdat niets in het antwoord het als falen markeert. De eigen technische blog van OpenRouter erkent de kwaliteitskant van deze variatie: "Sommige providers serveren zwaarder gekwantiseerde varianten van een model die slechter presteren dan dezelfde model gehost elders" (How OpenRouter Model Routing Works, gepubliceerd op 2026-06-12). Onze data voegt een gedragsdimensie toe aan dat plaatje: niet alleen hetzelfde model slechter serveren, maar redenatie-output aanwezig of afwezig achter één stabiele ID.

De model-ID-loterij

Dat is het genoemde idee, en het mentale model dat we nu toepassen op elke gateway-integratie: wanneer één model-ID load-balanced over providers met verschillende serverende configuraties, is elke aanvraag een loterijtrekking, en de geprinte naam op het briefje is het minst informatieve ding erover. De model-ID vertelt je de gewichtenfamilie. Het vertelt je niet de kwantisering, de latentieverdeling, of redenatie-output zal verschijnen, of de parameters die je als vereist hebt gemarkeerd zullen worden weerspiegeld in wat terugkomt. Dat zijn eigenschappen van de (model, provider, dag)-drievoud, en twee van de drie variabelen liggen buiten jouw configuratiebestand.

De draagbare checklist

Als je LLM-verkeer routeert via een multi-provider gateway, niet alleen OpenRouter:

• Log gedragsoutputs als eersteklas metrics. Redenering-tekens of tokens per call, naast latentie, gekoppeld aan de serverende provider die het antwoord rapporteert. Een gedrag dat niet per-antwoord wordt gemeten, kan verdwijnen zonder dat iemand het merkt. Waarschuw bij instorting in productie, niet alleen in evals.
• Behandel routerings- en parameter-vlaggen als hints tot je ze hebt bevestigd tegen de output. Stuur een aanvraag die een capaciteit vereist, controleer dan welke provider het bediende en of de capaciteit daadwerkelijk in het antwoord verscheen.
• Voordat je concludeert "dit model kan geen X", pin een bekende-werkende provider en A/B de vlag. Onze aanvraag was de hele tijd geldig; de serverende endpoint was de variabele. Zonder de gepinde verificatie hadden we het model de schuld gegeven.
• Herhaal routering over uren en dagen, niet binnen één sessie. Tien van de tien naar één provider op dinsdag is een steekproef, geen eigenschap. Onze oscillatie verscheen pas over rondes dagen later.
• Discrimineer met moeilijke prompts en rapporteer verdelingen. Onze tien makkelijke prompts produceerden antwoorden die we niet betekenisvol konden rangschikken; alleen de vijf moeilijke prompts scheidden de antwoordkwaliteit over configuraties, en mediaan verstopte de 178-seconden staart. De max-kolom is waar de niet-scheepbare configuraties leven.
• Als deterministisch gedrag ertoe doet, pin de provider en herverifieer op een schema. Pinnen verruilt failover en soms latentie. Voor een gereguleerd domein is dat vaak de juiste trade-off.

Beperkingen

Dit is één evaluatie: 186 calls, 5 tot 10 prompts per configuratie, op onze compliance-prompt-set, gestart op 2026-04-22 met laatste rondes in de dagen erna (we registreerden de evaluatiedatum, niet de per-rondetijdstippen). Elk getal hier is onze eigen meting op onze eigen taken binnen dat venster, geen claim over het huidige gedrag, configuratie of intentie van een leverancier. Model-identificatoren zijn de publieke gateway-IDs zoals aangevraagd op dat moment; we hebben geen onafhankelijke onderliggende modelrevisies geregistreerd. Serverende implementaties, de routeringslogica van OpenRouter en de documentatie die we citeren (geraadpleegd op 2026-07-15) kunnen allemaal sinds die tijd veranderd zijn. De require_parameters-observatie is één model op één provider-paar; we hebben het niet over de hele catalogus heen uitgebreid. Nul gestreamde redenatie-tekens betekent dat er geen redenatie in het antwoord werd getoond, niets meer. En de steekproefgroottes zijn beslissingsniveau voor onze scheepsbeslissing, richtinggevend voor die van jou. Waarin we zeker zijn, is het mechanisme: wanneer serverend gedrag per provider varieert achter een stabiele ID, is de enige capaciteit die je daadwerkelijk hebt degene die je meet aan de uitgang.

De model-ID in jouw configuratie is een naam voor een verdeling. Meet de trekkingen.