Drex Max riktar blicken mot beslutsmodellen – och prissätter varje klick till $0.06

En datoranvändningsagent är egentligen inte ett enda beslut. Att boka en flygresa är trettio av dem: vilket fält som ska klickas, vilket resultat som ska öppnas, om kalenderwidgeten har renderats färdigt, om biljettpriset den tittar på är det den vill ha. Var och en av dem är en tur och retur med en skärmbild, och om modellen i andra änden är en avancerad chattmodell kostar var och en sekunder och en räkning för avancerade modeller. Drex Max, som Nace.AI lanserade som allmänt tillgänglig den 19 oktober 2026, är ett försök att pressa ihop den aritmetiken. Det är en beslutsmodell snarare än en chattmodell – du ger den en skärm och en uppsättning typade alternativ, och en enda framåtpassning returnerar en sannolikhet för varje alternativ. Nace listar den till 0,06 USD per miljon indatatoken, en medianlatens på 183 ms och ingen utdatakostnad alls, eftersom den inte skriver något. De dokumenterade AI-felen och agentincidenterna bakom lanseringar som denna samlas i OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omstridd status.

Jämförelsen som Nace ställer bredvid det är TypeSafe J​ev 1.14, beslutsmodellen som definierade hur förfrågningar i kategorin är utformade, och de generalistiska frontiermodellerna som agenter använder i dag. Enligt Naces egen publicerade tabell är det 10,17 USD per tusen beslut för Claude Opus 5.5 och ungefär 3,5 sekunder per beslut, mot 0,06 USD och 174 ms för Drex Max på samma 243 skärmbildsfrågor. Leverantörssiffror, egenkörda, ej granskade av någon utanför Nace – men storleksordningen är poängen, och det är anledningen till att den här lanseringen betyder mer än dess benchmarkrad gör.

Vad som faktiskt levererades

Drex Max är den första modellen i Drex-serien med en vision-encoder. Drex 2.0 och Drex 1.5 tog text in och gav sannolikheter ut; Max läser skärmbilder, skärminspelningar, skannade dokument, diagram, foton och videorutor och svarar på samma tre frågetyper som sina föregångare.

• Modell-id — drex-max, låst. Inga öppna vikter; hostas via Naces eget API, utan någon nedladdningsbar checkpoint.

• Indataformat – en state-sträng plus ett questions-objekt, och en images-array med upp till 8 bilder per begäran. Slutpunkten är POST /v1/systemone, samma sökväg som J​ev använder.

• Frågetyper — choice (namngivna alternativ, returnerar en sannolikhet per alternativ), noul (en ja/nej-fråga, returnerar P(true)), score (ordnade nivåer, returnerar en förväntad nivå och en fördelning). Flera frågor om ett tillstånd delar en enda körning.

• Kontext — 131 072 token per fråga inklusive bildtoken, enligt API-guiden. Lanseringsinlägget säger separat "262K-token kontextfönster". De två siffrorna stämmer inte överens, och det är det första som måste redas ut innan du dimensionerar en buffert för skärmdumpar.

• Pris — $0.06 per miljon indatatokens; utdata faktureras inte. Nace anger samma siffra som $0.06 per tusen beslut, vilket antyder ungefär tusen tokens per anrop.

• Föregångare — Drex 2.0 (35B totalt, cirka 3B aktiva, byggd på Qwen3.6-35B-A3B, öppna vikter) till $0.06 per tusen beslut, och Drex 1.5 (9B, endast text) till $0.04.

• Deployment — hanterad på Naces GPU:er, dedikerad, i ett kundägt AWS- eller Azure-konto, eller i ett isolerat nät, allt med samma förfrågningskontrakt. Inga vikter innebär ingen egen hosting, men det betyder inte att det bara är SaaS.

Det finns inget exotiskt i gränssnittet. Det är avsiktligt: Nace byggde Drex Max för att vara wire-kompatibel med TypeSafe:s J​ev SDK, så @typesafe-ai/sdk fortsätter att fungera med en ändrad bas-URL, nyckel och standardmodell. Kompatibiliteten är inte en artighet mot en konkurrent. Det är så en ny aktör blir testad — den billigaste migreringen är den som är ett konfigurationsvärde.

Det som verkligen är annorlunda: en fördelning i stället för en mening

En chattmodell svarar på en fråga om datoranvändning genom att skriva sig fram till ett svar. "Om man tittar på sidan verkar sökresultaten ha laddats, så nästa åtgärd bör vara att klicka på det andra resultatet" – och sedan tolkar din harness den meningen, eller en JSON-blob, och hoppas att modellen inte valde ett alternativ som du aldrig erbjöd. Kostnaden för den designen betalas två gånger: en gång i utdatatokens, och en gång i parsern som du måste underhålla eftersom modellen kan hallucinera en knapp som inte finns på skärmen.

Drex Max kan inte göra det. Det returnerar en sannolikhet över de alternativ du angav och inget annat. Om du erbjuder fem klickbara kandidater får du fem tal som summerar till ett. Det är en snävare förmåga och en mycket bättre passform för en loop, av tre skäl som spelar större roll i produktion än i en demo.

Den första är tröskling. En sannolikhetsfördelning låter dig skriva regeln du faktiskt vill ha: agera när det bästa alternativet passerar 0,9, eskalera till en långsammare modell eller en människa när det inte gör det. En generativ modell ger dig en mening och ett konfidensfält som betyder något helt annat – vanligtvis hur spetsig tokenfördelningen var, inte hur sannolikt det är att svaret är korrekt.

Det andra är felbeteende. En {{1}}agent{{/1}} som bara kan svara med deklarerade alternativ kan inte uppfinna en sjätte knapp. Den kan ha fel, och den kan vara dåligt kalibrerad, men den kan inte producera en {{2}}åtgärd{{/2}} som din testram inte vet hur den ska utföra.

Det tredje är ekonomin. Eftersom det inte finns några utdatatoken är kostnaden för att poängsätta tio alternativ densamma som för att poängsätta två. Naces resonemang är att detta gör det tillräckligt billigt att anropa vid varje steg, och med 0,06 dollar per tusen anrop går matematiken ihop: även en slarvig trettio steg lång uppgift kostar mindre än två tiondels cent i beslut. Samma uppgift mot Opus 5.5, enligt Naces siffra per beslut, skulle kosta omkring trettio cent – inte ödesdigert, men trettio gånger priset för det den gör.

Benchmarktabellen, och vems siffror dessa är

Varje siffra nedan kommer från Naces lanseringsinlägg. Decision Index 0.3.2 är en offentlig resultattavla för benchmarks i beslutsstil, men Drex Max-körningen på den är Naces egen, med det officiella kitet, och ingen utanför Nace har reproducerat den. Tavlans "Full"-poäng blandar också in privata tester som inte ingår i den här körningen. Behandla resultatens form som informativ och decimalerna som marknadsföring.

Rubriken är ett offentligt Decision Index på 67,6, jämfört med 61,3 för Drex 2.0, 58,1 för Drex 1.5, 60,7 för J​ev 1.14 och 47,8 för GPT-6 Luna Decisions. I det kompletterande Vision Index — siffran som spelar roll för en modell vars säljargument är synen — får Drex Max 74,5 jämfört med Lunas 63,9.

• Mind2Web — 88,6 mot 81,2 för GPT-6 Luna Decisions, den mest direkt relevanta raden för webbläsaragenter.

• OSWorld-Verified — 0,780 mot 0,756 för GPT-6 Sol och 0,790 för Claude Opus 5.5. Drex Max slår den första och förlorar med knapp marginal mot den andra.

• OSWorld-V2 — 0.737 mot 0.744 för Sol och 0.761 för Opus 5.5. Samma historia, något större gap.

• BFCL-verktygsanrop — 98,2, före Jev 1.14:s 96,4 och Claude Opus 5.5:s 97,3, endast efter GPT-6 Sol.

• DecideBench — 98,5 på uppgifter och 97,0 på par, båda före J​ev 1.14.

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

OSWorld-raderna förtjänar en brasklapp som Naces tabell inte uttryckligen anger. Dessa poäng beskriver en fullständig automationsstack, och det är inte dokumenterat hur stor del av loopen runt Drex Max som också var Naces egen harness. En beslutsmodell som väljer nästa åtgärd på ett bra sätt är fortfarande beroende av det som tar skärmbilden, väntar på renderingar och avgör när uppgiften är slutförd. Läs 0,780 som ett bevis på att besluten inte är flaskhalsen, inte som ett löfte om din agent.

Där den förlorar, vilken är den mer användbara halvan av tabellen

Förlusterna är inte begravda, men de är lätta att ögna förbi, och två av dem beskriver verkliga gränser snarare än avrundningsbrus.

När det gäller allmänkunskap och avancerad resonemangsförmåga är beslutsmodellerna helt enkelt inte konkurrenskraftiga mot frontier-chattmodeller, och Drex Max ändrar inte det. MMLU-Pro är 72,5, bakom Jev 1.14:s 82,1, Sols 93,0 och Opus 5.5:s 94,0. HLE är 19,0 mot Jevs 19,4 – oavgjort i botten av intervallet oavsett. Detta är förväntat för en modell vars uppgift är att välja från en kort lista givet en skärm, och det är anledningen till att en beslutsmodell är en komponent i en agent, inte en ersättning för modellen som planerar.

Mer intressant är regressionen jämfört med dess egen föregångare. På When2Call, som frågar om ett verktygsanrop överhuvudtaget är motiverat, får Drex Max 85,2 medan Drex 2.0 når 86,5 och den äldre, billigare Drex 1.5 får 89,7. Den nyaste och dyraste Drex-modellen är sämst av de tre på att veta när man inte ska agera. Om ditt arbetsflöde är beroende av återhållsamhet — en supportagent som bör förbli tyst snarare än att anropa ett återbetalningsverktyg — ger synförmågan dig inte det, och en billigare textmodell kan fortfarande vara rätt val.

Samma mönster syns i två vision-rader som går i motsatt riktning. KIE, extrahering av nyckelinformation från skannade formulär, ligger på 95,5 mot Lunas 97,5. Moderering av Hateful Memes ligger på 70,6 mot 71,2. Ingen av skillnaderna är stor, och båda ligger inom områden där Drex Maxs försprång på andra håll är trettio punkter stort, vilket tyder på att vision-kodaren är tränad mot skärmlayouter och diagram snarare än tryckta formulär eller memes.

Latensen gick också bakåt. Drex Max medianvärde på 183 ms är 32 ms långsammare än Drex 2.0 och 38 ms långsammare än Drex 1.5. I en loop som körs trettio gånger per uppgift innebär det ungefär en extra sekund per uppgift, mot flera sekunder som sparas per steg jämfört med en frontiermodell. Fortfarande rätt avvägning, men värt att veta att visionskodaren inte är gratis.

En siffra behöver särskiljas innan den citeras mot dig. De 174 ms i inledningsparagrafen är Naces skärmdumpsbaserade mätning – 243 bildfrågor, en förfrågan i taget, mot 253 ms för J​ev 1.14 på samma uppsättning. De 183 ms är medianen över hela benchmark-sviten i lanseringstabellen. Båda är Naces; de är olika mätningar, och den smickrande är den snävare.

Två fallgropar i API:et innan du kopplar ihop något

Dokumentationen innehåller en detalj som kommer att kosta någon en eftermiddag om de bara skummar igenom den. drex-latest pekar inte på Drex Max. Det är en fastnålad checkpoint, och aliaset löser upp till något annat. Alla som följer snabbstarten, byter in sin nyckel och anger TYPESAFE_DEFAULT_MODEL=drex-latest – vilket är exakt vad Jev-kompatibilitetsinstruktionerna säger att de ska göra – kommer att anropa en textbaserad modell och undra varför deras skärmbilder ignoreras.

Den andra fällan är storleken. API-guiden begränsar förfrågningar till åtta bilder och 131 072 token per fråga, inklusive bildtoken; lanseringsinlägget uppger 262K. Tills Nace har stämt av de två siffrorna bör du utgå från den mindre. Det finns ingen publicerad tokenkostnad per bild, vilket gör taket svårt att resonera kring i förväg: en skärmbild i full upplösning motsvarar inte ett fast antal token, och dokumentationen anger inte hur bilder skalas om eller delas upp i rutor.

En sak som är enklare än den befintliga lösningen: Drex Max accepterar skärmbilder i alla dimensioner. J​ev 1.14:s API avvisar bilder med en sida under 280 px eller över 1 568 px, vilket är den typ av begränsning som visar sig som ett tyst fel i en återförsöksloop klockan 2 på natten.

Vad detta gör med ett routingbeslut

Den praktiska frågan är inte huruvida Drex Max är bättre än en frontiermodell. Det är det inte, och det försöker inte vara det. Frågan är vilka av de trettio besluten i en uppgift som förtjänar en frontiermodell och vilka som förtjänar en sannolikhetsfördelning på 174 ms, och det är ett routingproblem innan det är ett modellproblem.

Drex Max finns inte på vår ruttlista. OrcaRouter-katalogen har den inte, och inget här ska läsas som ett tillgänglighetspåstående från oss – Nace säljer den via sitt eget API och sin egen konsol. Det vi däremot har är den befintliga lösning som den mäts mot. TypeSafe Jev 1.13 är en listad rutt till $0,042 per miljon indatatoken över en kontext på 65 536 token, som serveras via samma POST /v1/systemone body, så ett A/B-test mellan en beslutsmodell och din nuvarande screenshot-to-frontier-loop är en modellsträng snarare än en omskrivning. Det billiga sättet att avgöra detta är att behålla dina textbaserade beslutsanrop där de är, lägga till ett skärmläsningssteg bredvid dem för de uppgifter som behöver ögon, och mäta båda mot dina egna loggar i stället för Naces 140 178 poängsatta förfrågningar.

Den typen av uppdelning fungerar bara om delarna går att nå från en och samma plats. En nyckel för över 200 modeller, leverantörens listpris som förs vidare utan påslag per token, och automatisk redundansväxling mellan leverantörer är det som hindrar experimentet från att förfalla till en död gren när personen som satte upp det byter team. Det spelar också roll här av en specifik anledning: Drex Max är nytt, ej granskat och enbart API-baserat, och det säkra sättet att införa en obeprövad komponent är att lägga den bakom något som kan falla tillbaka på en känd modell när dess tillförlitlighet sjunker eller slutpunkten beter sig illa. Dirigera de säkra besluten till den billiga modellen och låt redundansväxlingen hantera resten.

Vad skulle ändra den här avläsningen?

Det första är en oberoende körning av Decision Index. Sviten är offentlig, {{1}}Nace säger att utvärderingarna är reproducerbara{{/1}}, och innan någon utanför företaget har kört Drex Max på den är {{2}}67,6 ett leverantörstal{{/2}}. Cellerna att hålla koll på när det händer är de som pekar i motsatta riktningar: en ledning på 30 poäng på Mind2Web bredvid en regression på When2Call är inte en jämn förmågekurva, den beskriver en modell som tränats hårt på "vilken av dessa är nästa klick" och mindre hårt på "bör jag klicka något alls". Om det håller är det det operativt viktigaste faktumet om Drex Max, och det finns inte med bland höjdpunkterna.

Produktionslatens under samtidighet är den andra. Naces egen genomströmningssiffra – cirka 25 förfrågningar per sekund på en H100-replika, inga fel upp till 64 samtidiga – gäller Drex i allmänhet, inte Max specifikt. Hela poängen med designen är att den ligger i en het kodväg vid varje steg, vilket gör p95 under belastning långt mer relevant än en median på 183 ms, och inget som publicerats tar upp det.

För det tredje behöver prissättningen ett genomräknat exempel med bilder i. $0.06 per miljon indatatokens är bara användbart om man vet vad en skärmbild kostar i tokens, och ingen publicerad siffra gör det. Ett team som budgeterar en 30-stegsloop med en 1440p-skärm per steg gissar tills Nace publicerar bildredovisningen eller någon mäter det.

Inget av det gör lanseringen mindre intressant. En beslutsmodell som ser är en genuint annan komponent än en chattmodell som ombeds titta på en skärmbild, och prisskillnaden är tillräckligt stor för att förändra vad en agent har råd att göra i varje steg. Det är bara ännu inte en siffra som någon utanför Nace har kontrollerat – och den del av tabellen som överlever kontakt med en verklig driftsättning blir förmodligen den del som ingen citerar.