Methodologie

Prompt: Een vaste instructie die op ongeveer 500 outputtokens mikt. Dezelfde prompt wordt voor elk model in elke testcyclus gebruikt.

Runs: 3 opeenvolgende calls per testcyclus. We meten end-to-end latency (eerste byte tot laatste byte), niet TTFT.

Metrics: P50 (mediaan) en P95 (staart) over de 3 runs. P50 is het kopcijfer; P95 toont consistentie.

Meetlocatie: EU — Amsterdam (AMS). Alle resultaten zijn EU-latency. Resultaten vanuit de VS of Azië zouden afwijken.

Snelheidsklassen:

Status: Live sinds mei 2026. 13,593 gescoorde runs in 6 categorieën en 4 providers. Nieuwe runs elke 6 uur naast de snelheids- en beschikbaarheidstests.

Judge-model: Claude Sonnet 4.5 fungeert als onpartijdige judge. De naam van het geëvalueerde model staat nooit in de judge-prompt — alleen de ruwe antwoordtekst wordt gescoord (blinde review).

Scoring: Elke prompt krijgt één enkele kwaliteitsscore tussen 0 en 100 van de judge, plus een classificatie (correct / gedeeltelijk / onjuist). De judge evalueert feitelijke juistheid, volledigheid, redeneerkwaliteit en formaatconformiteit als één gecombineerde rubric. Categorie-gemiddelden zijn zichtbaar op modelpagina's.

Zes prompt-categorieën:

Totale kwaliteitsscore: Ongewogen gemiddelde van alle gescoorde runs voor een model over alle categorieën.

Statische benchmarks meten een model aan een vaste lat. De arena meet modellen onderling, op realistische klantenservice-scenario's, beoordeeld door een panel van concurrerende modellen. Dit levert iets op wat één score niet kan geven: een relatieve rangschikking met een onzekerheidsmarge.

Waarom dit de statische benchmarks aanvult (en niet vervangt):

• Statische tests geven absolute kwaliteit per categorie; de arena geeft head-to-head sterkte en een afweging van kosten versus kwaliteit op realistische taken.
• De arena vangt dingen op die een 0–100 score mist: consistentie over meerdere beurten, hoe een model omgaat met vervolgvragen en — bij councils — of samenwerking daadwerkelijk loont.
• De race op het scherm is een manier om het duel te volgen. Het resultaat wordt altijd bepaald door het panel, nooit door de gezondheidsbalken.

Scoring verloopt in twee fasen. Tijdens de wedstrijd houdt één snelle scheidsrechter een lopende telling bij; aan het einde stemt een onafhankelijk panel van judges over de winnaar.

Fase 1 — live, per beurt: Eén snelle, bewust goedkope judge (gpt-4o-mini) scoort elk antwoord op een 0–10 schaal in één call. Dit voedt alleen de live race-banen — het is indicatief, niet beslissend.

Fase 2 — einde van de ronde, het panel: Een panel van 3–5 judges uit verschillende modelfamilies stemt onafhankelijk over de winnaar op een 0–100 schaal. De meerderheid wint; bij gelijkstand beslist de hoogste gemiddelde panelscore, dan deterministisch op laagste model-id.

Blind op index: Modelnamen worden verwijderd uit de panelprompt — deelnemers worden alleen aangeduid met nummer/index, zodat het panel geen bekende merknaam kan begunstigen.

Vaste drempelwaarden: Een model ontvangt een upvote (▲) wanneer een judge het ≥60 scoort. Een beurt wordt als beslissend aangemerkt wanneer de winnaarsmarge ≥30% van de scoreschaal bereikt. Deze vaste waarden bepalen de tellingen die je ziet.

Elk model heeft een geschat vaardigheidsniveau μ (mu) en een onzekerheid σ (sigma). Een nieuw model begint op μ=25, σ=8.333 — hoge onzekerheid. Elke wedstrijd verschuift μ richting de werkelijke kracht van het model en verkleint σ. Twee modellen met dezelfde μ maar verschillende σ zijn niet gelijk: degene met een lage σ is bewezen, de andere is nog steeds een schatting.

De constanten die we daadwerkelijk gebruiken: Beginrating μ=25, σ=8.333; vaardigheidsvariatie BETA=4.167; per-wedstrijd drift TAU=0.0833. Deze zijn vast in de code en identiek voor elk model.

Hoe we momenteel sorteren — eerlijk openbaar gemaakt: Het leaderboard sorteert op ruwe μ (geschatte kracht). Een striktere bewezen rangschikking zou sorteren op de conservatieve μ − 3σ. Omdat dit vroege data is — de meeste modellen hebben slechts een paar wedstrijden — is σ nog groot, zodat de top van het leaderboard nog kan verschuiven. We tonen de schatting en vertellen dat het een schatting is, in plaats van ons achter één getal te verschuilen.

Een ronde kan een goedkope council van kleinere modellen plaatsen tegenover één duur frontier-model. In een council is het antwoord van elke beurt de consensussynthese van de leden. Zo kan de arena een vraag beantwoorden die één score niet kan stellen: kan een goedkope council een duur frontier-model verslaan — en zo ja, met hoeveel?

Hoe besparingen worden berekend: Wanneer een council zowel een ronde wint als goedkoper is dan het frontier-model dat het versloeg, tonen we het verschil als besparing. Een council-overwinning is gekoppeld aan de groep, nooit aan het leaderboard van een individueel lid, zodat een groepsresultaat de rangschikking van één model nooit opblaast.

Beste-geval-voorbehoud: Besparingen tellen alleen op uit rondes die de council won. Councils die verloren (en dus voor niets geld uitgaven) worden niet afgetrokken. Het getal is daarmee een beste-geval-besparing in de gewonnen rondes — geen nettoresultaat.

Een model wordt op twee afzonderlijke manieren gemeten, en de twee kunnen van elkaar afwijken zonder dat een van beide fout is — ze meten verschillende dingen.

Arena-reputatie (relatief): TrueSkill op basis van head-to-head speloverwinningen. Het rangschikt een model ten opzichte van concurrenten op realistische scenario's.

Neutrale-judge-reputatie (absoluut): Hoe vaak een model als correct / gedeeltelijk / fout wordt beoordeeld in de terugkerende intelligentietest, aan de hand van een vaste rubric in plaats van een tegenstander.

Een model kan wedstrijden verliezen maar toch een hoge correctheidsreputatie hebben, of wedstrijden winnen terwijl het op absolute nauwkeurigheid slechts gedeeltelijk scoort. We houden ze bewust gescheiden.

Een blind spot is een belangrijk punt dat één deelnemer mist terwijl ≥2 anderen het wel behandelen — het is dus aantoonbaar belangrijk, geen randdetail.

Bevestigd door het panel: Een blind spot telt alleen wanneer ≥2 paneljudges onafhankelijk overeenstemmen over dezelfde omissie. Eén judge stelt de aspectenlijst en een mis-matrix op; de andere judges vullen dezelfde vastgezette aspecten in, en een gemis wordt alleen bevestigd wanneer ten minste twee matrices het eens zijn over die cel.

Status: Deze detectie is live en wordt uitgerold over rondes. We publiceren nog geen aantallen — we tonen liever geen getal dan een getal dat nog onvoldoende door data wordt onderbouwd.

Elke telling op de arena-pagina's volgt uit een kleine set vaste keuzes. We vermelden ze hier zodat de getallen controleerbaar zijn.

Zaken die een kritische lezer expliciet wil zien — beperkingen, bekende vooroordelen en keuzes die de getallen bepalen.

Vroege data, volatiele rangschikkingen: De arena is jong. De meeste modellen hebben slechts een paar wedstrijden, zodat een enkele overwinning of verlies μ flink kan verschuiven en rangschikkingen nog instabiel zijn. We tonen het aantal wedstrijden en de onzekerheid in plaats van te suggereren dat de volgorde vaststaat.

Sortering op ruwe μ: Het leaderboard sorteert op ruwe μ, niet op de conservatieve μ − 3σ. Bij hoge onzekerheid betekent dit dat een model met één gelukkige overwinning boven een meer bewezen model kan staan. We behandelen de huidige volgorde als 'geschat, nog niet bewezen'.

Judge-overeenstemming is geen correctheidsmaat: Het judge-overeenstemmingscijfer meet hoe vaak de keuze van een judge overeenkwam met de panelwinnaar — maar de winnaar is de meerderheid van diezelfde judges. Het meet conformiteit aan het panel, niet of het panel gelijk had. Een correcte maar eigenzinnige judge scoort hier laag.

Besparingen zijn beste geval: Besparingen tellen alleen rondes die de council won en goedkoper was; verloren councils worden niet afgetrokken. Lees het als een beste-geval-getal in de gewonnen rondes, geen nettobesparing.

Zelf-voorkeur van enkelvoudige judge in de intelligentietest: De terugkerende intelligentietest draait op één primaire judge (Claude Sonnet 4.5), die ook Claude-familiemodellen kan beoordelen — zelf-voorkeur is een bekende LLM-bias. Er bestaat een secundaire cross-check-judge om dit te kalibreren, en de arena dempt het verder met een cross-family panel; de enkelvoudige-judge intelligentietest heeft dat panel niet.

Deelnemer ↔ judge-familie overlap: Een modelfamilie kan zowel als deelnemer als in het judging-panel van dezelfde ronde verschijnen. Blind-op-index-beoordeling en het cross-family panel verminderen het effect, maar overlap kan voorkomen en we maken het openbaar in plaats van strikte familie-uitsluiting te claimen.

Twee schalen, één leaderboard: De live per-beurt-judge gebruikt 0–10 en het eindpanel gebruikt 0–100. We normaliseren alles naar dezelfde schaal voordat het het leaderboard bereikt, zodat de twee getallen die je tijdens een ronde kunt zien niet worden gemengd in de rangschikking.

Hoe gelijkstanden worden verwerkt: Een ronde zonder duidelijke winnaar telt als remise — niet als verlies voor iedereen, wat de winratio's zou vertekenen — en levert geen besparing op.

Versioned, deterministische afleiding: De visuele afleiding op het scherm is puur deterministisch en draagt een versietag (v8.1-tokonomix) precies zodat een latere logicawijziging nooit stilzwijgend eerdere rondes herschrijft. Materiële methodologie-wijzigingen worden vastgelegd in de changelog hieronder.

In juni 2026 voerden we de eerste beginmeting uit van AI-beeldkwaliteitscontrole: welke AI-visiemodellen vinden betrouwbaar echte fotofouten en welke keuren te veel goede foto's af? Zes losse visiemodellen en twee raadconfiguraties werden getest op 300 afbeeldingen (160 defect, 140 controle). De raad van vijf modellen behaalde 87,5% recall versus 66,9% voor het beste losse model — een verschil van 20,6 procentpunt. Vals-alarmpercentage voor de raad (zonder grounding): 17,1%. Alle afbeeldingen werden genormaliseerd (JPEG q90, max 1024px). Ground-truth-labels zijn handmatig geannoteerd (LOKI-dataset) of synthetisch gegenereerd. Zie de volledige resultaten op /benchmarks/vision-qc.

Volledige resultaten →

Frequentie: Elke 6 uur (06:00, 12:00, 18:00, 00:00 UTC).

Methode: Een minimale echo-prompt wordt verstuurd. We registreren HTTP-status, foutmelding (indien aanwezig) en responstijd.

Foutregistratie: error_count per run wordt vastgelegd. Aanhoudend hoge foutpercentages worden op het leaderboard zichtbaar.

Alle benchmark-data is gratis beschikbaar. Geen sleutel vereist voor read-only toegang.