Het artikel analyseert waarom traditionele benchmarkscores voor AI-modellen zoals Qwen 3.8-Max en Claude Opus 5 een vertekend beeld geven van de werkelijke prestaties en kosten. Het kernprobleem is dat tijd- en tokenbudgetten vaak verborgen blijven, terwijl deze bepalend zijn voor het succes van een taak.
Belangrijke inzichten:
- Budgetten beïnvloeden resultaten: Grote verschillen in time-outs tussen fabrikanten (zoals Alibaba) en onafhankelijke tests verklaren waarom scores sterk uiteenlopen.
- Kosten per token vs. Kosten per succes: Vanwege 'thinking tokens' bij reasoning-modellen is de prijs per token niet langer representatief voor de uiteindelijke rekening. De auteur stelt voor om te kijken naar de totale kosten gedeeld door het aantal daadwerkelijk voltooide taken.
- Foutanalyse: Veel fouten in benchmarks zijn eigenlijk time-outs (budgetuitputting) in plaats van inhoudelijke onjuistheden, wat essentieel is bij het configureren van routing-ladders.
De auteur adviseert ontwikkelaars om falen expliciet te categoriseren, kosten per succesvol resultaat te berekenen en kritisch te kijken naar de standaard 'effort'-instellingen van modellen.
Qwen 3.8-Max en Claude Opus 5 tonen waarom ruwe benchmarkscores de rekening niet voorspellen
Beide resultaten zijn reëel en verdedigbaar. Het gat tussen beide gaat over token- en tijdsbudgetten, en dat is belangrijk omdat deze cijfers meestal niet als koptekst worden vermeld. De voetnoten van Alibaba geven hun coding-cijfers een time-out van vijf uur, en tot 12 uur per run op PaperBench. De onafhankelijke harness, VulcanBench, stond tussen de 45 en 60 minuten aan kloktijd toe. Een tijdsbudget dat vijf tot zestien keer groter is aan de kant van Alibaba verklaart het enorme verschil in resultaten.
Het is tijd om twee dingen te doen om rekening te houden met deze verschillen bij het kiezen van modellen. Ten eerste is de metriek die gebruikt moet worden 'kosten per succesvolle taak': de totale uitgaven, inclusief alles wat is besteed aan pogingen die mislukten, gedeeld door de taken die daadwerkelijk zijn goedgekeurd via de acceptatiecontrole. Ten tweede moeten tijd- of tokenbudgetten een expliciet onderdeel worden van uw acceptatiecriteria, in plaats van een verborgen detail.
Prijs per token voorspelt de rekening niet meer
De vergelijking die iedereen in de eerste week van Qwen 3.8-Max publiceerde was een prijsvergelijking, omdat dat de enige beschikbare data was. Het is geen goedkoop model. DeepSeek-V4-Flash-0731, die op 31 juli in publieke API-beta ging, kost 14 cent per miljoen inputtokens en 28 cent voor output. Qwen 3.8-Max kost $2 en $6. Kimi K3 zit op $3 en $15.
Deze prijzen vertellen u minder dan voorheen, om een reden die specifiek is voor reasoning-modellen zoals Qwen: het bereiken van een resultaat kost 'thinking tokens'. Een model dat het grootste deel van zijn tokenbudget besteedt aan redeneren, kan een tokenlimiet bereiken voordat het het antwoord schrijft. Dit resulteert in een leeg resultaat dat niet te onderscheiden is van een totale mislukking, maar tegen de kosten van een volledige run.
Artificial Analysis heeft de meest heldere gepubliceerde meting van hoe dit de werkelijke uitgaven voor agents kan beïnvloeden: het draaien van hun Intelligence Index op DeepSeek-V4-Flash bij maximale inzet kostte 210 miljoen outputtokens, tegenover een mediaan van 100 miljoen voor die klasse. De absolute kosten bleven sowieso laag omdat de tokens zo goedkoop waren. Maar uitgebreidheid (verbosity) kost tijd, niet alleen geld, en afhankelijk van uw use case kan dat fataal zijn.
Wat u nodig heeft is een getal dat alles telt wat u heeft uitgegeven, inclusief de pogingen die leeg terugkwamen, afgezet tegen de taken die daadwerkelijk zijn voltooid binnen het door u opgegeven tijd- en tokenbudget. Dit is waar een metriek voor kosten per succes bij helpt.
Uw foutpercentage is gedeeltelijk een configuratie-instelling
Een run die een fout antwoord produceert en een run die het budget overschrijdt, zijn verschillende gebeurtenissen met verschillende oplossingen. Bijna geen enkele harness maakt dit onderscheid, en bijna geen enkel leaderboard rapporteert de splitsing. Ik merkte dit toen ik mijn eigen agent-benchmark bouwde: de harness registreerde een fout zonder aan te geven waarom, en ik moest het onderscheid zelf toevoegen. Wanneer u ze wel scheidt, blijkt dat budgetuitputting domineert.
Long-Horizon-Terminal-Bench, gepubliceerd in juli, testte 17 frontier-modellen over 46 taken via een gedeelde harness met één poging van 90 minuten per stuk. Time-outs waren verantwoordelijk voor 79% van de onopgeloste runs, tegenover 19% voor agents die uit eigen beweging stopten en 3% voor harness-fouten. De auteurs zijn voorzichtig over wat dit wel en niet betekent: de runs die time-outten waren niet nabij voltooiing, met een gemiddelde beloning tussen 0,10 en 0,35; u kunt dus niet aannemen dat meer tijd tot succes zou hebben geleid. Maar de les is: benchmarks meten impliciet de tijdefficiëntie, of ze daar nu expliciet over communiceren of niet.
Het duidelijkste gepubliceerde voorbeeld van dit mechanisme komt van VulcanBench, dezelfde open-source harness achter de Qwen-grafiek. In een rapport van 26 juli was de instelling met de laagste inzet ('lowest-effort') voor Claude Opus 5 de beste; het loste 20 van de 23 taken op, tegenover 18 bij hoge inzet. De extra redenering was niet nutteloos: hoge inzet leverde de minste foute antwoorden op van alle instellingen (één tegenover drie). Het model liep echter simpelweg uit de tijd, en een time-out scoort nul. Twee van de drie regressies waren afkapjes bij taken die de lage-inzetinstelling wel oplost; met onbeperkte tijd zou het resultaat slechts gelijk zijn aan de goedkoopste instelling, maar tegen 3,1 keer de kosten.
Dit heeft een direct gevolg voor iedereen die een routing-ladder bouwt. Het standaardontwerp escaleert naar meer redenering wanneer een goedkope poging mislukt, vanuit de aanname dat de volgende trede beter is en enkel duurder kost. Voor een aanzienlijk deel van de model- en taakcombinaties is die aanname onjuist, en betaalt u de prijs van de hogere trede om te escaleren naar een time-out of het bereiken van een limiet.
Wie meet dit al?
Verschillende groepen zijn de afgelopen maanden onafhankelijk van elkaar uitgekomen op 'kosten per succesvolle taak', wat het sterkste signaal is dat dit de standaard wordt.
- VulcanBench rapporteert dollars per opgeloste taak als een hoofdkolom in hun rapporten.
- Long-Horizon-Terminal-Bench publiceert kosten per taak naast de nauwkeurigheid; de meest leerzame rij is GPT-5.4 met ongeveer $26 per taak en een veel lager slagingspercentage dan Grok 4.5 met ongeveer $11.
- TestEvo-Bench laat agents draaien onder een kostenplafond; de score voor testgeneratie van Claude Code daalt hierbij van 71% naar 44% bij een strikter plafond.
Ook leveranciers zijn al inmiddels overgestapt op het meten per succesvolle taak:
- HubSpot veranderde in april de facturering van hun Breeze Customer Agent naar 50 cent per opgeloste conversatie, in plaats van $1 per afgehandelde conversatie.
- Zendesk factureert per automatische resolutie.
- Fin rekent 99 cent per resultaat en factureert alleen bij end-to-end resolutie.
Wat deze week te veranderen
- Geef bij elke agent-run een reden voor falen op als verplicht veld. Maak onderscheid tussen budgetuitputting, verifieringsfout en harness-fout in plaats van één algemene foutvlag. Totdat u een time-out kunt scheiden van een fout antwoord, meet uw slagingspercentage twee dingen tegelijk en weet u niet wat u moet repareren.
- Bereken de kosten per succesvolle taak per inspanningsniveau, niet alleen per model. De totale uitgaven inclusief mislukte pogingen, gedeeld door de taken die uw acceptatiecontrole zijn gepasseerd. De ranglijst zal niet overeenkomen met de prijslijst, en de goedkoopste instelling kan 얼마 zeer goed winnen.
- Stel een limiet in op tokens in plaats van kloktijd, tenzij latentie echt onderdeel is van uw service level objective (SLO). Een tijdslimiet scoort de serveersnelheid van uw provider als modelkwaliteit.
- Controleer de standaardinstelling voor inspanning ('effort') op alles wat u heeft geïmplementeerd. Qwen 3.8-Max draait op de hoogste redeneerinstelling wanneer het effort-veld niet is ingesteld, en juist die hoogste instelling presteerde het slechtst in onafhankelijke tests. Een team dat deze parameter nooit aanpast, gebruikt de configuratie die de meeste kosten per opgeloste taak veroorzaakt.
Qwen 3.8-Max en Claude Opus 5 tonen waarom ruwe benchmarkscores de rekening niet voorspellen
Beide resultaten zijn reëel en verdedigbaar. Het gat tussen beide gaat over token- en tijdsbudgetten, en dat is belangrijk omdat deze cijfers meestal niet als koptekst worden vermeld. De voetnoten van Alibaba geven hun coding-cijfers een time-out van vijf uur, en tot 12 uur per run op PaperBench. De onafhankelijke harness, VulcanBench, stond tussen de 45 en 60 minuten aan kloktijd toe. Een tijdsbudget dat vijf tot zestien keer groter is aan de kant van Alibaba verklaart het enorme verschil in resultaten.
Het is tijd om twee dingen te doen om rekening te houden met deze verschillen bij het kiezen van modellen. Ten eerste is de metriek die gebruikt moet worden 'kosten per succesvolle taak': de totale uitgaven, inclusief alles wat is besteed aan pogingen die mislukten, gedeeld door de taken die daadwerkelijk zijn goedgekeurd via de acceptatiecontrole. Ten tweede moeten tijd- of tokenbudgetten een expliciet onderdeel worden van uw acceptatiecriteria, in plaats van een verborgen detail.
Prijs per token voorspelt de rekening niet meer
De vergelijking die iedereen in de eerste week van Qwen 3.8-Max publiceerde was een prijsvergelijking, omdat dat de enige beschikbare data was. Het is geen goedkoop model. DeepSeek-V4-Flash-0731, die op 31 juli in publieke API-beta ging, kost 14 cent per miljoen inputtokens en 28 cent voor output. Qwen 3.8-Max kost $2 en $6. Kimi K3 zit op $3 en $15.
Deze prijzen vertellen u minder dan voorheen, om een reden die specifiek is voor reasoning-modellen zoals Qwen: het bereiken van een resultaat kost 'thinking tokens'. Een model dat het grootste deel van zijn tokenbudget besteedt aan redeneren, kan een tokenlimiet bereiken voordat het het antwoord schrijft. Dit resulteert in een leeg resultaat dat niet te onderscheiden is van een totale mislukking, maar tegen de kosten van een volledige run.
Artificial Analysis heeft de meest heldere gepubliceerde meting van hoe dit de werkelijke uitgaven voor agents kan beïnvloeden: het draaien van hun Intelligence Index op DeepSeek-V4-Flash bij maximale inzet kostte 210 miljoen outputtokens, tegenover een mediaan van 100 miljoen voor die klasse. De absolute kosten bleven sowieso laag omdat de tokens zo goedkoop waren. Maar uitgebreidheid (verbosity) kost tijd, niet alleen geld, en afhankelijk van uw use case kan dat fataal zijn.
Wat u nodig heeft is een getal dat alles telt wat u heeft uitgegeven, inclusief de pogingen die leeg terugkwamen, afgezet tegen de taken die daadwerkelijk zijn voltooid binnen het door u opgegeven tijd- en tokenbudget. Dit is waar een metriek voor kosten per succes bij helpt.
Uw foutpercentage is gedeeltelijk een configuratie-instelling
Een run die een fout antwoord produceert en een run die het budget overschrijdt, zijn verschillende gebeurtenissen met verschillende oplossingen. Bijna geen enkele harness maakt dit onderscheid, en bijna geen enkel leaderboard rapporteert de splitsing. Ik merkte dit toen ik mijn eigen agent-benchmark bouwde: de harness registreerde een fout zonder aan te geven waarom, en ik moest het onderscheid zelf toevoegen. Wanneer u ze wel scheidt, blijkt dat budgetuitputting domineert.
Long-Horizon-Terminal-Bench, gepubliceerd in juli, testte 17 frontier-modellen over 46 taken via een gedeelde harness met één poging van 90 minuten per stuk. Time-outs waren verantwoordelijk voor 79% van de onopgeloste runs, tegenover 19% voor agents die uit eigen beweging stopten en 3% voor harness-fouten. De auteurs zijn voorzichtig over wat dit wel en niet betekent: de runs die time-outten waren niet nabij voltooiing, met een gemiddelde beloning tussen 0,10 en 0,35; u kunt dus niet aannemen dat meer tijd tot succes zou hebben geleid. Maar de les is: benchmarks meten impliciet de tijdefficiëntie, of ze daar nu expliciet over communiceren of niet.
Het duidelijkste gepubliceerde voorbeeld van dit mechanisme komt van VulcanBench, dezelfde open-source harness achter de Qwen-grafiek. In een rapport van 26 juli was de instelling met de laagste inzet ('lowest-effort') voor Claude Opus 5 de beste; het loste 20 van de 23 taken op, tegenover 18 bij hoge inzet. De extra redenering was niet nutteloos: hoge inzet leverde de minste foute antwoorden op van alle instellingen (één tegenover drie). Het model liep echter simpelweg uit de tijd, en een time-out scoort nul. Twee van de drie regressies waren afkapjes bij taken die de lage-inzetinstelling wel oplost; met onbeperkte tijd zou het resultaat slechts gelijk zijn aan de goedkoopste instelling, maar tegen 3,1 keer de kosten.
Dit heeft een direct gevolg voor iedereen die een routing-ladder bouwt. Het standaardontwerp escaleert naar meer redenering wanneer een goedkope poging mislukt, vanuit de aanname dat de volgende trede beter is en enkel duurder kost. Voor een aanzienlijk deel van de model- en taakcombinaties is die aanname onjuist, en betaalt u de prijs van de hogere trede om te escaleren naar een time-out of het bereiken van een limiet.
Wie meet dit al?
Verschillende groepen zijn de afgelopen maanden onafhankelijk van elkaar uitgekomen op 'kosten per succesvolle taak', wat het sterkste signaal is dat dit de standaard wordt.
- VulcanBench rapporteert dollars per opgeloste taak als een hoofdkolom in hun rapporten.
- Long-Horizon-Terminal-Bench publiceert kosten per taak naast de nauwkeurigheid; de meest leerzame rij is GPT-5.4 met ongeveer $26 per taak en een veel lager slagingspercentage dan Grok 4.5 met ongeveer $11.
- TestEvo-Bench laat agents draaien onder een kostenplafond; de score voor testgeneratie van Claude Code daalt hierbij van 71% naar 44% bij een strikter plafond.
Ook leveranciers zijn al inmiddels overgestapt op het meten per succesvolle taak:
- HubSpot veranderde in april de facturering van hun Breeze Customer Agent naar 50 cent per opgeloste conversatie, in plaats van $1 per afgehandelde conversatie.
- Zendesk factureert per automatische resolutie.
- Fin rekent 99 cent per resultaat en factureert alleen bij end-to-end resolutie.
Wat deze week te veranderen
- Geef bij elke agent-run een reden voor falen op als verplicht veld. Maak onderscheid tussen budgetuitputting, verifieringsfout en harness-fout in plaats van één algemene foutvlag. Totdat u een time-out kunt scheiden van een fout antwoord, meet uw slagingspercentage twee dingen tegelijk en weet u niet wat u moet repareren.
- Bereken de kosten per succesvolle taak per inspanningsniveau, niet alleen per model. De totale uitgaven inclusief mislukte pogingen, gedeeld door de taken die uw acceptatiecontrole zijn gepasseerd. De ranglijst zal niet overeenkomen met de prijslijst, en de goedkoopste instelling kan 얼마 zeer goed winnen.
- Stel een limiet in op tokens in plaats van kloktijd, tenzij latentie echt onderdeel is van uw service level objective (SLO). Een tijdslimiet scoort de serveersnelheid van uw provider als modelkwaliteit.
- Controleer de standaardinstelling voor inspanning ('effort') op alles wat u heeft geïmplementeerd. Qwen 3.8-Max draait op de hoogste redeneerinstelling wanneer het effort-veld niet is ingesteld, en juist die hoogste instelling presteerde het slechtst in onafhankelijke tests. Een team dat deze parameter nooit aanpast, gebruikt de configuratie die de meeste kosten per opgeloste taak veroorzaakt.
Groetjes,