Drex Max richt de blik op het beslissingsmodel — en prijst elke klik op $0,06

Een computer-use-agent is niet echt één beslissing. Een vlucht boeken bestaat uit dertig beslissingen: op welk veld je klikt, welk resultaat je opent, of de kalenderwidget klaar is met renderen, of het tarief dat hij bekijkt het gewenste is. Elk daarvan is een screenshot-roundtrip, en als het model aan de andere kant een frontier-chatmodel is, kost elk ervan seconden en een frontier-modelrekening. Drex Max, dat Nace.AI op 19 oktober 2026 als algemeen beschikbaar uitbracht, is een poging om die rekensom ineen te laten klappen. Het is een beslissingsmodel in plaats van een chatmodel — je geeft het een scherm en een reeks getypeerde opties, en één forward pass retourneert een waarschijnlijkheid voor elke optie. Nace noemt een prijs van $0,06 per miljoen inputtokens, een mediane latentie van 183 ms en helemaal geen outputkosten, omdat het niets schrijft. De gedocumenteerde AI-fouten en agentincidenten achter releases zoals deze zijn verzameld in het OrcaRouter AI Incident Archive waar elke vermelding zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwistmarkering heeft.

De vergelijking die Nace daarnaast zet is TypeSafe J​ev 1.14, het beslissingsmodel dat de requestvorm van deze categorie definieerde, en de algemene frontiermodellen die agents vandaag gebruiken. In de eigen gepubliceerde tabel van Nace bedraagt dat $10,17 per duizend beslissingen voor Claude Opus 5.5 en ongeveer 3,5 seconden per beslissing, tegenover $0,06 en 174 ms voor Drex Max op dezelfde 243 screenshotvragen. Leverancierscijfers, zelf uitgevoerd, door niemand buiten Nace gecontroleerd — maar de orde van grootte is het punt, en dat is de reden dat deze release meer ertoe doet dan zijn benchmarkrij.

Wat er daadwerkelijk is uitgebracht

Drex Max is het eerste model in de Drex-lijn met een vision-encoder. Drex 2.0 en Drex 1.5 waren tekst-in, waarschijnlijkheid-uit; Max leest screenshots, screencasts, gescande documenten, grafieken, foto's en videoframes, en beantwoordt dezelfde drie soorten vragen als zijn voorgangers.

• Model-id — drex-max, vastgezet. Geen open weights; gehost via Nace's eigen API, zonder downloadbare checkpoint.

• Invoerstructuur — een state-string plus een questions-object, en een images-array van maximaal 8 afbeeldingen per verzoek. Het endpoint is POST /v1/systemone, hetzelfde pad dat J​ev gebruikt.

• Vraagtypen — choice (benoemde opties, geeft een waarschijnlijkheid per optie), noul (een ja/nee-vraag, geeft P(true)), score (geordende niveaus, geeft een verwacht niveau en een verdeling). Meerdere vragen over één toestand delen één enkele pass.

• Context — 131.072 tokens per vraag, inclusief imagetokens, volgens de API-gids. De lanceerpost zegt afzonderlijk "262K-token context window." Die twee getallen komen niet overeen, en dat is het eerste dat moet worden opgelost voordat je een screenshot-buffer dimensioneert.

• Prijs — $0,06 per miljoen invoertokens; uitvoer wordt niet gefactureerd. Nace noemt hetzelfde bedrag als $0,06 per duizend beslissingen, wat neerkomt op ongeveer duizend tokens per aanroep.

• Voorgangers — Drex 2.0 (35B totaal, ongeveer 3B actief, gebouwd op Qwen3.6-35B-A3B, open gewichten) tegen $0,06 per duizend beslissingen, en Drex 1.5 (9B, alleen tekst) tegen $0,04.

• Implementatie — beheerd op Nace's GPU's, dedicated, binnen een AWS- of Azure-account van de klant, of air-gapped, allemaal met hetzelfde request-contract. Geen weights betekent geen self-hosting, maar het betekent niet alleen SaaS.

Er is niets exotisch aan de interface. Dat is bewust: Nace heeft Drex Max gebouwd om wire-compatibel te zijn met TypeSafe's J​ev SDK, zodat @typesafe-ai/sdk blijft werken met een gewijzigde basis-URL, sleutel en standaardmodel. De compatibiliteit is geen hoffelijkheid aan een rivaal. Zo wordt een nieuwkomer uitgeprobeerd — de goedkoopste migratie is degene die een configuratiewaarde is.

Het deel dat echt anders is: een distributie in plaats van een zin.

Een chatmodel beantwoordt een vraag over computergebruik door al schrijvend tot een antwoord te komen. "Als ik naar de pagina kijk, lijken de zoekresultaten te zijn geladen, dus de volgende actie zou moeten zijn om op het tweede resultaat te klikken" — en dan parseert je harness die zin, of een JSON-blob, en hoopt dat het model niet een optie heeft gekozen die je nooit hebt aangeboden. De prijs van dat ontwerp betaal je twee keer: één keer in outputtokens, en één keer in de parser die je moet onderhouden omdat het model een knop kan hallucineren die niet op het scherm staat.

Drex Max kan dat niet. Het retourneert een waarschijnlijkheid over de opties die je hebt opgegeven en niets anders. Als je vijf klikbare kandidaten aanbiedt, krijg je vijf getallen die samen optellen tot één. Dat is een beperkter vermogen en veel beter geschikt voor een loop, om drie redenen die in productie meer uitmaken dan in een demo.

De eerste is drempelwaarde toepassen. Met een kansverdeling kun je de regel opschrijven die je echt wilt: handel wanneer de beste optie 0,9 overschrijdt, escaleer naar een langzamer model of een mens wanneer dat niet het geval is. Een generatief model geeft je een zin en een betrouwbaarheidsveld dat iets heel anders betekent — meestal hoe gepiekt de tokenverdeling was, niet hoe waarschijnlijk het is dat het antwoord juist is.

Het tweede is faalgedrag. Een agent die alleen kan antwoorden met gedeclareerde opties, kan geen zesde knop bedenken. Hij kan fout zitten, en hij kan slecht gekalibreerd zijn, maar hij kan geen actie produceren waarvan jouw harness niet weet hoe die moet worden uitgevoerd.

Het derde is de economie. Omdat er geen outputtokens zijn, kost het beoordelen van tien opties hetzelfde als het beoordelen van twee. Nace's framing is dat dit het goedkoop genoeg maakt om bij elke stap aan te roepen, en bij $0,06 per duizend aanroepen klopt de rekensom: zelfs een slordige taak van dertig stappen kost minder dan twee tiende cent aan beslissingen. Dezelfde taak tegen Opus 5.5 zou, op basis van Nace's bedrag per beslissing, ongeveer dertig cent kosten — niet fataal, maar dertig keer de prijs van wat het aan het doen is.

De benchmarktabel, en van wie deze cijfers zijn

Elk cijfer hieronder komt uit Nace's lanceerbericht. De Decision Index 0.3.2 is een openbare ranglijst van benchmarks in beslissingsstijl, maar de Drex Max-run daarop is van Nace zelf, met gebruik van de officiële kit, en niemand buiten Nace heeft die gereproduceerd. De "Full"-score van het bord mengt ook private tests die geen deel uitmaken van deze run. Beschouw de vorm van de resultaten als informatief en de decimalen als marketing.

De kop is een openbare Decision Index van 67,6, tegen 61,3 voor Drex 2.0, 58,1 voor Drex 1.5, 60,7 voor J​ev 1.14 en 47,8 voor GPT-6 Luna Decisions. Op de bijbehorende Vision Index — het getal dat ertoe doet voor een model waarvan zien het verkoopargument is — scoort Drex Max 74,5 tegen 63,9 voor Luna.

• Mind2Web — 88,6 tegenover 81,2 voor GPT-6 Luna Decisions, de meest direct relevante rij voor browseragents.

• OSWorld-Verified — 0,780 tegen 0,756 voor GPT-6 Sol en 0,790 voor Claude Opus 5.5. Drex Max verslaat de eerste en verliest nipt van de tweede.

• OSWorld-V2 — 0,737 tegen 0,744 voor Sol en 0,761 voor Opus 5.5. Zelfde verhaal, iets grotere kloof.

• BFCL-toolaanroepen — 98,2, vóór de 96,4 van Jev 1.14 en de 97,3 van Claude Opus 5.5, alleen achter GPT-6 Sol.

• DecideBench — 98,5 op items en 97,0 op paren, beide beter dan Jev 1.14.

• Zakelijke beslissingen vs J​ev 1.14 — FinEntity 92,3 vs 81,9, BANKING77 90,0 vs 79,7, ContractNLI 75,9 vs 57,7.

De OSWorld-rijen verdienen een voorbehoud dat de tabel van Nace niet expliciet maakt. Die scores beschrijven een volledige automatiseringsstack, en het is niet gedocumenteerd hoeveel van de lus rond Drex Max ook de eigen harness van Nace was. Een beslissingsmodel dat de volgende actie goed kiest, blijft afhankelijk van wat de screenshot maakt, wacht op renders en beslist wanneer de taak klaar is. Lees 0,780 als bewijs dat de beslissingen niet de bottleneck zijn, niet als een belofte over je agent.

Waar het verliest, welke de nuttigere helft van de tabel is

De verliezen zijn niet begraven, maar ze zijn gemakkelijk over het hoofd te zien, en twee ervan beschrijven echte beperkingen in plaats van afrondingsruis.

Op het gebied van algemene kennis en moeilijke redeneertaken zijn beslissingsmodellen eenvoudigweg niet concurrerend met frontier-chatmodellen, en Drex Max verandert daar niets aan. MMLU-Pro is 72,5, achter de 82,1 van J​ev 1.14, de 93,0 van Sol en de 94,0 van Opus 5.5. HLE is 19,0 tegenover de 19,4 van J​ev — hoe dan ook een gelijkspel onderaan de range. Dit is te verwachten voor een model wiens taak het is om op basis van een screening uit een korte lijst te kiezen, en dat is de reden dat een beslissingsmodel een component in een agent is, niet een vervanging voor het model dat de planning doet.

Interessanter is de regressie ten opzichte van zijn eigen voorganger. Op When2Call, dat vraagt of een tool-call überhaupt gerechtvaardigd is, scoort Drex Max 85,2, terwijl Drex 2.0 86,5 haalt en het oudere, goedkopere Drex 1.5 89,7 scoort. Het nieuwste en duurste Drex-model is van de drie het slechtst in aanvoelen wanneer het niet moet handelen. Als je workflow afhankelijk is van terughoudendheid — een supportagent die liever stil blijft dan een terugbetalings-tool aanroept — dan levert de vision-capaciteit je dat niet op, en een goedkoper tekstmodel kan nog steeds de juiste keuze zijn.

Hetzelfde patroon is te zien in twee vision-rijen die de andere kant op gaan. KIE, extractie van sleutelinformatie uit gescande formulieren, is 95,5 tegenover 97,5 voor Luna. Hateful Memes-moderatie is 70,6 tegenover 71,2. Geen van beide verschillen is groot, en beide liggen in domeinen waar de voorsprong van Drex Max elders dertig punten groot is, wat erop wijst dat de vision-encoder is getraind op schermlay-outs en grafieken in plaats van gedrukte formulieren of memes.

Latentie is ook achteruitgegaan. De mediaan van 183 ms van Drex Max is 32 ms trager dan Drex 2.0 en 38 ms trager dan Drex 1.5. In een lus die dertig keer per taak wordt uitgevoerd, komt dat neer op ongeveer een seconde extra per taak, tegenover meerdere seconden bespaard per stap vergeleken met een frontier-model. Nog steeds de juiste afweging, maar het is goed om te weten dat de vision-encoder niet gratis is.

Eén getal moet apart worden gehouden voordat het je wordt voorgehouden. De 174 ms in de inleidende alinea is Nace's meting uitsluitend op basis van screenshots — 243 beeldvragen, één verzoek tegelijk, tegenover 253 ms voor J​ev 1.14 op dezelfde set. De 183 ms is de mediaan over de hele benchmarksuite in de lanceringstabel. Beide zijn van Nace; het zijn verschillende metingen, en het meest flatteuze is het smalste.

Twee valkuilen in de API voordat je iets aansluit

De documentatie bevat een detail dat iemand een middag kost als die het vluchtig leest. drex-latest wijst niet naar Drex Max. Het is een vastgezet checkpoint, en de alias verwijst naar iets anders. Iedereen die de quickstart volgt, zijn sleutel invult en TYPESAFE_DEFAULT_MODEL=drex-latest instelt — precies wat de J​ev-compatibiliteitsinstructies hun zeggen te doen — zal een model aanroepen dat alleen tekst aankan en zich afvragen waarom hun screenshots worden genegeerd.

De tweede valkuil is grootte. De API-handleiding beperkt verzoeken tot acht afbeeldingen en 131.072 tokens per vraag, inclusief afbeeldingstokens; het lanceringsbericht adverteert 262K. Totdat Nace de twee met elkaar in overeenstemming brengt, kun je beter uitgaan van het kleinere getal. Er is geen gepubliceerde tokenkosten per afbeelding, waardoor de limiet vooraf moeilijk te beredeneren is: een schermafbeelding op volledige resolutie is geen vast aantal tokens, en de documentatie zegt niet hoe afbeeldingen worden verkleind of in tegels verdeeld.

Eén ding is eenvoudiger dan bij de gevestigde speler: Drex Max accepteert screenshots van elke afmeting. De API van Jev 1.14 weigert afbeeldingen met een zijde kleiner dan 280 px of groter dan 1.568 px — precies het soort beperking dat zich om 2 uur 's nachts in een retry-loop als een stille fout openbaart.

Wat dit doet met een routeringsbeslissing

De praktische vraag is niet of Drex Max beter is dan een frontiermodel. Dat is het niet, en dat probeert het ook niet te zijn. De vraag is welke van de dertig beslissingen in een taak een frontiermodel verdienen en welke een waarschijnlijkheidsverdeling van 174 ms verdienen, en dat is een routeringsprobleem voordat het een modelprobleem is.

Drex Max staat niet op onze routelijst. De OrcaRouter-catalogus bevat het niet, en niets hier mag worden opgevat als een beschikbaarheidsclaim van ons — Nace verkoopt het via zijn eigen API en zijn eigen console. Wat wij wel aanbieden, is de gevestigde speler waarmee het wordt vergeleken. TypeSafe Jev 1.13 is een vermelde route voor $0.042 per miljoen inputtokens over een context van 65.536 tokens, aangeboden via dezelfde POST /v1/systemone body, dus een A/B tussen een beslissingsmodel en je huidige screenshot-naar-frontier-lus is een modelstring in plaats van een herschrijving. De goedkope manier om dit te beslechten is je tekstuele beslissingsaanroepen laten waar ze zijn, er een stap voor schermlezen naast zetten voor de taken die ogen nodig hebben, en beide te meten aan je eigen logs in plaats van aan Nace's 140.178 gescoorde requests.

Dat soort splitsing werkt alleen als de onderdelen vanaf één plek bereikbaar zijn. Eén sleutel voor meer dan 200 modellen, de lijstprijs van de provider één-op-één doorgegeven zonder opslag per token, en automatische failover tussen providers zijn wat voorkomt dat het experiment wegzakt tot een verouderde branch zodra de persoon die het heeft opgezet van team wisselt. Het is hier ook om een specifieke reden van belang: Drex Max is nieuw, niet-geaudit en alleen via API beschikbaar, en de veilige manier om een onbewezen component te adopteren is het achter iets te plaatsen dat kan terugvallen op een bekend model wanneer het vertrouwen daalt of de endpoint zich misdraagt. Stuur de zekere beslissingen naar het goedkope model en laat failover de rest afhandelen.

Wat zou deze aflezing veranderen?

Een onafhankelijke run van de Decision Index komt op de eerste plaats. De suite is openbaar, Nace zegt dat de evals reproduceerbaar zijn, en totdat iemand buiten het bedrijf Drex Max erop laat draaien, is de 67,6 een leverancierscijfer. De cellen om in de gaten te houden wanneer dat gebeurt, zijn de cellen die in tegengestelde richtingen wijzen: een voorsprong van 30 punten op Mind2Web naast een regressie op When2Call is geen vloeiende capaciteitscurve; het beschrijft een model dat hard is getraind op "welke van deze is de volgende klik" en minder hard op "zou ik überhaupt iets moeten aanklikken". Als dat standhoudt, is het het operationeel belangrijkste feit over Drex Max, en het staat niet in de hoogtepunten.

Productielatentie onder concurrency is het tweede punt. Nace's eigen doorvoercijfer — ongeveer 25 requests per seconde op één H100-replica, geen fouten tot 64 gelijktijdig in behandeling — geldt voor Drex in het algemeen, niet specifiek voor Max. Het hele verkoopargument van het ontwerp is dat het op elke stap in een hot path zit, waardoor p95 onder belasting veel relevanter is dan een mediaan van 183 ms, en niets gepubliceerd gaat daarop in.

Ten derde heeft de prijsstelling een uitgewerkt rekenvoorbeeld met afbeeldingen nodig. $0,06 per miljoen invoertokens is alleen nuttig als je weet wat een schermafbeelding in tokens kost, en geen enkel gepubliceerd cijfer doet dat. Een team dat een lus van 30 stappen begroot, met per stap een 1440p-scherm, gokt totdat Nace de tokenboekhouding voor afbeeldingen publiceert of iemand het meet.

Niets daarvan maakt de release minder interessant. Een beslissingsmodel dat kan zien is een wezenlijk andere component dan een chatmodel dat wordt gevraagd naar een screenshot te kijken, en het prijsverschil is groot genoeg om te veranderen wat een agent zich bij elke stap kan permitteren. Alleen is het nog geen getal dat iemand buiten Nace heeft gecontroleerd — en het deel van de tabel dat contact met een echte deployment overleeft, zal waarschijnlijk het deel zijn dat niemand citeert.