Drex Max przygląda się modelowi decyzyjnemu — i wycenia każde kliknięcie na 0,06 USD

Agent korzystający z komputera tak naprawdę nie podejmuje jednej decyzji. Rezerwacja lotu to ich trzydzieści: w które pole kliknąć, który wynik otworzyć, czy widżet kalendarza zakończył renderowanie, czy taryfa, na którą patrzy, jest tą, której chce. Każda z nich to rundka zrzutu ekranu, a jeśli model po drugiej stronie jest czołowym modelem czatu, każda kosztuje sekundy i rachunek jak za model z czołówki. Drex Max, który Nace.AI udostępnił jako ogólnie dostępny 19 października 2026 r., jest próbą zredukowania tej arytmetyki. To model decyzyjny, a nie model czatu — podajesz mu ekran i zestaw opcji wraz z ich typami, a jedno przejście w przód zwraca prawdopodobieństwo dla każdej opcji. Nace podaje cenę 0,06 USD za milion tokenów wejściowych, medianę opóźnienia 183 ms i brak opłaty za wyjście, ponieważ nic nie zapisuje. Udokumentowane awarie AI i incydenty z agentami stojące za takimi wydaniami jak to są zebrane w OrcaRouter AI Incident Archive, gdzie każdy wpis zawiera własne źródła, poziom krytyczności, stopień pewności i flagę sporności.

Dla porównania Nace zestawia z tym TypeSafe J​ev 1.14, model decyzyjny, który zdefiniował kształt zapytań w tej kategorii, oraz modele frontier ogólnego przeznaczenia, których agenci używają dziś. W opublikowanej przez samego Nace tabeli to 10,17 USD za tysiąc decyzji dla Claude Opus 5.5 i około 3,5 sekundy na decyzję, wobec 0,06 USD i 174 ms dla Drex Max w przypadku tych samych 243 pytań ze zrzutów ekranu. Liczby dostawcy, uzyskane samodzielnie, niezweryfikowane przez nikogo spoza Nace — ale to rząd wielkości jest tu sednem i dlatego to wydanie ma większe znaczenie niż jego wiersz w benchmarku.

Co faktycznie zostało wydane

Drex Max to pierwszy model z linii Drex z enkoderem wizyjnym. Drex 2.0 i Drex 1.5 przyjmowały na wejściu tekst, a zwracały prawdopodobieństwo; Max odczytuje zrzuty ekranu, nagrania ekranu, zeskanowane dokumenty, wykresy, zdjęcia i klatki wideo oraz odpowiada na te same trzy typy pytań co jego poprzednicy.

• Identyfikator modelu — drex-max, przypięty. Brak otwartych wag; udostępniany przez własne API Nace, bez checkpointu do pobrania.

• Kształt danych wejściowych — stan w postaci ciągu znaków oraz pytania w postaci obiektu, a także obrazy w postaci tablicy zawierającej do 8 obrazów na żądanie. Endpoint to POST /v1/systemone, ta sama ścieżka, której używa J​ev.

• Typy pytań — choice (nazwane opcje, zwraca prawdopodobieństwo dla każdej opcji), noul (pytanie tak/nie, zwraca P(true)), score (uporządkowane poziomy, zwraca oczekiwany poziom i rozkład). Kilka pytań dotyczących jednego stanu korzysta z jednego przebiegu.

• Kontekst — 131 072 tokeny na pytanie, łącznie z tokenami obrazów, zgodnie z przewodnikiem API. Wpis premierowy osobno podaje „okno kontekstu 262K tokenów”. Te dwie liczby się nie zgadzają i to jest pierwsza rzecz do rozwiązania, zanim określisz rozmiar bufora zrzutów ekranu.

• Cena — $0.06 za milion tokenów wejściowych; za dane wyjściowe nie są naliczane opłaty. Nace podaje tę samą kwotę jako $0.06 za tysiąc decyzji, co sugeruje około tysiąca tokenów na wywołanie.

• Poprzednicy — Drex 2.0 (łącznie 35B, około 3B aktywnych, zbudowany na Qwen3.6-35B-A3B, otwarte wagi) po 0,06 USD za tysiąc decyzji oraz Drex 1.5 (9B, tylko tekst) po 0,04 USD.

• Wdrożenie — zarządzane na GPU Nace, dedykowane, wewnątrz konta AWS lub Azure klienta albo w środowisku odizolowanym (air-gapped), zawsze z tym samym kontraktem żądań. Brak wag oznacza brak własnego hostingu, ale nie oznacza wyłącznie SaaS.

W interfejsie nie ma nic egzotycznego. To celowe: Nace zbudował Drex Max tak, aby był kompatybilny na poziomie protokołu z SDK J​ev firmy TypeSafe, więc @typesafe-ai/sdk nadal działa po zmianie bazowego URL, klucza i domyślnego modelu. Ta kompatybilność nie jest uprzejmością wobec rywala. W ten sposób nowy gracz zostaje wypróbowany — najtańsza migracja to ta, która jest wartością konfiguracji.

Część, która jest naprawdę inna: rozkład zamiast zdania

Model czatu odpowiada na pytanie dotyczące korzystania z komputera, pisząc swoją drogę do odpowiedzi. „Patrząc na stronę, wygląda na to, że wyniki wyszukiwania się załadowały, więc następnym działaniem powinno być kliknięcie drugiego wyniku” — a następnie Twoje środowisko testowe parsuje to zdanie lub obiekt JSON i ma nadzieję, że model nie wybrał opcji, której nigdy nie zaproponowałeś. Koszt takiego rozwiązania ponosi się dwukrotnie: raz w tokenach wyjściowych, a raz w parserze, który musisz utrzymywać, ponieważ model może halucynować przycisk, którego nie ma na ekranie.

Drex Max nie potrafi tego zrobić. Zwraca wyłącznie prawdopodobieństwo dla opcji, które podasz, i nic więcej. Jeśli zaproponujesz pięć klikalnych kandydatów, otrzymasz pięć liczb, których suma wynosi jeden. To węższa zdolność i znacznie lepiej pasuje do pętli, z trzech powodów, które mają większe znaczenie w środowisku produkcyjnym niż w wersji demonstracyjnej.

Pierwsze to progowanie. Rozkład prawdopodobieństwa pozwala zapisać regułę, której naprawdę chcesz: działaj, gdy najlepsza opcja przekracza 0,9, a gdy nie — eskaluj do wolniejszego modelu lub człowieka. Model generatywny daje ci zdanie i pole pewności, które oznacza coś zupełnie innego — zwykle to, jak bardzo skoncentrowany był rozkład tokenów, a nie jak prawdopodobne jest, że odpowiedź jest poprawna.

Drugi to zachowanie w przypadku niepowodzenia. Agent, który może odpowiadać wyłącznie zadeklarowanymi opcjami, nie może wymyślić szóstego przycisku. Może się mylić i może być źle skalibrowany, ale nie może wygenerować działania, którego twoje środowisko wykonawcze nie umie wykonać.

Po trzecie – ekonomika. Ponieważ nie ma tokenów wyjściowych, koszt oceny dziesięciu opcji jest taki sam jak koszt oceny dwóch. Nace ujmuje to tak, że dzięki temu jest to wystarczająco tanie, by wywoływać to na każdym kroku, a przy $0.06 za tysiąc wywołań arytmetyka się zgadza: nawet niestarannie wykonane zadanie o trzydziestu krokach kosztuje poniżej dwóch dziesiątych centa na decyzje. To samo zadanie w przypadku Opus 5.5, według stawki Nace'a za decyzję, kosztowałoby około trzydziestu centów – nie zabójczo, ale trzydzieści razy więcej niż koszt rzeczy, którą wykonuje.

Tabela benchmarków i czyje są te liczby

Każda liczba poniżej pochodzi z postu premierowego Nace'a. Decision Index 0.3.2 to publiczny ranking benchmarków typu decyzyjnego, ale przebieg Drex Max w nim jest własnym przebiegiem Nace'a, z użyciem oficjalnego zestawu narzędzi, i nikt spoza Nace'a go nie odtworzył. Wynik „Full” tego rankingu uwzględnia też prywatne testy, które nie są częścią tego przebiegu. Traktuj ogólny kształt wyników jako wskazówkę, a miejsca po przecinku jako marketing.

W nagłówku podano publiczny Indeks Decyzji wynoszący 67.6 wobec 61.3 dla Drex 2.0, 58.1 dla Drex 1.5, 60.7 dla J​ev 1.14 i 47.8 dla GPT-6 Luna Decisions. W towarzyszącym Indeksie Wizji — liczbie, która ma znaczenie dla modelu, którego atutem sprzedażowym jest widzenie — Drex Max uzyskuje 74.5 wobec 63.9 Luny.

• Mind2Web — 88,6 vs 81,2 dla GPT-6 Luna Decisions, najbardziej bezpośrednio istotny wiersz dla agentów przeglądarkowych.

• OSWorld-Verified — 0,780 vs 0,756 dla GPT-6 Sol i 0,790 dla Claude Opus 5.5. Drex Max pokonuje pierwszego i nieznacznie przegrywa z drugim.

• OSWorld-V2 — 0,737 vs 0,744 dla Sol i 0,761 dla Opus 5.5. To samo, tylko nieco większa różnica.

• wywoływanie narzędzi BFCL — 98,2, przed J​ev 1.14 (96,4) i Claude Opus 5.5 (97,3), ustępując jedynie GPT-6 Sol.

• DecideBench — 98,5 w przypadku elementów i 97,0 w przypadku par, oba wyniki lepsze niż w J​ev 1.14.

• Decyzje biznesowe vs J​ev 1.14 — FinEntity 92.3 vs 81.9, BANKING77 90.0 vs 79.7, ContractNLI 75.9 vs 57.7.

Wiersze OSWorld zasługują na zastrzeżenie, którego tabela Nace'a nie precyzuje. Te wyniki opisują pełny stos automatyzacji i nie udokumentowano, jak duża część pętli wokół Drex Max była również własnym środowiskiem testowym Nace'a. Model decyzyjny, który dobrze wybiera następne działanie, nadal zależy od tego, co wykonuje zrzut ekranu, czeka na wyrenderowanie i decyduje, kiedy zadanie jest ukończone. Traktuj 0,780 jako dowód, że decyzje nie są wąskim gardłem, a nie jako obietnicę dotyczącą twojego agenta.

W czym przegrywa — która połowa tabeli jest bardziej użyteczna

Straty nie są ukryte, ale łatwo je przeoczyć, a dwie z nich opisują rzeczywiste ograniczenia, a nie szum zaokrągleń.

Pod względem wiedzy ogólnej i trudnego rozumowania modele decyzyjne po prostu nie są konkurencyjne wobec czołowych modeli czatowych, a Drex Max tego nie zmienia. MMLU-Pro wynosi 72,5, za 82,1 J​ev 1.14, 93,0 Sol i 94,0 Opus 5.5. HLE wynosi 19,0 wobec 19,4 J​ev — tak czy inaczej remis na dole zakresu. Jest to oczekiwane w przypadku modelu, którego zadaniem jest wybór z krótkiej listy na podstawie ekranu, i dlatego model decyzyjny jest komponentem agenta, a nie zamiennikiem modelu, który planuje.

Bardziej interesujący jest regres względem własnego poprzednika. W When2Call, który pyta, czy wywołanie narzędzia jest w ogóle uzasadnione, Drex Max uzyskuje 85,2, podczas gdy Drex 2.0 osiąga 86,5, a starszy, tańszy Drex 1.5 zdobywa 89,7. Najnowszy i najdroższy model Drex jest najgorszy z trzech, jeśli chodzi o rozpoznawanie, kiedy nie należy działać. Jeśli Twój przepływ pracy zależy od powściągliwości — agent wsparcia, który powinien milczeć, zamiast wywoływać narzędzie do zwrotów — możliwości wizyjne tego Ci nie zapewnią, a tańszy model tekstowy może nadal być właściwym wyborem.

Ten sam wzorzec widać w dwóch wierszach dotyczących widzenia, które wypadają w przeciwnym kierunku. KIE, ekstrakcja kluczowych informacji ze skanowanych formularzy, wynosi 95,5 wobec 97,5 dla Luny. Moderacja Hateful Memes wynosi 70,6 wobec 71,2. Żadna z tych różnic nie jest duża, a obie dotyczą dziedzin, w których przewaga Drex Max w innych obszarach wynosi trzydzieści punktów, co sugeruje, że enkoder wizyjny jest trenowany raczej pod kątem układów ekranów i wykresów niż drukowanych formularzy czy memów.

Opóźnienie również się pogorszyło. Mediana 183 ms w Drex Max jest o 32 ms wyższa niż w Drex 2.0 i o 38 ms wyższa niż w Drex 1.5. W pętli uruchamianej trzydzieści razy na zadanie daje to około dodatkowej sekundy na zadanie, wobec kilku sekund oszczędności na krok w porównaniu z modelem frontier. To wciąż właściwy kompromis, ale warto wiedzieć, że enkoder wizyjny nie jest darmowy.

Jedną liczbę trzeba wyodrębnić, zanim ktoś ci ją zacytuje. 174 ms w pierwszym akapicie to pomiar Nace'a dotyczący wyłącznie zrzutów ekranu — 243 pytania obrazkowe, jedno żądanie naraz, w porównaniu z 253 ms dla J​ev 1.14 na tym samym zestawie. 183 ms to mediana w całym zestawie testów porównawczych w tabeli z premiery. Oba pochodzą od Nace'a; to różne pomiary, a ten pochlebniejszy jest tym węższym.

Dwie pułapki w API, zanim cokolwiek podłączysz

Dokumentacja zawiera szczegół, który kosztuje kogoś całe popołudnie, jeśli tylko prześlizgnie się po niej wzrokiem. drex-latest nie wskazuje na Drex Max. To przypięty punkt kontrolny, a alias wskazuje na coś innego. Każdy, kto postępuje zgodnie z quickstartem, wstawia swój klucz i ustawia TYPESAFE_DEFAULT_MODEL=drex-latest — co dokładnie każą robić instrukcje zgodności z J​ev — będzie wywoływać model wyłącznie tekstowy i zastanawiać się, dlaczego jego zrzuty ekranu są ignorowane.

Druga pułapka to rozmiar. Przewodnik API ogranicza żądania do ośmiu obrazów i 131 072 tokenów na pytanie, łącznie z tokenami obrazów; wpis premierowy reklamuje 262 tys. Dopóki Nace nie pogodzi tych dwóch wartości, kieruj się mniejszą liczbą. Nie opublikowano kosztu tokenów na obraz, co utrudnia z góry ocenę limitu: zrzut ekranu w pełnej rozdzielczości nie ma stałej liczby tokenów, a dokumentacja nie mówi, jak obrazy są skalowane ani dzielone na kafelki.

Jedna rzecz jest łatwiejsza niż u dotychczasowego rozwiązania: Drex Max akceptuje zrzuty ekranu o dowolnych wymiarach. API J​ev 1.14 odrzuca obrazy, których bok ma mniej niż 280 px lub więcej niż 1568 px, co jest rodzajem ograniczenia, które ujawnia się jako cichy błąd w pętli ponowień o 2 w nocy.

Jak to wpływa na decyzję dotyczącą routingu

Praktyczne pytanie nie brzmi, czy Drex Max jest lepszy od modelu frontierowego. Nie jest i nie próbuje być. Pytanie brzmi, które z trzydziestu decyzji w zadaniu zasługują na model frontierowy, a które na 174-milisekundowy rozkład prawdopodobieństwa, i to jest problem routingu, zanim staje się problemem modelu.

Drex Max nie znajduje się na naszej liście tras. Katalog OrcaRouter go nie zawiera i niczego tutaj nie należy odczytywać jako naszej deklaracji dostępności — Nace sprzedaje go przez własne API i własną konsolę. To, co oferujemy, to model dotychczasowy, wobec którego jest oceniany. TypeSafe Jev 1.13 to pozycja na liście tras w cenie $0.042 za milion tokenów wejściowych przy kontekście 65,536 tokenów, obsługiwana przez ten sam POST /v1/systemone format treści żądania, więc test A/B między modelem decyzyjnym a Twoją obecną pętlą od zrzutu ekranu do modelu frontier to zmiana ciągu modelu, a nie przepisanie. Tanim sposobem rozstrzygnięcia tego jest pozostawienie wywołań decyzyjnych obsługujących tylko tekst tam, gdzie są, dodanie obok nich kroku odczytu ekranu w zadaniach wymagających oczu i porównanie obu z własnymi logami, a nie z 140,178 ocenionymi żądaniami Nace.

Tego rodzaju podział działa tylko wtedy, gdy do wszystkich elementów można dotrzeć z jednego miejsca. Jeden klucz na ponad 200 modeli, cena listowa dostawcy przekazywana bez narzutu za token, oraz automatyczne przełączanie awaryjne między dostawcami to właśnie powstrzymuje eksperyment przed przekształceniem się w przestarzałą gałąź, gdy osoba, która go skonfigurowała, zmieni zespół. Ma to tu również znaczenie z konkretnego powodu: Drex Max jest nowy, nieaudytowany i dostępny wyłącznie przez API, a bezpiecznym sposobem wdrożenia nie sprawdzonego komponentu jest umieszczenie go za czymś, co może przełączyć się na znany model, gdy spadnie jego pewność lub punkt końcowy zacznie działać nieprawidłowo. Kieruj pewne decyzje do taniego modelu, a resztę pozostaw mechanizmowi przełączania awaryjnego.

Co zmieniłoby ten odczyt?

Niezależne uruchomienie Decision Index to pierwsza rzecz, którą trzeba zrobić. Zestaw testów jest publiczny, Nace twierdzi, że ewaluacje są powtarzalne, a dopóki ktoś spoza firmy nie uruchomi na nim Drex Max, 67.6 pozostaje liczbą podaną przez dostawcę. Komórki, którym trzeba się przyjrzeć, gdy to nastąpi, to te wskazujące w przeciwnych kierunkach: 30-punktowa przewaga na Mind2Web obok regresji na When2Call nie jest gładką krzywą możliwości; opisuje model wytrenowany mocno na „który z tych elementów jest następnym kliknięciem” i słabiej na „czy w ogóle powinienem coś kliknąć”. Jeśli to się potwierdzi, jest to najważniejszy operacyjnie fakt dotyczący Drex Max i nie ma go w najważniejszych punktach.

Opóźnienie produkcyjne przy współbieżności to druga kwestia. Podana przez Nace'a wartość przepustowości — około 25 żądań na sekundę na jednej replice H100, bez błędów przy do 64 równocześnie przetwarzanych żądaniach — dotyczy ogólnie Drex, a nie konkretnie Max. Cała koncepcja tego projektu opiera się na tym, że znajduje się on w gorącej ścieżce na każdym kroku, co sprawia, że p95 pod obciążeniem jest znacznie istotniejsze niż mediana 183 ms, a nic opublikowanego tego nie omawia.

Po trzecie, cennik wymaga przykładu obliczeniowego z obrazami. $0.06 za milion tokenów wejściowych jest przydatne tylko wtedy, gdy wiesz, ile tokenów kosztuje zrzut ekranu, a żadna opublikowana liczba tego nie pokazuje. Zespół planujący budżet na 30-krokową pętlę z ekranem 1440p na każdym kroku zgaduje, dopóki Nace nie opublikuje rozliczenia obrazów albo ktoś tego nie zmierzy.

Nic z tego nie sprawia, że wydanie jest mniej interesujące. Model decyzyjny, który widzi, to naprawdę inny komponent niż model czatu, który ma spojrzeć na zrzut ekranu, a różnica cen jest wystarczająco duża, by zmienić, na co agent może sobie pozwolić na każdym kroku. To po prostu jeszcze nie liczba, którą ktokolwiek spoza Nace sprawdził — a część tabeli, która przetrwa zetknięcie z rzeczywistym wdrożeniem, będzie prawdopodobnie tą częścią, której nikt nie cytuje.