Drex Max присматривается к модели принятия решений — и оценивает каждый клик в $0.06

Компьютерный агент — это на самом деле не одно решение. Бронирование авиабилета — это тридцать решений: в какое поле нажать, какой результат открыть, закончил ли календарь отрисовку, тот ли это тариф, который нужен. Каждый из этих шагов — это круговой обмен со скриншотом, и если модель на другом конце — передовая чат-модель, каждый стоит секунд и счёта за передовую модель. Drex Max, которую Nace.AI выпустила в общий доступ 19 октября 2026 года, — попытка сломать эту арифметику. Это модель принятия решений, а не чат-модель: вы передаёте ей экран и набор типизированных вариантов, и один прямой проход возвращает вероятность для каждого варианта. Nace указывает цену $0,06 за миллион входных токенов, медианную задержку 183 мс и полное отсутствие платы за выход, потому что она ничего не пишет. Документированные сбои ИИ и инциденты с агентами, стоящие за подобными релизами, собраны в OrcaRouter AI Incident Archive, где каждая запись имеет собственные источники, уровень серьёзности, степень уверенности и отметку об оспаривании.

Сравнение, которое Nace ставит рядом с этим, — это TypeSafe J​ev 1.14, модель принятия решений, определившая форму запросов в этой категории, и универсальные передовые модели, которые агенты используют сегодня. В собственной опубликованной таблице Nace это $10.17 за тысячу решений для Claude Opus 5.5 и примерно 3,5 секунды на решение против $0.06 и 174 мс у Drex Max на тех же 243 вопросах по скриншотам. Цифры вендора, полученные им самостоятельно и не проверенные никем за пределами Nace, — но суть в порядке величины, и именно поэтому этот выпуск важнее, чем его строка в бенчмарке.

Что на самом деле было выпущено

Drex Max — первая модель в линейке Drex с визуальным энкодером. Drex 2.0 и Drex 1.5 работали по принципу «на входе текст — на выходе вероятность»; Max читает скриншоты, записи экрана, сканированные документы, графики, фотографии и кадры видео и отвечает на те же три типа вопросов, что и его предшественники.

• ID модели — drex-max, закреплён. Открытых весов нет; размещён через собственный API Nace, без загружаемого чекпоинта.

• Формат входных данных — это state строка плюс questions объект и images массив до 8 изображений на запрос. Конечная точка — POST /v1/systemone, тот же путь, который использует J​ev.

• Типы вопросов — choice (именованные варианты, возвращает вероятность для каждого варианта), noul (вопрос да/нет, возвращает P(true)), score (упорядоченные уровни, возвращает ожидаемый уровень и распределение). Несколько вопросов об одном состоянии используют один проход.

• Контекст — 131 072 токена на вопрос, включая токены изображений, согласно руководству по API. В посте о запуске отдельно указано «окно контекста на 262K токенов». Эти два числа не совпадают, и это первое, что нужно выяснить, прежде чем задавать размер буфера скриншотов.

• Цена — $0.06 за миллион входных токенов; за выходные данные плата не взимается. Nace приводит ту же цифру как $0.06 за тысячу решений, что подразумевает примерно тысячу токенов на один вызов.

• Предшественники — Drex 2.0 (всего 35B, около 3B активных, на базе Qwen3.6-35B-A3B, открытые веса) по $0,06 за тысячу решений и Drex 1.5 (9B, только текст) по $0,04.

• Развёртывание — под управлением на GPU Nace, выделенное, внутри аккаунта AWS или Azure заказчика либо в изолированной среде, и всё это с одним и тем же контрактом запросов. Отсутствие весов означает невозможность самостоятельного хостинга, но это не значит, что доступен только SaaS.

В интерфейсе нет ничего экзотического. Это сделано намеренно: Nace создавал Drex Max совместимым на уровне протокола с Jev SDK от TypeSafe, поэтому @typesafe-ai/sdk продолжает работать при изменённых базовом URL, ключе и модели по умолчанию. Совместимость — не любезность по отношению к конкуренту. Именно так и пробуют новичка — самая дешёвая миграция та, что сводится к значению в конфигурации.

По-настоящему отличается вот что: распределение вместо предложения.

Чат-модель отвечает на вопрос о работе с компьютером, буквально прописывая свой путь к ответу. «Судя по странице, результаты поиска, похоже, загрузились, поэтому следующим действием должен быть клик по второму результату» — а затем ваша обвязка парсит это предложение или JSON-блок и надеется, что модель не выбрала вариант, который вы никогда не предлагали. Цена такой конструкции платится дважды: один раз — в выходных токенах, а второй — в парсере, который приходится поддерживать, потому что модель может выдумать кнопку, которой нет на экране.

Drex Max не может этого сделать. Он возвращает вероятность по предложенным вами вариантам и ничего больше. Если вы предложите пять кликабельных кандидатов, вы получите пять чисел, сумма которых равна единице. Это более узкая возможность, и она гораздо лучше подходит для цикла — по трём причинам, которые важнее в продакшене, чем в демо.

Первый — это пороговая фильтрация. Распределение вероятностей позволяет записать именно то правило, которое вам нужно: действовать, когда лучший вариант превышает 0,9, и передавать управление более медленной модели или человеку, когда это не так. Генеративная модель выдаёт вам предложение и поле уверенности, которое означает совсем другое — обычно то, насколько острым было распределение токенов, а не то, насколько вероятно, что ответ правильный.

Второе — поведение при отказах. Агент, который может отвечать только объявленными вариантами, не может выдумать шестую кнопку. Он может ошибаться и может быть плохо откалиброван, но он не может породить действие, которое ваша обвязка не знает, как выполнить.

Третье — экономика. Поскольку выходных токенов нет, стоимость оценки десяти вариантов равна стоимости оценки двух. Nace формулирует это так: благодаря этому вызов достаточно дёшев, чтобы обращаться к нему на каждом шаге, и при $0,06 за тысячу вызовов арифметика сходится: даже небрежная задача из тридцати шагов обходится менее чем в две десятых цента на решениях. Та же задача на Opus 5.5, по расчёту Nace на одно решение, стоила бы около тридцати центов — не фатально, но в тридцать раз дороже того, что она делает.

Таблица бенчмарков и чьи это цифры

Каждый {{1}}показатель{{/1}} ниже взят из поста Nace о запуске. {{2}}Decision Index 0.3.2{{/2}} — это публичная таблица лидеров бенчмарков в стиле принятия решений, но {{3}}прогон Drex Max{{/3}} в ней выполнен самим Nace с использованием официального набора, и никто за пределами Nace его не воспроизвёл. Оценка «{{4}}Full{{/4}}» в таблице также смешивает закрытые тесты, которые не входят в этот прогон. Считайте {{5}}общую картину результатов{{/5}} информативной, а {{6}}десятичные знаки{{/6}} — маркетингом.

В заголовке — публичный Decision Index на уровне 67,6 против 61,3 у Drex 2.0, 58,1 у Drex 1.5, 60,7 у J​ev 1.14 и 47,8 у GPT-6 Luna Decisions. В сопутствующем Vision Index — показателе, который имеет значение для модели, чья главная фишка — зрение, — Drex Max набирает 74,5 против 63,9 у Luna.

• Mind2Web — 88,6 против 81,2 у GPT-6 Luna Decisions, наиболее直接 относящаяся к браузерным агентам строка.

• OSWorld-Verified — 0,780 против 0,756 у GPT-6 Sol и 0,790 у Claude Opus 5.5. Drex Max превосходит первого и совсем немного уступает второму.

• OSWorld-V2 — 0,737 против 0,744 у Sol и 0,761 у Opus 5.5. Та же картина, только разрыв чуть шире.

• BFCL tool calling — 98,2, впереди J​ev 1.14 с 96,4 и Claude Opus 5.5 с 97,3, уступает только GPT-6 Sol.

• DecideBench — 98,5 по пунктам и 97,0 по парам, оба показателя выше, чем у J​ev 1.14.

• Бизнес-решения против J​ev 1.14 — FinEntity 92,3 против 81,9, BANKING77 90,0 против 79,7, ContractNLI 75,9 против 57,7.

Строки OSWorld заслуживают оговорки, которую таблица Nace не проговаривает явно. Эти оценки описывают полный стек автоматизации, и не задокументировано, какая доля цикла вокруг Drex Max также приходилась на собственный harness Nace. Модель принятия решений, которая хорошо выбирает следующее действие, всё равно зависит от того, что делает скриншоты, ждёт рендеринга и решает, когда задача выполнена. Рассматривайте 0.780 как свидетельство того, что решения не являются узким местом, а не как обещание относительно вашего агента.

Там, где он проигрывает, — это более полезная половина таблицы.

Потери не скрыты, но их легко пропустить, и две из них описывают реальные ограничения, а не шум округления.

На общих знаниях и сложных рассуждениях решающие модели просто не конкурентоспособны с фронтирными чат-моделями, и Drex Max этого не меняет. MMLU-Pro — 72,5, позади J​ev 1.14 с 82,1, Sol с 93,0 и Opus 5.5 с 94,0. HLE — 19,0 против 19,4 у J​ev — так или иначе ничья у нижней границы диапазона. Это ожидаемо для модели, чья задача — выбирать из короткого списка по содержимому экрана, и именно поэтому решающая модель является компонентом агента, а не заменой модели, которая планирует.

Интереснее регресс относительно собственного предшественника. В When2Call, который проверяет, оправдан ли вообще вызов инструмента, Drex Max набирает 85,2, тогда как Drex 2.0 — 86,5, а более старая и дешёвая Drex 1.5 — 89,7. Самая новая и самая дорогая модель Drex хуже всех трёх понимает, когда не следует действовать. Если ваш рабочий процесс зависит от сдержанности — например, агент поддержки, который должен промолчать, а не вызывать инструмент возврата средств, — возможности распознавания изображений этого не дают, и более дешёвая текстовая модель может по-прежнему быть правильным выбором.

Та же закономерность проявляется в двух строках по зрению, которые показывают противоположную картину. KIE — извлечение ключевой информации из сканированных форм — 95,5 против 97,5 у Luna. Модерация Hateful Memes — 70,6 против 71,2. Ни тот, ни другой разрыв невелик, и оба относятся к областям, где преимущество Drex Max в других задачах достигает тридцати пунктов, что позволяет предположить: визуальный кодировщик обучен скорее на экранных макетах и графиках, чем на печатных формах или мемах.

Задержка тоже ухудшилась. Медианное значение 183 мс у Drex Max на 32 мс медленнее, чем у Drex 2.0, и на 38 мс медленнее, чем у Drex 1.5. В цикле, который выполняется тридцать раз на задачу, это добавляет около секунды на задачу — при этом на каждом шаге экономится несколько секунд по сравнению с передовой моделью. Всё ещё правильный компромисс, но стоит знать, что vision-энкодер не бесплатен.

Одно число нужно отделить, прежде чем его вам процитируют. 174 мс во вступительном абзаце — это измерение Nace только по скриншотам: 243 вопроса по изображениям, по одному запросу за раз, против 253 мс у J​ev 1.14 на том же наборе. 183 мс — это медиана по всему набору бенчмарков в таблице запуска. Оба значения принадлежат Nace; это разные измерения, и более лестное из них — более узкое.

Две ловушки в API, о которых стоит знать до подключения

В документации есть деталь, которая обойдётся кому-то в полдня, если читать по диагонали. drex-latest не указывает на Drex Max. Это закреплённый чекпойнт, а псевдоним ведёт к чему-то другому. Любой, кто пройдёт быстрый старт, подставит свой ключ и установит TYPESAFE_DEFAULT_MODEL=drex-latest — именно это советуют инструкции по совместимости с J​ev — будет обращаться к текстовой модели и недоумевать, почему его скриншоты игнорируются.

Вторая ловушка — размер. Руководство API ограничивает запросы восемью изображениями и 131 072 токенами на вопрос, включая токены изображений; в анонсе запуска заявлено 262K. Пока Nace не согласует эти два значения, ориентируйтесь на меньшее. Опубликованной стоимости в токенах за изображение нет, поэтому заранее трудно понять, как соотноситься с этим лимитом: скриншот в полном разрешении не имеет фиксированного числа токенов, а в документации не сказано, как изображения изменяются в размере или разбиваются на тайлы.

Одно преимущество перед конкурентом: Drex Max принимает скриншоты любых размеров. API J​ev 1.14 отклоняет изображения со стороной менее 280 px или более 1 568 px — а такие ограничения всплывают как молчаливый сбой в цикле повторных попыток в два часа ночи.

Как это влияет на решение о маршрутизации

Практический вопрос не в том, лучше ли Drex Max, чем передовая модель. Она не лучше и не пытается ею быть. Вопрос в том, какие из тридцати решений в задаче заслуживают передовой модели, а какие — вероятностного распределения за 174 мс, и это проблема маршрутизации прежде, чем проблема модели.

Drex Max отсутствует в нашем списке маршрутов. В каталоге OrcaRouter его нет, и ничто здесь не должно восприниматься как наше заявление о доступности — Nace продаёт его через собственный API и собственную консоль. А что у нас действительно есть — так это текущее решение, с которым его сравнивают. TypeSafe Jev 1.13 — это указанный маршрут по цене $0.042 за миллион входных токенов при контексте 65,536 токенов, обслуживаемый через то жеPOST /v1/systemone тело запроса, так что A/B между моделью принятия решений и вашим текущим циклом «скриншот → frontier» — это замена строки модели, а не переписывание. Самый дешёвый способ решить этот вопрос — оставить ваши текстовые вызовы для принятия решений там, где они есть, добавить рядом с ними этап чтения экрана для задач, которым нужны глаза, и оценивать оба варианта по вашим собственным логам, а не по 140,178 оценённым запросам Nace.

Такое разделение работает только в том случае, если все части доступны из одного места. Один ключ для более чем 200 моделей, списочная цена провайдера, передаваемая без наценки за токен, и автоматическое переключение между провайдерами при сбое — именно это не даёт эксперименту превратиться в устаревшую ветку после того, как человек, который его настроил, перейдёт в другую команду. Здесь это важно ещё и по конкретной причине: Drex Max — новый, непроверенный и доступный только через API продукт, а безопасный способ внедрить неопробованный компонент — поставить его за чем-то, что может переключиться на известную модель, когда уверенность падает или конечная точка ведёт себя неправильно. Направляйте уверенные решения на дешёвую модель, а остальное пусть обрабатывает механизм переключения при сбое.

Что могло бы изменить это чтение?

Независимый прогон Decision Index — это первое, на что стоит смотреть. Набор тестов публичный, Нейс говорит, что оценки воспроизводимы, и пока кто-то вне компании не прогонит Drex Max на нём, 67,6 — это цифра поставщика. Ячейки, за которыми стоит следить, когда это произойдёт, — те, что указывают в противоположные стороны: преимущество в 30 пунктов на Mind2Web рядом с регрессией на When2Call — это не плавная кривая возможностей; это describes модель, усиленно обученную на вопросе «какой из этих элементов — следующий клик» и меньше — на вопросе «стоит ли мне вообще на что-то кликать». Если это подтвердится, это самый важный с операционной точки зрения факт о Drex Max, и его нет в ключевых моментах.

Задержка в продакшене при конкурентной нагрузке — это второй вопрос. Собственный показатель пропускной способности Nace — около 25 запросов в секунду на одной реплике H100, без ошибок при до 64 одновременно выполняющихся запросах — относится к Drex в целом, а не конкретно к Max. Весь смысл этой архитектуры в том, что она находится на горячем пути на каждом шаге, поэтому p95 под нагрузкой гораздо важнее медианы в 183 мс, и ничего из опубликованного это не рассматривает.

В-третьих, в ценообразовании нужен разобранный пример с изображениями. Цена $0.06 за миллион входных токенов полезна, только если вы знаете, сколько токенов стоит скриншот, а ни одна опубликованная цифра этого не делает. Команда, планирующая бюджет для 30-шагового цикла с экраном 1440p на каждом шаге, гадает, пока Nace не опубликует учёт изображений или кто-то не измерит это.

Ничто из этого не делает релиз менее интересным. Модель принятия решений, которая видит, — это действительно другой компонент, чем чат-модель, которую просят взглянуть на скриншот, а ценовой разрыв достаточно велик, чтобы изменить то, что агент может позволить себе делать на каждом шаге. Просто это пока не число, которое кто-либо за пределами Nace проверил, — и та часть таблицы, которая уцелеет при контакте с реальным развёртыванием, вероятно, будет той частью, которую никто не цитирует.