Drex Max se fija en el modelo de decisión — y tasa cada clic en $0.06

Un agente de uso de computadora no es realmente una sola decisión. Reservar un vuelo son treinta: qué campo hacer clic, qué resultado abrir, si el widget de calendario ha terminado de renderizarse, si la tarifa que está mirando es la que quiere. Cada una de esas es un viaje de ida y vuelta de captura de pantalla, y si el modelo al otro lado es un modelo de chat de frontera, cada una cuesta segundos y una factura de modelo de frontera. Drex Max, que Nace.AI lanzó como disponible de forma general el 19 de octubre de 2026, es un intento de colapsar esa aritmética. Es un modelo de decisión en lugar de un modelo de chat — le entregas una pantalla y un conjunto de opciones tipadas, y una sola pasada hacia adelante devuelve una probabilidad para cada opción. Nace lo lista a $0.06 por millón de tokens de entrada, una latencia mediana de 183 ms y ningún cargo por salida, porque no escribe nada. Los fallos documentados de IA y los incidentes de agentes que hay detrás de lanzamientos como este se recopilan en la OrcaRouter AI Incident Archive donde cada entrada incluye sus propias fuentes, nivel de gravedad, calificación de confianza y marca de disputa.

La comparación que Nace pone junto a eso es TypeSafe J​ev 1.14, el modelo de decisión que definió la forma de las solicitudes de la categoría, y los modelos frontera de propósito general que los agentes usan hoy. En la propia tabla publicada por Nace, eso son 10,17 USD por cada mil decisiones para Claude Opus 5.5 y aproximadamente 3,5 segundos por decisión, frente a 0,06 USD y 174 ms para Drex Max en las mismas 243 preguntas de captura de pantalla. Cifras del proveedor, ejecutadas por ellos mismos, sin auditar por nadie fuera de Nace — pero el orden de magnitud es lo importante, y es la razón por la que este lanzamiento importa más que su fila en el benchmark.

Lo que realmente se envió

Drex Max es el primer modelo de la línea Drex con un codificador visual. Drex 2.0 y Drex 1.5 eran de entrada de texto y salida de probabilidad; Max lee capturas de pantalla, grabaciones de pantalla, documentos escaneados, gráficos, fotos y fotogramas de vídeo, y responde a los mismos tres tipos de preguntas que sus predecesores.

• ID del modelo — drex-max, fijado. Sin pesos abiertos; alojado mediante la propia API de Nace, sin checkpoint descargable.

• Forma de la entrada — una state de tipo string más un objeto questions, y un images arreglo de hasta 8 imágenes por solicitud. El endpoint es POST /v1/systemone, la misma ruta que usa J​ev.

• Tipos de pregunta — choice (opciones con nombre, devuelve una probabilidad por opción), noul (una pregunta de sí/no, devuelve P(true)), score (niveles ordenados, devuelve un nivel esperado y una distribución). Varias preguntas sobre un mismo estado comparten una sola pasada.

• Contexto — 131.072 tokens por pregunta, incluidos los tokens de imagen, según la guía de la API. La publicación de lanzamiento dice por separado "ventana de contexto de 262K tokens". Esos dos números no coinciden, y es lo primero que hay que resolver antes de dimensionar un búfer de capturas de pantalla.

• Precio — $0.06 por millón de tokens de entrada; la salida no se factura. Nace cita la misma cifra como $0.06 por cada mil decisiones, lo que implica aproximadamente mil tokens por llamada.

• Predecesores — Drex 2.0 (35B en total, unos 3B activos, basado en Qwen3.6-35B-A3B, pesos abiertos) a $0.06 por cada mil decisiones, y Drex 1.5 (9B, solo texto) a $0.04.

• Despliegue — gestionado en las GPU de Nace, dedicado, dentro de una cuenta de AWS o Azure del cliente, o en un entorno aislado (air-gapped), todo con el mismo contrato de solicitudes. Que no haya pesos significa que no hay autoalojamiento, pero no significa que sea únicamente SaaS.

No hay nada exótico en la interfaz. Es algo deliberado: Nace diseñó Drex Max para ser compatible a nivel de conexión con el SDK J​ev de TypeSafe, de modo que @typesafe-ai/sdk siga funcionando con solo cambiar la URL base, la clave y el modelo predeterminado. Esa compatibilidad no es una cortesía hacia un rival. Es la manera en que un nuevo competidor consigue que lo prueben: la migración más barata es la que se reduce a un valor de configuración.

La parte que es genuinamente diferente: una distribución en lugar de una oración

Un modelo de chat responde una pregunta de uso de computadora escribiendo su camino hacia una respuesta. "Al observar la página, los resultados de búsqueda parecen haberse cargado, así que la siguiente acción debería ser hacer clic en el segundo resultado" — y luego tu harness analiza esa oración, o un bloque JSON, y espera que el modelo no haya elegido una opción que nunca ofreciste. El costo de ese diseño se paga dos veces: una en tokens de salida y otra en el parser que tienes que mantener porque el modelo puede alucinar un botón que no está en la pantalla.

Drex Max no puede hacer eso. Devuelve una probabilidad sobre las opciones que le proporcionaste y nada más. Si ofreces cinco candidatos en los que se puede hacer clic, obtienes cinco números que suman uno. Se trata de una capacidad más limitada y mucho más adecuada para un bucle, por tres razones que importan más en producción que en una demo.

La primera es la umbralización. Una distribución de probabilidad permite escribir la regla que realmente se quiere: actuar cuando la opción principal supera 0,9, y escalar a un modelo más lento o a una persona cuando no lo hace. Un modelo generativo da una frase y un campo de confianza que significa algo completamente distinto —normalmente, cuán concentrada estaba la distribución de tokens, no cuán probable es que la respuesta sea correcta.

El segundo es el comportamiento ante fallos. Un agente que solo puede responder con las opciones declaradas no puede inventar un sexto botón. Puede equivocarse y puede estar mal calibrado, pero no puede producir una acción que tu harness no sepa cómo ejecutar.

El tercero es el aspecto económico. Como no hay tokens de salida, el coste de puntuar diez opciones es el mismo que el de puntuar dos. El planteamiento de Nace es que esto lo abarata lo suficiente como para llamarlo en cada paso y, a 0,06 $ por cada mil llamadas, las cuentas cuadran: incluso una tarea descuidada de treinta pasos cuesta menos de dos décimas de centavo en decisiones. La misma tarea frente a Opus 5.5, según la cifra por decisión de Nace, costaría unos treinta centavos; no es fatal, pero es treinta veces el precio de lo que está haciendo.

La tabla de benchmarks, y de quién son estos números

Todas las cifras que aparecen a continuación provienen de la publicación de lanzamiento de Nace. El Decision Index 0.3.2 es una tabla de clasificación pública de benchmarks de toma de decisiones, pero la ejecución de Drex Max en él es la propia de Nace, realizada con el kit oficial, y nadie fuera de Nace la ha reproducido. La puntuación «Full» de la tabla también combina pruebas privadas que no forman parte de esta ejecución. Considera la forma de los resultados como informativa y los decimales como marketing.

El titular es un Índice de Decisión público de 67,6, frente a 61,3 para Drex 2.0, 58,1 para Drex 1.5, 60,7 para J​ev 1.14 y 47,8 para GPT-6 Luna Decisions. En el Índice de Visión complementario —la cifra que importa para un modelo cuyo atractivo es ver—, Drex Max obtiene 74,5 frente a 63,9 de Luna.

• Mind2Web — 88,6 frente a 81,2 de GPT-6 Luna Decisions, la fila más directamente relevante para agentes de navegador.

• OSWorld-Verified — 0,780 frente a 0,756 de GPT-6 Sol y 0,790 de Claude Opus 5.5. Drex Max supera al primero y pierde por un margen estrecho contra el segundo.

• OSWorld-V2 — 0,737 frente a 0,744 de Sol y 0,761 de Opus 5.5. La misma historia, con una brecha ligeramente mayor.

• Llamada de herramientas BFCL — 98,2, por delante del 96,4 de Jev 1.14 y del 97,3 de Claude Opus 5.5, solo por detrás de GPT-6 Sol.

• DecideBench — 98,5 en ítems y 97,0 en pares, ambos por delante de J​ev 1.14.

• Decisiones de negocio vs J​ev 1.14 — FinEntity 92.3 vs 81.9, BANKING77 90.0 vs 79.7, ContractNLI 75.9 vs 57.7.

Las filas de OSWorld merecen una salvedad que la tabla de Nace no explicita. Esas puntuaciones describen una pila de automatización completa, y no está documentado qué parte del bucle alrededor de Drex Max era también el propio arnés de Nace. Un modelo de decisión que elige bien la siguiente acción sigue dependiendo de lo que sea que esté tomando la captura de pantalla, esperando los renderizados y decidiendo cuándo está terminada la tarea. Lee 0.780 como evidencia de que las decisiones no son el cuello de botella, no como una promesa sobre tu agente.

Donde pierde, cuál es la mitad más útil de la tabla

Las pérdidas no están ocultas, pero es fácil pasarlas por alto, y dos de ellas describen límites reales en lugar de ruido de redondeo.

En conocimiento general y razonamiento complejo, los modelos de decisión sencillamente no compiten con los modelos de chat de vanguardia, y Drex Max no cambia eso. MMLU-Pro es 72,5, por detrás del 82,1 de J​ev 1.14, el 93,0 de Sol y el 94,0 de Opus 5.5. HLE es 19,0 frente al 19,4 de J​ev: un empate en el extremo inferior del rango en cualquier caso. Esto es lo esperable para un modelo cuya tarea es elegir de una lista corta a partir de una pantalla, y es la razón por la que un modelo de decisión es un componente dentro de un agente, no un sustituto del modelo que planifica.

Más interesante resulta la regresión frente a su propio predecesor. En When2Call, que pregunta si una llamada a una herramienta está justificada en absoluto, Drex Max obtiene 85,2, mientras que Drex 2.0 logra 86,5 y el más antiguo y barato Drex 1.5 obtiene 89,7. El modelo Drex más nuevo y más caro es el peor de los tres a la hora de saber cuándo no actuar. Si tu flujo de trabajo depende de la contención —un agente de soporte que debería permanecer en silencio en lugar de llamar a una herramienta de reembolso—, la capacidad de visión no te aporta eso, y un modelo de texto más barato puede seguir siendo la elección correcta.

El mismo patrón se observa en dos filas de visión que van en la dirección opuesta. KIE, la extracción de información clave en formularios escaneados, es de 95,5 frente a 97,5 de Luna. La moderación de Hateful Memes es de 70,6 frente a 71,2. Ninguna de las diferencias es grande, y ambas se sitúan en dominios donde la ventaja de Drex Max en otros aspectos es de treinta puntos, lo que sugiere que el codificador de visión está entrenado hacia diseños de pantalla y gráficos en lugar de formularios impresos o memes.

La latencia también empeoró. La mediana de 183 ms de Drex Max es 32 ms más lenta que la de Drex 2.0 y 38 ms más lenta que la de Drex 1.5. En un bucle que se ejecuta treinta veces por tarea, eso supone alrededor de un segundo añadido por tarea, frente a varios segundos ahorrados por paso en comparación con un modelo frontier. Sigue siendo la decisión correcta, pero conviene saber que el codificador de visión no sale gratis.

Hay una cifra que conviene separar antes de que te la citen. Los 174 ms del párrafo inicial son la medición de Nace basada únicamente en capturas de pantalla —243 preguntas de imágenes, una solicitud a la vez—, frente a los 253 ms de Jev 1.14 en el mismo conjunto. Los 183 ms son la mediana de toda la suite de pruebas de referencia en la tabla de lanzamiento. Ambas son de Nace; son mediciones distintas, y la que resulta favorable es la más restringida.

Dos trampas en la API antes de conectar nada

La documentación contiene un detalle que le costará una tarde a alguien si la lee por encima. drex-latest no apunta a Drex Max. Es un checkpoint fijado, y el alias resuelve a otra cosa. Cualquiera que siga el inicio rápido, introduzca su clave y establezca TYPESAFE_DEFAULT_MODEL=drex-latest — que es exactamente lo que le indican las instrucciones de compatibilidad con J​ev — estará llamando a un modelo solo de texto y preguntándose por qué se ignoran sus capturas de pantalla.

La segunda trampa es el tamaño. La guía de la API limita las solicitudes a ocho imágenes y 131.072 tokens por pregunta, incluidos los tokens de imagen; la publicación de lanzamiento anuncia 262K. Hasta que Nace concilie ambas cifras, dimensiona para la cifra menor. No hay publicado ningún costo de tokens por imagen, lo que hace difícil razonar de antemano sobre el límite: una captura de pantalla a resolución completa no equivale a un número fijo de tokens, y la documentación no indica cómo se redimensionan o dividen las imágenes.

Una cosa que es más fácil que con el sistema actual: Drex Max acepta capturas de pantalla de cualquier dimensión. La API de J​ev 1.14 rechaza las imágenes con un lado inferior a 280 px o superior a 1.568 px, el tipo de restricción que se manifiesta como un fallo silencioso en un bucle de reintentos a las 2 de la madrugada.

Qué efecto tiene esto en una decisión de enrutamiento

La pregunta práctica no es si Drex Max es mejor que un modelo de frontera. No lo es, y no pretende serlo. La cuestión es cuáles de las treinta decisiones de una tarea merecen un modelo de frontera y cuáles merecen una distribución de probabilidad de 174 ms, y eso es un problema de enrutamiento antes que un problema de modelo.

Drex Max no está en nuestra lista de rutas. El catálogo de OrcaRouter no lo incluye, y nada de lo que hay aquí debe interpretarse como una declaración de disponibilidad por nuestra parte — Nace lo vende a través de su propia API y su propia consola. Lo que sí tenemos es el modelo establecido contra el que se compara. TypeSafe Jev 1.13 es una ruta listada a $0,042 por millón de tokens de entrada con un contexto de 65.536 tokens, servido a través del mismo POST /v1/systemone como cuerpo de solicitud, así que un A/B entre un modelo de decisión y tu bucle actual de captura de pantalla a modelo frontier es cuestión de una cadena de modelo en lugar de una reescritura. La forma económica de resolver esto es mantener tus llamadas de decisión de solo texto donde están, añadir un paso de lectura de pantalla junto a ellas para las tareas que necesitan ojos, y medir ambos contra tus propios registros en lugar de las 140.178 solicitudes puntuadas de Nace.

Ese tipo de división solo funciona si se puede acceder a las piezas desde un único lugar. Una sola clave para más de 200 modelos, el precio de lista del proveedor repercutido sin recargo por token, y la conmutación automática por error entre proveedores son lo que impide que el experimento degenere en una rama obsoleta una vez que la persona que lo configuró cambia de equipo. También importa aquí por una razón concreta: Drex Max es nuevo, no auditado y solo disponible mediante API, y la forma segura de adoptar un componente no probado es ponerlo detrás de algo que pueda recurrir a un modelo conocido cuando su confianza disminuya o el endpoint funcione mal. Dirige las decisiones con confianza al modelo barato y deja que la conmutación por error se encargue del resto.

¿Qué cambiaría esta lectura?

Lo primero es una ejecución independiente del Decision Index. La suite es pública, Nace dice que las evaluaciones son reproducibles y, hasta que alguien fuera de la empresa ejecute Drex Max en ella, el 67.6 es un número de proveedor. Las celdas que hay que observar cuando eso ocurra son las que apuntan en direcciones opuestas: una ventaja de 30 puntos en Mind2Web junto a una regresión en When2Call no es una curva de capacidad uniforme; describe un modelo entrenado a fondo en «cuál de estos es el siguiente clic» y menos a fondo en «¿debería hacer clic en algo?». Si eso se sostiene, es el hecho más importante en términos operativos sobre Drex Max y no está en los puntos destacados.

La latencia de producción bajo concurrencia es la segunda. La propia cifra de rendimiento de Nace —unos 25 solicitudes por segundo en una réplica H100, sin errores hasta 64 en vuelo— corresponde a Drex en general, no específicamente a Max. Todo el argumento del diseño es que se sitúa en una ruta crítica en cada paso, lo que hace que el p95 bajo carga sea mucho más relevante que una mediana de 183 ms, y nada de lo publicado lo aborda.

Tercero, la fijación de precios necesita un ejemplo resuelto con imágenes. $0.06 por millón de tokens de entrada solo es útil si sabes cuánto cuesta una captura de pantalla en tokens, y ninguna cifra publicada lo hace. Un equipo que presupuesta un bucle de 30 pasos con una pantalla de 1440p por paso está adivinando hasta que Nace publique la contabilidad de imágenes o alguien la mida.

Nada de eso hace que el lanzamiento sea menos interesante. Un modelo de decisión que ve es un componente genuinamente distinto de un modelo de chat al que se le pide mirar una captura de pantalla, y la diferencia de precio es lo bastante grande como para cambiar lo que un agente puede permitirse hacer en cada paso. Es solo que aún no es una cifra que alguien fuera de Nace haya comprobado — y la parte de la tabla que sobreviva al contacto con un despliegue real probablemente será la parte que nadie está citando.