Drex Max nimmt das Entscheidungsmodell ins Visier — und bepreist jeden Klick mit 0,06 US-Dollar

Ein Computer-Use-Agent ist nicht wirklich eine einzige Entscheidung. Eine Flugbuchung besteht aus dreißig davon: welches Feld angeklickt werden muss, welches Ergebnis geöffnet werden soll, ob das Kalender-Widget fertig gerendert ist, ob der Tarif, den es gerade ansieht, der gewünschte ist. Jeder dieser Schritte ist ein Screenshot-Roundtrip, und wenn das Modell am anderen Ende ein Frontier-Chatmodell ist, kostet jeder einzelne Sekunden und eine Frontier-Modell-Rechnung. Drex Max, das Nace.AI am 19. Oktober 2026 als allgemein verfügbar veröffentlichte, ist ein Versuch, diese Rechnung zu reduzieren. Es ist ein Entscheidungsmodell und kein Chatmodell – man übergibt ihm einen Bildschirm und eine Reihe typisierter Optionen, und ein einziger Forward-Pass liefert für jede Option eine Wahrscheinlichkeit. Nace führt es mit 0,06 US-Dollar pro Million Eingabetoken, einer Medianlatenz von 183 ms und ohne jegliche Ausgabekosten, da es nichts schreibt. Die dokumentierten KI-Ausfälle und Agentenvorfälle hinter Veröffentlichungen wie dieser sind im OrcaRouter AI Incident Archive gesammelt, wo jeder Eintrag seine eigenen Quellen, seinen Schweregrad, seine Konfidenzstufe und seine Kennzeichnung als umstritten enthält.

Der Vergleich, den Nace daneben stellt, ist TypeSafe J​ev 1.14, das Entscheidungsmodell, das die Anfrageform dieser Kategorie definiert hat, sowie die generalistischen Frontier-Modelle, die Agenten heute nutzen. In Naces eigener veröffentlichter Tabelle sind das 10,17 US-Dollar pro tausend Entscheidungen für Claude Opus 5.5 und rund 3,5 Sekunden pro Entscheidung – gegenüber 0,06 US-Dollar und 174 ms für Drex Max bei denselben 243 Screenshot-Fragen. Herstellerangaben, selbst erhoben, von niemandem außerhalb von Nace geprüft – aber die Größenordnung ist der Punkt, und sie ist der Grund, warum dieses Release mehr zählt als seine Benchmark-Zeile.

Was tatsächlich ausgeliefert wurde

Drex Max ist das erste Modell der Drex-Reihe mit einem Vision-Encoder. Drex 2.0 und Drex 1.5 nahmen Text entgegen und gaben Wahrscheinlichkeiten aus; Max liest Screenshots, Screencasts, gescannte Dokumente, Diagramme, Fotos und Videoframes und beantwortet dieselben drei Fragetypen wie seine Vorgänger.

• Modell-ID — drex-max, gepinnt. Keine offenen Gewichte; über Naces eigene API gehostet, ohne herunterladbaren Checkpoint.

• Eingabeformat — ein state-String plus ein questions-Objekt und ein images-Array mit bis zu 8 Bildern pro Anfrage. Der Endpunkt ist POST /v1/systemone, derselbe Pfad, den J​ev verwendet.

• Fragetypen — choice (benannte Optionen, gibt eine Wahrscheinlichkeit pro Option zurück), noul (eine Ja/Nein-Frage, gibt P(true) zurück), score (geordnete Stufen, gibt eine erwartete Stufe und eine Verteilung zurück). Mehrere Fragen zu einem Zustand teilen sich einen einzigen Durchlauf.

• Kontext — 131.072 Token pro Frage, einschließlich Bild-Token, laut dem API-Leitfaden. Der Veröffentlichungsbeitrag sagt separat „Kontextfenster mit 262K Token“. Diese beiden Zahlen stimmen nicht überein, und das ist der erste Punkt, der geklärt werden muss, bevor Sie einen Screenshot-Puffer dimensionieren.

• Preis — $0.06 pro Million Eingabe-Tokens; für Ausgabe fallen keine Kosten an. Nace gibt denselben Wert mit $0.06 pro tausend Entscheidungen an, was etwa tausend Tokens pro Aufruf bedeutet.

• Vorgängermodelle — Drex 2.0 (35B insgesamt, etwa 3B aktiv, basiert auf Qwen3.6-35B-A3B, offene Gewichte) zu 0,06 $ pro tausend Entscheidungen und Drex 1.5 (9B, nur Text) zu 0,04 $.

• Bereitstellung — verwaltet auf Naces GPUs, dediziert, in einem AWS- oder Azure-Konto des Kunden oder air-gapped, alles mit demselben Request-Contract. Keine Gewichte bedeuten kein Self-Hosting, aber das bedeutet nicht, dass es nur SaaS ist.

An der Schnittstelle ist nichts Exotisches. Das ist Absicht: Nace hat Drex Max so gebaut, dass es protokollkompatibel mit dem J​ev SDK von TypeSafe ist, sodass @typesafe-ai/sdk weiterhin funktioniert, wenn Basis-URL, Schlüssel und Standardmodell geändert werden. Die Kompatibilität ist kein Entgegenkommen gegenüber einem Konkurrenten. Sie ist die Art und Weise, wie ein neuer Anbieter ausprobiert wird — die kostengünstigste Migration ist die, bei der es sich um einen Konfigurationswert handelt.

Der Teil, der wirklich anders ist: eine Verteilung statt eines Satzes

Ein Chat-Modell beantwortet eine Frage zur Computernutzung, indem es sich seine Antwort zusammenschreibt. „Wenn ich mir die Seite ansehe, scheinen die Suchergebnisse geladen zu sein, also sollte die nächste Aktion darin bestehen, auf das zweite Ergebnis zu klicken“ – und dann parst Ihre Testumgebung diesen Satz oder einen JSON-Blob und hofft, dass das Modell nicht eine Option gewählt hat, die Sie nie angeboten haben. Die Kosten dieses Designs werden doppelt bezahlt: einmal in Ausgabe-Tokens und einmal in dem Parser, den Sie pflegen müssen, weil das Modell eine Schaltfläche halluzinieren kann, die nicht auf dem Bildschirm ist.

Drex Max kann das nicht. Es liefert eine Wahrscheinlichkeit über die von Ihnen angegebenen Optionen und sonst nichts. Wenn Sie fünf anklickbare Kandidaten anbieten, erhalten Sie fünf Zahlen, die sich zu eins summieren. Das ist eine engere Fähigkeit und passt viel besser zu einer Schleife, aus drei Gründen, die in der Produktion mehr zählen als in einer Demo.

Das erste ist Schwellenwertbildung. Eine Wahrscheinlichkeitsverteilung ermöglicht es Ihnen, die Regel zu formulieren, die Sie tatsächlich wollen: Handeln, wenn die beste Option 0,9 überschreitet, andernfalls an ein langsameres Modell oder einen Menschen eskalieren. Ein generatives Modell liefert Ihnen einen Satz und ein Konfidenzfeld, das etwas völlig anderes bedeutet – meist, wie spitz die Token-Verteilung war, nicht, wie wahrscheinlich die Antwort richtig ist.

Das zweite ist Fehlerverhalten. Ein Agent, der nur mit deklarierten Optionen antworten kann, kann keinen sechsten Button erfinden. Er kann falsch liegen, und er kann schlecht kalibriert sein, aber er kann keine Aktion erzeugen, von der Ihr Harness nicht weiß, wie er sie ausführen soll.

Der dritte Punkt ist die Wirtschaftlichkeit. Da es keine Ausgabe-Tokens gibt, kostet das Bewerten von zehn Optionen dasselbe wie das Bewerten von zwei. Naces Argumentation ist, dass dies günstig genug ist, um es bei jedem Schritt aufzurufen, und bei 0,06 US-Dollar pro tausend Aufrufe geht die Rechnung auf: Selbst eine schludrige Aufgabe mit dreißig Schritten kostet bei den Entscheidungen weniger als zwei Zehntel eines Cents. Dieselbe Aufgabe mit Opus 5.5 würde nach Naces Wert pro Entscheidung etwa dreißig Cent kosten – nicht fatal, aber dreißigmal so teuer wie die Sache, die es tut.

Die Benchmark-Tabelle – und wessen Zahlen das sind

Jede Zahl unten stammt aus Naces Launch-Post. Der Decision Index 0.3.2 ist ein öffentliches Leaderboard für Benchmarks im Decision-Stil, aber der Drex Max-Lauf darauf ist Naces eigener, mit dem offiziellen Kit, und niemand außerhalb von Nace hat ihn reproduziert. Der „Full“-Score des Boards vermischt außerdem private Tests, die nicht Teil dieses Laufs sind. Betrachten Sie die Form der Ergebnisse als informativ und die Dezimalstellen als Marketing.

Die Schlagzeile lautet: ein öffentlicher Decision Index von 67,6 gegenüber 61,3 für Drex 2.0, 58,1 für Drex 1.5, 60,7 für J​ev 1.14 und 47,8 für GPT-6 Luna Decisions. Beim begleitenden Vision Index – der Zahl, die für ein Modell zählt, dessen Verkaufsargument das Sehen ist – erreicht Drex Max 74,5 gegenüber 63,9 für Luna.

• Mind2Web — 88,6 vs. 81,2 für GPT-6 Luna Decisions, die am direktesten relevante Zeile für Browser-Agenten.

• OSWorld-Verified — 0,780 vs. 0,756 für GPT-6 Sol und 0,790 für Claude Opus 5.5. Drex Max schlägt den ersten und unterliegt dem zweiten knapp.

• OSWorld-V2 — 0,737 gegenüber 0,744 für Sol und 0,761 für Opus 5.5. Gleiches Bild, etwas größerer Abstand.

• BFCL-Tool-Calling — 98,2, vor J​ev 1.14 mit 96,4 und Claude Opus 5.5 mit 97,3, nur hinter GPT-6 Sol.

• DecideBench — 98,5 bei Items und 97,0 bei Paaren, beides besser als Jev 1.14.

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

Die OSWorld-Zeilen verdienen einen Vorbehalt, den Naces Tabelle nicht ausdrücklich nennt. Diese Scores beschreiben einen vollständigen Automatisierungs-Stack, und es ist nicht dokumentiert, wie viel der Schleife um Drex Max ebenfalls Naces eigener Harness war. Ein Entscheidungsmodell, das die nächste Aktion gut auswählt, hängt dennoch von dem ab, was den Screenshot aufnimmt, auf Renders wartet und entscheidet, wann die Aufgabe erledigt ist. Lies 0.780 als Beleg dafür, dass die Entscheidungen nicht der Engpass sind, nicht als Versprechen in Bezug auf deinen Agenten.

Wo es verliert, welche die nützlichere Hälfte der Tabelle ist

Die Verluste sind nicht versteckt, aber leicht zu überfliegen, und zwei davon beschreiben reale Grenzen statt bloßes Rundungsrauschen.

Bei Allgemeinwissen und schwierigem Schlussfolgern sind die Entscheidungsmodelle schlicht nicht konkurrenzfähig mit Frontier-Chatmodellen, und Drex Max ändert daran nichts. MMLU-Pro liegt bei 72,5 und damit hinter J​ev 1.14 mit 82,1, Sol mit 93,0 und Opus 5.5 mit 94,0. HLE liegt bei 19,0 gegenüber J​ev mit 19,4 – so oder so ein Gleichstand am unteren Ende der Spanne. Das ist zu erwarten für ein Modell, dessen Aufgabe darin besteht, anhand eines Screens aus einer kurzen Liste auszuwählen, und es ist der Grund, warum ein Entscheidungsmodell eine Komponente in einem Agenten ist und kein Ersatz für das Modell, das plant.

Interessanter ist der Rückschritt gegenüber dem eigenen Vorgänger. Bei When2Call, wo es darum geht, ob ein Tool-Aufruf überhaupt gerechtfertigt ist, erzielt Drex Max 85,2, während Drex 2.0 86,5 erreicht und das ältere, günstigere Drex 1.5 89,7 erzielt. Das neueste und teuerste Drex-Modell ist von den dreien am schlechtesten darin zu erkennen, wann es nicht handeln sollte. Wenn Ihr Workflow auf Zurückhaltung angewiesen ist – ein Support-Agent, der lieber schweigen sollte, als ein Rückerstattungs-Tool aufzurufen –, dann bringt Ihnen die Vision-Fähigkeit das nicht, und ein günstigeres Textmodell kann nach wie vor die richtige Wahl sein.

Dasselbe Muster zeigt sich in zwei Vision-Zeilen, bei denen es andersherum ist. KIE, die Extraktion von Schlüsselinformationen aus gescannten Formularen, liegt bei 95,5 gegenüber 97,5 bei Luna. Die Moderation von Hateful Memes liegt bei 70,6 gegenüber 71,2. Keine der beiden Lücken ist groß, und beide liegen in Domänen, in denen Drex Max’ Vorsprung anderswo dreißig Punkte groß ist, was darauf hindeutet, dass der Vision-Encoder eher auf Bildschirmlayouts und Diagramme als auf gedruckte Formulare oder Memes trainiert ist.

Auch die Latenz hat sich verschlechtert. Der Median von Drex Max liegt bei 183 ms und damit 32 ms langsamer als bei Drex 2.0 sowie 38 ms langsamer als bei Drex 1.5. In einer Schleife, die pro Aufgabe dreißigmal läuft, bedeutet das etwa eine zusätzliche Sekunde pro Aufgabe – gegenüber mehreren Sekunden, die pro Schritt im Vergleich zu einem Frontier-Modell eingespart werden. Immer noch der richtige Kompromiss, aber man sollte wissen, dass der Vision-Encoder nicht kostenlos ist.

Eine Zahl muss man auseinanderhalten, bevor sie einem vorgehalten wird. Die 174 ms im Eröffnungsabsatz sind Naces reine Screenshot-Messung – 243 Bildfragen, eine Anfrage nach der anderen, gegenüber 253 ms für J​ev 1.14 auf demselben Set. Die 183 ms sind der Median über die gesamte Benchmark-Suite in der Launch-Tabelle. Beide stammen von Nace; es sind unterschiedliche Messungen, und die schmeichelhaftere ist die engere.

Zwei Fallstricke in der API, bevor du irgendetwas anschließt

Die Dokumentation enthält ein Detail, das jemanden einen Nachmittag kosten wird, wenn man sie nur überfliegt. drex-latest verweist nicht auf Drex Max. Es ist ein gepinnter Checkpoint, und der Alias verweist auf etwas anderes. Wer dem Quickstart folgt, seinen Schlüssel einsetzt und dann TYPESAFE_DEFAULT_MODEL=drex-latest — genau das, wozu die J​ev-Kompatibilitätsanweisungen auffordern — setzt, ruft ein reines Textmodell auf und wundert sich, warum seine Screenshots ignoriert werden.

Die zweite Falle ist die Größe. Der API-Leitfaden begrenzt Anfragen auf acht Bilder und 131.072 Tokens pro Frage einschließlich Bild-Tokens; im Launch-Beitrag werden 262K angegeben. Bis Nace die beiden Zahlen in Einklang bringt, sollte man mit dem kleineren Wert planen. Es gibt keine veröffentlichten Token-Kosten pro Bild, wodurch sich die Obergrenze im Voraus schwer einschätzen lässt: Ein Screenshot in voller Auflösung entspricht nicht einer festen Tokenzahl, und die Dokumentation sagt nicht, wie Bilder skaliert oder gekachelt werden.

Eine Sache, die einfacher ist als beim etablierten Anbieter: Drex Max akzeptiert Screenshots beliebiger Abmessungen. Die API von Jev 1.14 lehnt Bilder ab, deren eine Seite unter 280 px oder über 1.568 px liegt – eine Einschränkung, die sich um 2 Uhr nachts in einer Wiederholungsschleife als stiller Fehler bemerkbar macht.

Wie sich dies auf eine Routing-Entscheidung auswirkt

Die praktische Frage ist nicht, ob Drex Max besser ist als ein Frontier-Modell. Das ist es nicht, und es versucht es auch nicht. Die Frage ist, welche der dreißig Entscheidungen in einer Aufgabe ein Frontier-Modell verdienen und welche eine 174-ms-Wahrscheinlichkeitsverteilung verdienen, und das ist ein Routing-Problem, bevor es ein Modellproblem ist.

Drex Max steht nicht auf unserer Routenliste. Der OrcaRouter-Katalog führt es nicht, und nichts hier sollte als Verfügbarkeitsaussage von uns verstanden werden — Nace vertreibt es über seine eigene API und seine eigene Konsole. Was wir führen, ist der etablierte Anbieter, an dem es gemessen wird. TypeSafe Jev 1.13 ist eine gelistete Route zu $0.042 pro Million Eingabe-Tokens über einen Kontext von 65,536 Tokens, bereitgestellt über denselben POST /v1/systemone-Body, sodass ein A/B zwischen einem Entscheidungsmodell und Ihrer aktuellen Screenshot-zu-Frontier-Schleife eher ein Modellstring als eine Neuentwicklung ist. Der günstige Weg, das zu klären, besteht darin, Ihre rein textbasierten Entscheidungsaufrufe dort zu belassen, daneben einen Bildschirmleseschritt für die Aufgaben hinzuzufügen, die Augen brauchen, und beides anhand Ihrer eigenen Logs zu messen statt an Naces 140,178 bewerteten Anfragen.

Diese Art der Aufteilung funktioniert nur, wenn die Teile von einer Stelle aus erreichbar sind. Ein Schlüssel für über 200 Modelle, ein ohne tokenbezogenen Aufschlag weitergegebener Anbieter-Listenpreis und automatisches Failover über Anbieter hinweg – das ist es, was verhindert, dass das Experiment zu einem veralteten Zweig verkommt, sobald die Person, die es eingerichtet hat, das Team wechselt. Hier zählt das auch aus einem bestimmten Grund: Drex Max ist neu, nicht auditiert und nur per API verfügbar, und der sichere Weg, eine unerprobte Komponente einzuführen, besteht darin, sie hinter etwas zu stellen, das auf ein bekanntes Modell zurückfallen kann, wenn ihre Konfidenz sinkt oder der Endpunkt sich fehlerhaft verhält. Leite die Entscheidungen mit hoher Konfidenz an das günstige Modell und überlasse den Rest dem Failover.

Was würde diese Lesart ändern?

An erster Stelle steht ein unabhängiger Lauf des Decision Index. Die Suite ist öffentlich, Nace sagt, die Evals seien reproduzierbar, und solange niemand außerhalb des Unternehmens Drex Max darauf laufen lässt, ist die 67.6 eine Zahl des Anbieters. Die Zellen, die es dann zu beobachten gilt, sind jene, die in entgegengesetzte Richtungen weisen: ein Vorsprung von 30 Punkten bei Mind2Web neben einer Regression bei When2Call ist keine glatte Fähigkeitskurve, sondern beschreibt ein Modell, das stark auf „Welches davon ist der nächste Klick“ trainiert wurde und weniger stark auf „Sollte ich überhaupt etwas anklicken“. Wenn das Bestand hat, ist es die operativ wichtigste Tatsache über Drex Max, und sie steht nicht in den Highlights.

Die Produktionslatenz unter Nebenläufigkeit ist der zweite Punkt. Naces eigene Durchsatzzahl – etwa 25 Anfragen pro Sekunde auf einer H100-Replik, keine Fehler bis zu 64 gleichzeitig in Bearbeitung – gilt für Drex allgemein, nicht speziell für Max. Das gesamte Argument des Designs ist, dass es bei jedem Schritt in einem Hot Path sitzt, was p95 unter Last weit relevanter macht als einen Median von 183 ms, und nichts Veröffentlichtes geht darauf ein.

Drittens braucht die Preisgestaltung ein durchgerechnetes Beispiel mit Bildern. 0,06 US-Dollar pro Million Input-Token ist nur nützlich, wenn man weiß, was ein Screenshot in Token kostet, und keine veröffentlichte Zahl leistet das. Ein Team, das eine 30-Schritt-Schleife mit einem 1440p-Bildschirm pro Schritt kalkuliert, rät, bis Nace die Bildabrechnung veröffentlicht oder jemand sie misst.

Nichts davon macht die Veröffentlichung weniger interessant. Ein Entscheidungsmodell, das sehen kann, ist eine wirklich andere Komponente als ein Chatmodell, das gebeten wird, sich einen Screenshot anzusehen, und die Preisdifferenz ist groß genug, um zu verändern, was sich ein Agent bei jedem Schritt leisten kann. Es ist nur noch keine Zahl, die irgendjemand außerhalb von Nace überprüft hat – und der Teil der Tabelle, der den Kontakt mit einem echten Deployment übersteht, wird wahrscheinlich der Teil sein, den niemand zitiert.