Что такое stealth/union-alpha на OpenRouter и почему её тестируют до релиза
16 сентября 2026 года на OpenRouter появилась анонимная модель stealth/union-alpha. Это стелс-релиз: лаборатория выложила модель под техническим именем, без названия вендора и без официального анонса. Смысл понятен: собрать реальную нагрузку и реакцию разработчиков до того, как модель выйдет под настоящим именем. На момент публикации цена стояла нулевая, а в карточке заявлены мультимодальность, поддержка tool calling и результат GPQA Diamond 90.9%.
Оговорка по данным: всё перечисленное это заявления платформы на момент публикации, а не цифры, подтверждённые независимой проверкой. Нулевая цена у стелс-моделей обычно живёт дни или недели, потом меняется. Поэтому модель имеет смысл оценивать не по карточке, а по работе на конкретной задаче. Так и было сделано: не бенчмарк, а доработка ветки обработки комментариев для живого ИИ-агента в n8n, который отвечает пользователям в Direct.
Короткий итог теста: за один заход модель выдала семь файлов, включая сборщик воркфлоу, 16 тестов и самоанализ на 38 КБ. Артефакт рабочий, но не готовый к проду. Ручной аудит нашёл три класса ошибок, а самые серьёзные сбои при живых прогонах оказались человеческими, а не модельными.
Заявленные характеристики: мультимодальность, tool calling, GPQA Diamond 90.9% и нулевая цена
Что заявлено в карточке stealth/union-alpha:
- мультимодальность;
- поддержка tool calling;
- GPQA Diamond 90.9%;
- нулевая цена на момент публикации.
GPQA Diamond это набор вопросов уровня выпускника профильной специальности: физика, химия, биология. Высокий процент там означает, что модель уверенно держит сложные предметные рассуждения. Про сборку многофайлового артефакта с конкретными зависимостями бенчмарк не говорит ничего. Заявленные 90.9% означают, что модель стоит внимания, и не означают, что она заменит ревью.
Независимого подтверждения мультимодальности, tool calling и метрики в этом тесте не было. Цена на момент публикации тоже не гарантия: у стелс-моделей она меняется первой.
Почему бенчмарки не заменяют реальную задачу
Бенчмарк измеряет ответ на вопрос с известным правильным вариантом. Продакшен требует другого: собрать связный набор файлов, не перепутать константы, не сломать существующую ветку, пройти живой прогон с реальными ключами доступа. Это разные навыки, и второй слабо коррелирует с первым.
Для интегратора сигнал от реальной задачи плотнее. Сразу видно, держит ли модель структуру проекта, пишет ли тесты, оставляет ли осмысленный самоанализ и где именно ошибается. Логика оценки новинок по чек-листу, а не по числу в карточке, разобрана в материале про оценку новых AI-моделей без шума вокруг релизов. В случае union-alpha разрыв между заявленными 90.9% и тремя ошибками в коде виден построчно.
Задача для теста: доработка ветки обработки комментариев для ИИ-агента в n8n
Живой проект: ИИ-агент в n8n, который отвечает пользователям в Direct. Задача для модели - доработка ветки обработки комментариев. Не синтетический пример, а рабочая ветка с реальными зависимостями: credential для доступа к аккаунту, allowlist источников, фолбэк-модель на случай отказа основной.
Почему выбрана изолированная ветка, а не весь агент
Ветка обработки комментариев имеет понятные границы: вход (комментарий), выход (ответ или пропуск), набор правил между ними. Такой контур даёт чистый сигнал о возможностях модели без шума от остальных частей агента. Если модель валит изолированную ветку, обсуждать весь агент рано.
Здесь же проверялся контекст. Заявленные 262K токенов оценивались ровно на этой ветке, и достаточность подтверждена только для неё. На весь агент, на другие ветки и на длинные диалоги с историей сообщений вывод не распространяется.
Критерии оценки: что считалось успехом, а что провалом
Успех: связный многофайловый артефакт за один заход, тесты в комплекте, корректные константы, прохождение живого прогона. Провал: обрыв структуры, отсутствие тестов, неверная конфигурация, падение на реальных данных.
Отдельно зафиксирую границу между «генерация прошла» и «готово к продакшену». Даже аккуратный по структуре код от LLM требует аудита: проверки констант, allowlist, обработки ответа. Модель пишет черновик быстрее человека, а ответственность за прод остаётся на человеке.
Что модель сгенерировала за один заход: семь файлов, 16 тестов и самоанализ на 38 КБ
За один заход модель выдала семь файлов. Это полноценный набор для целой ветки: сборщик воркфлоу, тесты, самоанализ и вспомогательные модули.
Состав артефакта: сборщик воркфлоу, тесты и самоанализ
- Сборщик воркфлоу. Код, который воспроизводит структуру ветки в n8n. Полезен тем, что воркфлоу становится версионируемым: его можно пересобрать из исходников, а не править руками в редакторе.
- 16 тестов. Покрытие логики ветки: разбор комментария, фильтрация по allowlist, формирование ответа, очистка текста.
- Самоанализ на 38 КБ. Разбор моделью собственных решений: что сделано, какие допущения приняты, где остались места, требующие проверки.
Самоанализ на 38 КБ это самый неочевидный элемент набора. На ревью он экономит время: модель сама перечисляет развилки, и ревьюер быстрее понимает, куда смотреть. Заменой ручной проверки он не становится. Документ описывает замысел, а не соответствие реальному конфигу проекта: неверные константы модель в самоанализе не поймает, потому что сама их и придумала.
Хватило ли контекста 262K токенов
Живые прогоны показали: 262K токенов хватает для изолированной ветки обработки комментариев. В контекст поместились описания нод, структура существующего воркфлоу, правила обработки и история правок.
Ограничение простое: подтверждено только для этой ветки. Распространять вывод на весь агент с несколькими ветками, памятью диалогов и поиском по базе нельзя. Каждый такой контур надо мерить отдельно, потому что длинный контекст в карточке не равен способности модели удерживать в нём всё одинаково хорошо.
Аудит сгенерированного кода: три класса ошибок, которые нашлись вручную
Аудит сгенерированного кода дал три класса ошибок. Все нашлись руками: автоматические тесты, которые модель написала сама, их не поймали.
Промпт-копия вместо отдельного сценария
Модель скопировала промпт в новый блок вместо того, чтобы вынести логику в отдельный сценарий. На первый взгляд работает так же. На практике это ловушка поддержки: два одинаковых промпта начинают жить своей жизнью, и при правке одного второй остаётся со старыми правилами. Рассинхрон проявляется не сразу, а через недели, когда поведение агента внезапно расходится на двух похожих сценариях.
Как ловить на ревью: искать повторы текстовых блоков промптов и проверять, что общая логика вынесена в одно место, а не растиражирована по файлам.
Неверные константы ID аккаунта и allowlist
В коде оказались неверные константы: ID аккаунта и allowlist. Ошибка типичная для генерации: модель подставляет правдоподобные значения вместо реальных, потому что реальных у неё нет. В продакшене это даёт два сценария: ответы уходят не тому адресату или фильтр пропускает источники, которые должен блокировать.
Практика: ID и allowlist держать в конфиге, сверять с источником истины и закрывать тестом на соответствие. Если константа меняется в коде, а не в конфиге, тест покажет это до продакшена, а не после жалобы.
Пропущенный тег в очистке ответа
В функции очистки ответа пропущен тег. Служебная разметка, которую модель добавляет во внутренний вывод, при таком пропуске попадает в финальный текст, который видит пользователь. Косметика? До первого скриншота от клиента с торчащим тегом посреди ответа.
Как ловить: тест на очистку с реальными примерами ответов, включая случаи, где разметка стоит в начале, середине и в конце строки, а также вложенные конструкции.
Живые прогоны: где на самом деле ломается продакшен
Живые прогоны дали главный вывод теста: продакшен ломался не там, где ожидалось. Обе серьёзные проблемы оказались конфигурационными.
Неверный credential: как конфигурация ломает агента
Credential оказался неверным, из-за чего агент не мог выполнить свою часть работы. Модель здесь ни при чём: сгенерированный код был на месте, доступ не работал.
Практика: проверять credential на старте, добавлять smoke-тест на доступ к аккаунту, логировать ошибки авторизации отдельно от ошибок генерации. Тогда падение авторизации не выглядит как «модель сломалась». Тема прав доступа, логов и изоляции подробно разобрана в материале про базовую гигиену AI-агентов вместо внешних аудитов.
Неподключённая фолбэк-модель: тихий отказ, который виден только в проде
Фолбэк-модель не была подключена. При отказе основной модели у агента не оставалось резерва, и вместо ответа пользователь получал тишину. Такой отказ не воспроизводится в тестах, где основная модель отвечает стабильно.
Практика: проверять наличие фолбэка в конфиге, отдельно тестировать сценарий отказа основной модели, логировать каждое переключение. Надёжность агентных моделей упирается в оркестрацию вокруг них, и это разобрано в статье про надёжность GLM-5.3-Flash и границы возможностей агентных моделей.
Чек-лист аудита и тестирования AI-агентов в продакшене
Чек-лист собран из разобранного кейса. Порядок важен: сначала конфигурация, потом код, потом живые прогоны.
Что проверять в сгенерированном коде
- Дублирование промптов. Искать повторы блоков, требовать выноса общей логики в один сценарий.
- Константы. ID аккаунта, allowlist, лимиты: сверить с источником истины и добавить тест на соответствие.
- Очистка ответа. Тест с реальными примерами, включая служебные теги в начале, середине и конце строки.
- Полезность тестов. Проверить, что 16 тестов проверяют логику, а не повторяют реализацию. Тесты, которые проверяют сами себя, бесполезны.
Что проверять в конфигурации и на живых прогонах
- Credential. Валидность и права доступа, smoke-тест на старте.
- Фолбэк-модель. Наличие в конфиге и работоспособность, тест на отказ основной модели.
- Логи. Переключения между моделями, ошибки авторизации отдельно от ошибок генерации.
- Контекст. Достаточность для конкретной ветки, замер на живых данных, а не на догадке.
| Слой | Что проверять | Что ловит |
|---|---|---|
| Конфигурация | Credential, фолбэк-модель, логирование | Тихие отказы в проде |
| Код | Промпты, константы, allowlist, очистка | Рассинхрон логики и утечку служебной разметки |
| Живые прогоны | Достаточность контекста, поведение на реальных данных | Проблемы, которые не видит синтетический тест |
Стоит ли использовать stealth/union-alpha: выводы и ограничения
Модель способна за один заход выдать крупный многофайловый артефакт для реальной задачи. Это факт из теста. Готовым продакшен-решением артефакт не становится: ручной аудит обязателен, и он нашёл три класса ошибок.
Кому подойдёт, а кому нет
Подойдёт разработчикам и интеграторам, которые готовы ревьюить сгенерированный код, тестировать на изолированных ветках и держать конфигурацию под контролем.
Не подойдёт тем, кто ждёт готовый код без проверки, и тем, кто строит критичную систему без фолбэка и логов. Здесь риск создаёт не модель, а отсутствие контура проверки.
Риски стелс-моделей на OpenRouter
- Автор и происхождение модели неизвестны: за техническим именем может стоять любая лаборатория.
- Цена и доступность меняются: нулевая цена на момент публикации не обязательство на будущее.
- Долгосрочных гарантий нет: модель может исчезнуть из каталога после релиза под настоящим именем.
- Воспроизводимость ограничена: результат одного захода не доказывает стабильность на других задачах.
Что с этим делать: держать стелс-модель вариантом для экспериментов и изолированных задач, а в критичном продакшене оставлять проверенную модель с фолбэком. Логика выбора основной модели на длинную дистанцию разобрана в статье про то, почему расклад открытых LLM в 2026 году выглядит именно так.
И последнее по границам теста. Результаты одного захода и одного живого прогона это не бенчмарк. Достаточность 262K токенов подтверждена только для ветки обработки комментариев, заявленные метрики независимо не проверялись, нулевая цена может измениться в любой день. Этого достаточно, чтобы попробовать модель на своей задаче. Недостаточно, чтобы делать её единственной точкой отказа в продакшене.