Drex Max se penche sur le modèle de décision — et fixe chaque clic à 0,06 $.

Un agent d'usage informatique ne prend pas vraiment une seule décision. Réserver un vol, c'est une trentaine de décisions : sur quel champ cliquer, quel résultat ouvrir, si le widget de calendrier a fini de s'afficher, si le tarif qu'il consulte est bien celui qu'il veut. Chacune d'elles est un aller-retour de capture d'écran, et si le modèle à l'autre bout est un modèle de chat de pointe, chacune coûte des secondes et une facture de modèle de pointe. Drex Max, que Nace.AI a rendu disponible en général le 19 octobre 2026, est une tentative de réduire cette arithmétique. C'est un modèle de décision plutôt qu'un modèle de chat — on lui fournit un écran et un ensemble d'options typées, et une seule passe avant renvoie une probabilité pour chaque option. Nace l'annonce à 0,06 $ par million de jetons d'entrée, pour une latence médiane de 183 ms et sans aucun frais de sortie, puisqu'il n'écrit rien. Les défaillances de l'IA et les incidents d'agents documentés qui se cachent derrière des versions comme celle-ci sont recensés dans le OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, un niveau de gravité, une note de confiance et un indicateur de contestation.

La comparaison que Nace met en regard de cela est TypeSafe J​ev 1.14, le modèle de décision qui a défini la forme des requêtes de la catégorie, et les modèles de pointe généralistes que les agents utilisent aujourd'hui. Sur le tableau publié par Nace lui-même, cela représente 10,17 $ pour mille décisions avec Claude Opus 5.5 et environ 3,5 secondes par décision, contre 0,06 $ et 174 ms pour Drex Max sur les mêmes 243 questions de captures d'écran. Des chiffres du fournisseur, obtenus par lui-même, non audités par quiconque en dehors de Nace — mais l'ordre de grandeur est ce qui compte, et c'est pourquoi cette version compte davantage que sa ligne de benchmark.

Ce qui a réellement été livré

Drex Max est le premier modèle de la gamme Drex doté d’un encodeur visuel. Drex 2.0 et Drex 1.5 prenaient du texte en entrée et produisaient des probabilités en sortie ; Max lit les captures d’écran, les screencasts, les documents numérisés, les graphiques, les photos et les images vidéo, et répond aux mêmes trois types de questions que ses prédécesseurs.

• ID du modèle — drex-max, épinglé. Aucun poids ouvert ; hébergé via l'API propre à Nace, sans checkpoint téléchargeable.

• Structure d’entrée — une chaîne state plus un questions objet, et un tableau d’images pouvant contenir jusqu’à 8 images par requête. Le point de terminaison est POST /v1/systemone, le même chemin que J​ev utilise.

• Types de questions — choice (options nommées, renvoie une probabilité par option), noul (une question oui/non, renvoie P(true)), score (niveaux ordonnés, renvoie un niveau attendu et une distribution). Plusieurs questions sur un même état partagent une seule passe.

• Contexte — 131 072 tokens par question, tokens d’image inclus, selon le guide de l’API. Le billet de lancement indique séparément « une fenêtre de contexte de 262K tokens ». Ces deux nombres ne concordent pas, et c’est la première chose à résoudre avant de dimensionner un buffer de capture d’écran.

• Prix — 0,06 $ par million de jetons d’entrée ; la sortie n’est pas facturée. Nace cite le même chiffre sous la forme de 0,06 $ par millier de décisions, ce qui implique environ un millier de jetons par appel.

• Prédécesseurs — Drex 2.0 (35B au total, environ 3B actifs, basé sur Qwen3.6-35B-A3B, poids ouverts) à 0,06 $ pour mille décisions, et Drex 1.5 (9B, texte uniquement) à 0,04 $.

• Déploiement — géré sur les GPU de Nace, en dédié, au sein d'un compte AWS ou Azure du client, ou en environnement isolé (air-gap), le tout avec le même contrat de requête. L'absence de poids signifie l'absence d'auto-hébergement, mais pas un modèle SaaS uniquement.

Il n’y a rien d’exotique dans l’interface. C’est délibéré : Nace a conçu Drex Max pour être compatible au niveau du protocole avec le SDK J​ev de TypeSafe, afin que @typesafe-ai/sdk continue de fonctionner avec une URL de base, une clé et un modèle par défaut modifiés. Cette compatibilité n’est pas une courtoisie envers un rival. C’est ainsi qu’on essaie un nouvel entrant — la migration la moins coûteuse est celle qui se résume à une valeur de configuration.

La partie qui est vraiment différente : une distribution plutôt qu’une phrase

Un modèle de chat répond à une question d'utilisation d'un ordinateur en écrivant son chemin vers une réponse. « En regardant la page, les résultats de recherche semblent avoir été chargés, donc la prochaine action devrait être de cliquer sur le deuxième résultat » — puis votre harnais analyse cette phrase, ou un blob JSON, en espérant que le modèle n'a pas choisi une option que vous n'avez jamais proposée. Le coût de cette conception se paie deux fois : une fois en tokens de sortie, et une fois dans le parseur que vous devez maintenir parce que le modèle peut halluciner un bouton qui n'est pas à l'écran.

Drex Max ne peut pas faire cela. Il renvoie une probabilité sur les options que vous avez fournies, et rien d’autre. Si vous proposez cinq candidats cliquables, vous obtenez cinq nombres dont la somme vaut un. C’est une capacité plus étroite, et bien mieux adaptée à une boucle, pour trois raisons qui comptent davantage en production que dans une démo.

Le premier est le seuillage. Une distribution de probabilités vous permet d’écrire la règle que vous voulez réellement : agissez lorsque l’option en tête dépasse 0,9, transférez à un modèle plus lent ou à un humain lorsque ce n’est pas le cas. Un modèle génératif vous donne une phrase et un champ de confiance qui signifie quelque chose de complètement différent — généralement à quel point la distribution des tokens était pointue, et non la probabilité que la réponse soit correcte.

La seconde est le comportement en cas d’échec. Un agent qui ne peut répondre qu’avec des options déclarées ne peut pas inventer un sixième bouton. Il peut se tromper, et il peut être mal calibré, mais il ne peut pas produire une action que votre harness ne sait pas exécuter.

Le troisième point est l’économie. Comme il n’y a pas de jetons de sortie, le coût pour évaluer dix options est le même que pour en évaluer deux. Selon la formulation de Nace, cela le rend suffisamment bon marché pour être appelé à chaque étape, et à 0,06 $ les mille appels, l’arithmétique tient : même une tâche bâclée de trente étapes coûte moins de deux dixièmes de cent en décisions. La même tâche avec Opus 5.5, selon le chiffre par décision de Nace, coûterait environ trente cents — pas rédhibitoire, mais trente fois le prix de ce qu’elle fait.

Le tableau de référence, et à qui appartiennent ces chiffres

Chaque chiffre ci-dessous provient de l'article de lancement de Nace. Le Decision Index 0.3.2 est un classement public de benchmarks de type décisionnel, mais l'exécution de Drex Max sur ce classement est propre à Nace, réalisée avec le kit officiel, et personne en dehors de Nace ne l'a reproduite. Le score « Full » du classement mélange aussi des tests privés qui ne font pas partie de cette exécution. Considérez la forme des résultats comme informative et les décimales comme du marketing.

Le chiffre clé est un indice Decision Index public de 67,6, contre 61,3 pour Drex 2.0, 58,1 pour Drex 1.5, 60,7 pour J​ev 1.14 et 47,8 pour GPT-6 Luna Decisions. Sur l’indice Vision Index complémentaire — le chiffre qui compte pour un modèle dont l’atout est de voir — Drex Max obtient 74,5 contre 63,9 pour Luna.

• Mind2Web — 88,6 contre 81,2 pour GPT-6 Luna Decisions, la ligne la plus directement pertinente pour les agents de navigation.

• OSWorld-Verified — 0,780 contre 0,756 pour GPT-6 Sol et 0,790 pour Claude Opus 5.5. Drex Max bat le premier et s'incline de peu face au second.

• OSWorld-V2 — 0,737 contre 0,744 pour Sol et 0,761 pour Opus 5.5. Même constat, un écart légèrement plus large.

• BFCL tool calling — 98,2, devant les 96,4 de J​ev 1.14 et les 97,3 de Claude Opus 5.5, derrière seulement GPT-6 Sol.

• DecideBench — 98,5 sur les éléments et 97,0 sur les paires, tous deux devant J​ev 1.14.

• Décisions commerciales vs J​ev 1.14 — FinEntity 92,3 vs 81,9, BANKING77 90,0 vs 79,7, ContractNLI 75,9 vs 57,7.

Les lignes OSWorld méritent une mise en garde que le tableau de Nace n’explicite pas. Ces scores décrivent une pile d’automatisation complète, et il n’est pas documenté quelle part de la boucle autour de Drex Max provenait également du harnais propre à Nace. Un modèle de décision qui choisit bien l’action suivante dépend encore de ce qui prend la capture d’écran, attend les rendus et décide quand la tâche est terminée. Lisez 0,780 comme la preuve que les décisions ne sont pas le goulot d’étranglement, et non comme une promesse concernant votre agent.

Là où il perd, quelle est la moitié la plus utile du tableau

Les pertes ne sont pas enfouies, mais il est facile de les survoler, et deux d’entre elles décrivent de véritables limites plutôt qu’un simple bruit d’arrondi.

En connaissances générales et en raisonnement difficile, les modèles de décision ne sont tout simplement pas compétitifs face aux modèles de chat de pointe, et Drex Max n’y change rien. MMLU-Pro est à 72,5, derrière les 82,1 de J​ev 1.14, les 93,0 de Sol et les 94,0 d’Opus 5.5. HLE est à 19,0 contre 19,4 pour J​ev — une égalité, dans un cas comme dans l’autre, en bas de la fourchette. C’est attendu pour un modèle dont le rôle est de choisir dans une liste courte à partir d’un écran, et c’est pourquoi un modèle de décision est un composant d’un agent, et non un remplacement du modèle qui planifie.

Plus intéressant encore est la régression par rapport à son propre prédécesseur. Sur When2Call, qui consiste à déterminer si un appel d'outil est justifié ou non, Drex Max obtient 85,2, tandis que Drex 2.0 atteint 86,5 et que le plus ancien et moins cher Drex 1.5 obtient 89,7. Le modèle Drex le plus récent et le plus cher est le moins bon des trois pour savoir quand ne pas agir. Si votre flux de travail repose sur la retenue — un agent de support qui devrait rester silencieux plutôt que d'appeler un outil de remboursement —, la capacité de vision ne vous l'apporte pas, et un modèle textuel moins cher peut encore être le bon choix.

Le même schéma apparaît dans deux lignes de vision qui vont dans l’autre sens. KIE, l’extraction d’informations clés sur des formulaires numérisés, obtient 95,5 contre 97,5 pour Luna. La modération de Hateful Memes est de 70,6 contre 71,2. Aucun des deux écarts n’est important, et tous deux concernent des domaines où l’avantage de Drex Max ailleurs est de trente points d’écart, ce qui suggère que l’encodeur de vision est entraîné davantage pour les mises en page d’écran et les graphiques que pour les formulaires imprimés ou les mèmes.

La latence a également régressé. La latence médiane de Drex Max, 183 ms, est supérieure de 32 ms à celle de Drex 2.0 et de 38 ms à celle de Drex 1.5. Dans une boucle exécutée trente fois par tâche, cela représente environ une seconde ajoutée par tâche, contre plusieurs secondes gagnées par étape par rapport à un modèle de pointe. Le compromis reste le bon, mais il vaut la peine de savoir que l’encodeur visuel n’est pas gratuit.

Il faut distinguer deux chiffres avant qu’on ne vous les cite. Les 174 ms du paragraphe d’ouverture correspondent à la mesure de Nace limitée aux captures d’écran — 243 questions sur des images, une requête à la fois, contre 253 ms pour J​ev 1.14 sur le même ensemble. Les 183 ms sont la médiane sur l’ensemble de la suite de benchmarks dans le tableau de lancement. Les deux sont de Nace ; ce sont des mesures différentes, et la plus flatteuse est la plus étroite.

Deux pièges dans l’API avant de tout brancher

La documentation contient un détail qui coûtera un après-midi à quiconque le survole. drex-latest ne pointe pas vers Drex Max. C'est un checkpoint épinglé, et l'alias se résout vers autre chose. Quiconque suit le démarrage rapide, remplace sa clé et définit TYPESAFE_DEFAULT_MODEL=drex-latest — ce que les instructions de compatibilité J​ev leur disent exactement de faire — appellera un modèle exclusivement textuel et se demandera pourquoi ses captures d'écran sont ignorées.

Le deuxième piège, c'est la taille. Le guide de l'API plafonne les requêtes à huit images et 131 072 tokens par question, tokens d'image inclus ; l'article de lancement annonce 262 K. Tant que Nace n'a pas concilié les deux, dimensionnez sur le chiffre le plus bas. Aucun coût en tokens par image n'est publié, ce qui rend le plafond difficile à anticiper : une capture d'écran en pleine résolution ne représente pas un nombre fixe de tokens, et la documentation ne précise ni comment les images sont redimensionnées, ni comment elles sont découpées en tuiles.

Un point plus simple que chez le concurrent : Drex Max accepte des captures d'écran de n'importe quelle dimension. L'API de J​ev 1.14 rejette les images dont un côté mesure moins de 280 px ou plus de 1 568 px, le genre de contrainte qui se manifeste par un échec silencieux dans une boucle de nouvelles tentatives à 2 h du matin.

Ce que cela fait à une décision de routage

La question pratique n’est pas de savoir si Drex Max est meilleur qu’un modèle de pointe. Il ne l’est pas, et il n’essaie pas de l’être. La question est de savoir lesquelles des trente décisions d’une tâche méritent un modèle de pointe et lesquelles méritent une distribution de probabilités en 174 ms, et c’est un problème de routage avant d’être un problème de modèle.

Drex Max ne figure pas sur notre liste de routes. Le catalogue OrcaRouter ne le référence pas, et rien ici ne doit être interprété comme une affirmation de notre part quant à sa disponibilité — Nace le vend via sa propre API et sa propre console. Ce que nous proposons, en revanche, c’est le modèle en place auquel il est comparé. TypeSafe Jev 1.13 est une route répertoriée à 0,042 $ par million de tokens d’entrée sur un contexte de 65 536 tokens, servi via le même corps POST /v1/systemone, de sorte qu’un A/B entre un modèle de décision et votre boucle actuelle capture d’écran → modèle frontière tient à une chaîne de modèle plutôt qu’à une réécriture. Le moyen le plus économique de trancher est de laisser vos appels de décision uniquement texte là où ils sont, d’ajouter à côté une étape de lecture d’écran pour les tâches qui ont besoin d’yeux, et de mesurer les deux par rapport à vos propres journaux plutôt qu’aux 140 178 requêtes évaluées de Nace.

Ce type de découpage ne fonctionne que si les éléments sont accessibles depuis un seul endroit. Une seule clé pour plus de 200 modèles, le prix catalogue du fournisseur répercuté sans marge par token, et le basculement automatique entre fournisseurs, voilà ce qui empêche l'expérience de se dégrader en branche obsolète une fois que la personne qui l'a mise en place change d'équipe. Cela compte aussi ici pour une raison précise : Drex Max est nouveau, non audité et uniquement disponible via API, et la manière sûre d'adopter un composant non éprouvé consiste à le placer derrière quelque chose capable de se rabattre sur un modèle connu lorsque sa confiance baisse ou que le point de terminaison se comporte mal. Orientez les décisions sûres vers le modèle bon marché et laissez le basculement gérer le reste.

Qu'est-ce qui changerait cette lecture ?

La première chose à faire est une exécution indépendante du Decision Index. La suite est publique, Nace affirme que les évaluations sont reproductibles, et tant que personne en dehors de l’entreprise n’aura fait tourner Drex Max dessus, le 67,6 est un chiffre de fournisseur. Les cellules à surveiller lorsque cela se produira sont celles qui pointent dans des directions opposées : une avance de 30 points sur Mind2Web à côté d’une régression sur When2Call ne forme pas une courbe de capacités régulière ; cela décrit un modèle entraîné intensivement sur « lequel de ces éléments est le prochain clic » et moins intensivement sur « dois-je cliquer sur quoi que ce soit ». Si cela se confirme, c’est le fait le plus important sur le plan opérationnel concernant Drex Max, et il ne figure pas parmi les points saillants.

La latence de production sous concurrence est le second point. Le chiffre de débit de Nace lui-même — environ 25 requêtes par seconde sur une réplique H100, sans erreur jusqu’à 64 requêtes en vol — concerne Drex en général, pas Max spécifiquement. Tout l’argument du design est qu’il intervient dans un chemin critique à chaque étape, ce qui rend le p95 sous charge bien plus pertinent qu’une médiane de 183 ms, et rien de publié ne traite ce point.

Troisièmement, la tarification a besoin d’un exemple concret incluant des images. Un tarif de 0,06 $ par million de jetons d’entrée n’est utile que si l’on sait combien coûte une capture d’écran en jetons, et aucun chiffre publié ne le fait. Une équipe qui budgétise une boucle de 30 étapes avec un écran 1440p à chaque étape ne fait que deviner tant que Nace n’a pas publié la comptabilisation des images ou que quelqu’un ne l’a pas mesurée.

Rien de tout cela ne rend la version moins intéressante. Un modèle de décision qui voit est un composant véritablement différent d’un modèle de chat à qui l’on demande de regarder une capture d’écran, et l’écart de prix est assez important pour changer ce qu’un agent peut se permettre de faire à chaque étape. Ce n’est simplement pas encore un chiffre que quelqu’un d’extérieur à Nace a vérifié — et la partie du tableau qui résiste au contact d’un déploiement réel sera probablement celle que personne ne cite.