Drex Max punta gli occhi sul modello decisionale — e fissa il prezzo di ogni clic a 0,06 dollari

Un agente computer-use non è davvero una singola decisione. Prenotare un volo ne richiede trenta: su quale campo fare clic, quale risultato aprire, se il widget del calendario ha finito di renderizzare, se la tariffa che sta guardando è quella che desidera. Ognuna di queste è un round trip di screenshot e, se il modello dall'altra parte è un modello chat di frontiera, ognuna costa secondi e una fattura da modello di frontiera. Drex Max, che Nace.AI ha rilasciato in disponibilità generale il 19 ottobre 2026, è un tentativo di far crollare quell'aritmetica. È un modello decisionale, non un modello chat: gli si fornisce una schermata e un insieme di opzioni tipizzate, e un singolo forward pass restituisce una probabilità per ciascuna opzione. Nace lo indica a 0,06 $ per milione di token di input, una latenza mediana di 183 ms e nessun costo di output, perché non scrive nulla. I guasti documentati dell'IA e gli incidenti degli agenti alla base di rilasci come questo sono raccolti nel OrcaRouter AI Incident Archive dove ogni voce riporta le proprie fonti, il livello di gravità, il grado di confidenza e l'indicatore di contestazione.

Il confronto che Nace pone accanto a ciò è TypeSafe J​ev 1.14, il modello decisionale che ha definito la forma delle richieste della categoria, e i modelli di frontiera general-purpose che gli agenti usano oggi. Nella tabella pubblicata da Nace stesso, ciò significa 10,17 $ per mille decisioni per Claude Opus 5.5 e circa 3,5 secondi per decisione, contro 0,06 $ e 174 ms per Drex Max sulle stesse 243 domande con screenshot. Numeri dei fornitori, eseguiti in autonomia, non verificati da nessuno al di fuori di Nace — ma l'ordine di grandezza è il punto, ed è il motivo per cui questo rilascio conta più della sua riga di benchmark.

Cosa è stato effettivamente spedito

Drex Max è il primo modello della linea Drex con un encoder visivo. Drex 2.0 e Drex 1.5 ricevevano testo e restituivano probabilità; Max legge screenshot, screencast, documenti scansionati, grafici, foto e fotogrammi video e risponde agli stessi tre tipi di domanda dei suoi predecessori.

• Model id — drex-max, fissato. Nessun peso aperto; ospitato tramite l'API proprietaria di Nace, senza checkpoint scaricabile.

• Forma dell'input — una stringa state più un oggetto questions, e un array images con un massimo di 8 immagini per richiesta. L'endpoint è POST /v1/systemone, lo stesso percorso usato da J​ev.

• Tipi di domanda — choice (opzioni con nome, restituisce una probabilità per opzione), noul (una domanda sì/no, restituisce P(true)), score (livelli ordinati, restituisce un livello atteso e una distribuzione). Più domande su uno stesso stato condividono un'unica passata.

• Contesto — 131.072 token per domanda, inclusi i token delle immagini, secondo la guida API. Il post di lancio afferma separatamente "finestra di contesto da 262K token". Questi due numeri non concordano, ed è la prima cosa da risolvere prima di dimensionare un buffer per gli screenshot.

• Prezzo — $0,06 per milione di token di input; l'output non viene fatturato. Nace cita la stessa cifra come $0,06 per mille decisioni, il che implica circa mille token per chiamata.

• Predecessori — Drex 2.0 (35B totali, circa 3B attivi, basato su Qwen3.6-35B-A3B, pesi aperti) a $0,06 per mille decisioni, e Drex 1.5 (9B, solo testo) a $0,04.

• Distribuzione — gestita sulle GPU di Nace, dedicata, all'interno di un account AWS o Azure del cliente, oppure air-gapped, il tutto con lo stesso contratto di richiesta. Nessun peso significa nessun self-hosting, ma non significa solo SaaS.

Non c'è nulla di esotico nell'interfaccia. È una scelta deliberata: Nace ha progettato Drex Max per essere compatibile a livello di protocollo con l'SDK Jev di TypeSafe, così @typesafe-ai/sdk continua a funzionare con base URL, chiave e modello predefinito modificati. La compatibilità non è un favore a un rivale. È così che un nuovo concorrente viene provato — la migrazione più economica è quella che si riduce a un valore di configurazione.

La parte che è davvero diversa: una distribuzione invece di una frase

Un modello di chat risponde a una domanda sull'uso del computer scrivendo il percorso verso una risposta. {{1}}"Guardando la pagina, i risultati di ricerca sembrano essersi caricati, quindi l'azione successiva dovrebbe essere fare clic sul secondo risultato"{{/1}} — e poi il tuo harness analizza quella frase, o un blob JSON, e spera che il modello non abbia scelto un'opzione che non hai mai offerto. {{2}}Il costo di questo design viene pagato due volte: una in token di output, e una nel parser che devi mantenere perché il modello può allucinare un pulsante che non è sullo schermo.{{/2}}

Drex Max non può farlo. Restituisce una probabilità sulle opzioni fornite e nient'altro. Se offri cinque candidati cliccabili, ottieni cinque numeri che sommano a uno. Si tratta di una capacità più limitata e molto più adatta a un ciclo, per tre ragioni che contano più in produzione che in una demo.

Il primo è il thresholding. Una distribuzione di probabilità ti consente di scrivere la regola che vuoi davvero: agisci quando l'opzione migliore supera 0,9, passa a un modello più lento o a un essere umano quando non lo fa. Un modello generativo ti fornisce una frase e un campo di confidenza che significa qualcosa di completamente diverso — di solito quanto era concentrata la distribuzione dei token, non quanto è probabile che la risposta sia corretta.

Il secondo è il comportamento in caso di errore. Un agente che può rispondere solo con opzioni dichiarate non può inventare un sesto pulsante. Può sbagliare, e può essere mal calibrato, ma non può produrre un'azione che il tuo harness non sappia come eseguire.

Il terzo è l'economia. Poiché non ci sono token di output, il costo di valutare dieci opzioni è lo stesso di valutarne due. L'impostazione di Nace è che questo lo rende abbastanza economico da chiamarlo a ogni passaggio, e a 0,06 $ per mille chiamate i conti tornano: anche un compito approssimativo di trenta passaggi costa meno di due decimi di centesimo in decisioni. Lo stesso compito con Opus 5.5, secondo il dato per decisione di Nace, costerebbe circa trenta centesimi: non fatale, ma trenta volte il prezzo di ciò che sta facendo.

La tabella dei benchmark, e di chi sono questi numeri

Ogni dato qui sotto proviene dal post di lancio di Nace. Il Decision Index 0.3.2 è una classifica pubblica di benchmark in stile decisionale, ma la run di Drex Max su di essa è di Nace stesso, realizzata con il kit ufficiale, e nessuno al di fuori di Nace l'ha riprodotta. Anche il punteggio "Full" della classifica combina test privati che non fanno parte di questa run. Considera la forma dei risultati informativa e i decimali come marketing.

Il dato principale è un Decision Index pubblico di 67,6, contro 61,3 di Drex 2.0, 58,1 di Drex 1.5, 60,7 di J​ev 1.14 e 47,8 di GPT-6 Luna Decisions. Sul Vision Index complementare — il numero che conta per un modello il cui punto di forza è la capacità di vedere — Drex Max segna 74,5 contro 63,9 di Luna.

• Mind2Web — 88,6 contro 81,2 per GPT-6 Luna Decisions, la riga più direttamente pertinente per gli agenti browser.

• OSWorld-Verified — 0,780 contro 0,756 di GPT-6 Sol e 0,790 di Claude Opus 5.5. Drex Max batte il primo e perde di poco contro il secondo.

• OSWorld-V2 — 0,737 rispetto a 0,744 per Sol e 0,761 per Opus 5.5. Stessa storia, divario leggermente più ampio.

• BFCL tool calling — 98,2, davanti al 96,4 di J​ev 1.14 e al 97,3 di Claude Opus 5.5, dietro solo a GPT-6 Sol.

• DecideBench — 98,5 sugli item e 97,0 sulle coppie, entrambi superiori a J​ev 1.14.

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

Le righe di OSWorld meritano un'avvertenza che la tabella di Nace non esplicita. Quei punteggi descrivono uno stack di automazione completo, e non è documentato quanto del ciclo attorno a Drex Max fosse anche l'harness di Nace. Un modello decisionale che sceglie bene l'azione successiva dipende comunque da ciò che cattura lo screenshot, attende i rendering e decide quando l'attività è conclusa. Leggi 0.780 come prova che le decisioni non sono il collo di bottiglia, non come una promessa sul tuo agente.

Dove perde, qual è la metà più utile della tabella

Le perdite non sono nascoste, ma è facile trascurarle, e due di esse descrivono limiti reali anziché rumore di arrotondamento.

Sulla conoscenza generale e sul ragionamento complesso, i modelli decisionali semplicemente non sono competitivi con i modelli chat di frontiera, e Drex Max non cambia questo. MMLU-Pro è 72,5, dietro l'82,1 di J​ev 1.14, il 93,0 di Sol e il 94,0 di Opus 5.5. HLE è 19,0 contro il 19,4 di J​ev — in ogni caso un pareggio nella parte bassa dell'intervallo. È prevedibile per un modello il cui compito è scegliere da un elenco ristretto data una schermata, ed è il motivo per cui un modello decisionale è un componente in un agente, non un sostituto del modello che pianifica.

Più interessante è la regressione rispetto al proprio predecessore. Su When2Call, che chiede se una chiamata a uno strumento sia del tutto giustificata, Drex Max ottiene 85,2, mentre Drex 2.0 arriva a 86,5 e il più vecchio ed economico Drex 1.5 segna 89,7. Il modello Drex più recente e più costoso è il peggiore dei tre nel capire quando non agire. Se il tuo flusso di lavoro dipende dalla capacità di trattenersi — un agente di supporto che dovrebbe restare in silenzio anziché chiamare uno strumento di rimborso — la capacità di visione non ti offre questo, e un modello testuale più economico potrebbe comunque essere la scelta giusta.

Lo stesso schema emerge in due righe della visione che vanno nella direzione opposta. KIE, l'estrazione di informazioni chiave da moduli scansionati, è 95,5 contro 97,5 di Luna. La moderazione di Hateful Memes è 70,6 contro 71,2. Nessuno dei due divari è ampio, ed entrambi si collocano in ambiti in cui il vantaggio di Drex Max altrove è ampio trenta punti, il che suggerisce che l'encoder visivo sia addestrato verso layout di schermo e grafici anziché moduli stampati o meme.

Anche la latenza è peggiorata. La mediana di 183 ms di Drex Max è 32 ms più alta di quella di Drex 2.0 e 38 ms più alta di quella di Drex 1.5. In un ciclo eseguito trenta volte per attività, ciò significa circa un secondo in più per attività, a fronte di diversi secondi risparmiati per passaggio rispetto a un modello di frontiera. Resta comunque un buon compromesso, ma è bene sapere che l'encoder visivo non è gratuito.

Un numero va distinto prima che vi venga citato. Il valore di 174 ms nel paragrafo iniziale è la misurazione di Nace basata solo sugli screenshot — 243 domande sulle immagini, una richiesta alla volta, contro i 253 ms di J​ev 1.14 sullo stesso set. Il valore di 183 ms è la mediana sull'intera suite di benchmark nella tabella di lancio. Entrambi sono di Nace; sono misurazioni diverse, e quella più lusinghiera è la più ristretta.

Due trappole nell'API prima di collegare qualsiasi cosa

La documentazione contiene un dettaglio che costerà a qualcuno un pomeriggio se la legge di fretta. drex-latest non punta a Drex Max. È un checkpoint bloccato, e l'alias rimanda a qualcos'altro. Chiunque segua la guida rapida, inserisca la propria chiave e imposti TYPESAFE_DEFAULT_MODEL=drex-latest — che è esattamente ciò che le istruzioni per la compatibilità con J​ev dicono di fare — finirà per chiamare un modello solo testo e chiedersi perché le sue schermate vengono ignorate.

La seconda trappola è la dimensione. La guida API limita le richieste a otto immagini e 131.072 token per domanda, inclusi i token delle immagini; il post di lancio pubblicizza 262K. Finché Nace non concilia i due valori, dimensiona sulla cifra più piccola. Non è pubblicato alcun costo in token per immagine, il che rende difficile ragionare in anticipo sul limite: uno screenshot a piena risoluzione non corrisponde a un numero fisso di token e la documentazione non indica come le immagini vengano ridimensionate o suddivise in tile.

Una cosa più semplice rispetto alla soluzione attuale: Drex Max accetta screenshot di qualsiasi dimensione. L'API di J​ev 1.14 rifiuta le immagini con un lato inferiore a 280 px o superiore a 1.568 px, il tipo di vincolo che si manifesta come un errore silenzioso in un ciclo di retry alle 2 del mattino.

Che effetto ha questo su una decisione di routing

La questione pratica non è se Drex Max sia migliore di un modello di frontiera. Non lo è, e non cerca di esserlo. La questione è quali delle trenta decisioni di un compito meritino un modello di frontiera e quali meritino una distribuzione di probabilità da 174 ms, e questo è un problema di instradamento prima ancora che un problema di modello.

Drex Max non è nella nostra lista di route. Il catalogo OrcaRouter non lo include, e nulla di quanto segue va inteso come una dichiarazione di disponibilità da parte nostra — Nace lo vende tramite la propria API e la propria console. Quello che offriamo è invece l'incumbent con cui viene confrontato. TypeSafe Jev 1.13 è una route in elenco a $0,042 per milione di token di input su un contesto di 65.536 token, servita tramite lo stesso POST /v1/systemone body, così un A/B tra un modello decisionale e il vostro attuale ciclo screenshot-to-frontier è una stringa di modello anziché una riscrittura. Il modo economico per risolvere la questione è mantenere le vostre chiamate decisionali solo testo dove sono, aggiungere accanto ad esse un passaggio di lettura dello schermo per le attività che richiedono occhi, e misurare entrambi rispetto ai vostri log anziché alle 140.178 richieste valutate di Nace.

Quel tipo di suddivisione funziona solo se i pezzi sono raggiungibili da un unico punto. Una chiave per oltre 200 modelli, prezzo di listino del provider passato così com'è, senza alcun ricarico per token, e failover automatico tra provider è ciò che impedisce all'esperimento di trasformarsi in un ramo obsoleto una volta che la persona che l'ha configurato cambia team. Qui conta anche per un motivo specifico: Drex Max è nuovo, non sottoposto a audit e solo API, e il modo sicuro di adottare un componente non collaudato è metterlo dietro qualcosa che possa passare a un modello noto quando il suo livello di confidenza scende o l'endpoint si comporta male. Instrada le decisioni ad alta confidenza verso il modello economico e lascia che il failover gestisca il resto.

Cosa cambierebbe questa lettura

{{1}}Un'esecuzione indipendente del Decision Index è la prima cosa.{{/1}} La suite è pubblica, {{2}}Nace dice che le valutazioni sono riproducibili{{/2}}, e finché qualcuno esterno all'azienda non eseguirà Drex Max su di essa, {{3}}il 67.6 è un numero del fornitore{{/3}}. Le celle da tenere d'occhio quando ciò accadrà sono quelle che puntano in direzioni opposte: {{4}}un vantaggio di 30 punti su Mind2Web accanto a una regressione su When2Call{{/4}} non è una curva di capacità regolare, descrive un modello addestrato intensamente su "quale di questi è il prossimo clic" e meno intensamente su "dovrei cliccare qualcosa". Se questo si conferma, {{5}}è il fatto operativamente più importante riguardo a Drex Max{{/5}} e non è nei punti salienti.

La seconda questione è la latenza in produzione in condizioni di concorrenza. Il dato di throughput dichiarato da Nace — circa 25 richieste al secondo su una singola replica H100, senza errori fino a 64 richieste in volo — riguarda Drex in generale, non specificamente Max. L'intera proposta del design è che esso si colloca in un percorso critico (hot path) a ogni passo, il che rende il p95 sotto carico molto più rilevante di una mediana di 183 ms, e nulla di quanto pubblicato lo affronta.

Terzo, il prezzo necessita di un esempio pratico con immagini. 0,06 $ per milione di token di input è utile solo se sai quanto costa uno screenshot in token, e nessun dato pubblicato lo fa. Un team che deve fare un budget per un ciclo di 30 passaggi con uno schermo 1440p per passaggio sta solo tirando a indovinare finché Nace non pubblica la rendicontazione delle immagini o qualcuno non la misura.

Nessuna di queste cose rende il rilascio meno interessante. Un modello decisionale che vede è un componente genuinamente diverso da un modello conversazionale a cui viene chiesto di guardare uno screenshot, e il divario di prezzo è abbastanza ampio da cambiare ciò che un agente può permettersi di fare a ogni passo. È solo che non è ancora un numero che qualcuno al di fuori di Nace abbia verificato — e la parte della tabella che sopravvive al contatto con un deployment reale sarà probabilmente la parte che nessuno sta citando.