GUI harness запускается двойным кликом по одному exe-файлу. Ни установки, ни Docker, ни браузера: приложение на Go несёт внутри llama.cpp, whisper.cpp, omnivoice.cpp и интерпретатор кода, а весь интерфейс собирает из векторных примитивов, которые генерирует LLM. CPU-сборка без CUDA весит около 40 МБ и занимает 70-100 МБ оперативной памяти до старта модели.
Пользователь говорит или печатает, модель пишет код, код исполняется и рисует векторные компоненты, похожие на SVG. Агент при этом не видит экран: он правит код и базу знаний. Отдельный слой системы - встроенное хранилище, которое записывает каждое изменение и позволяет откатить и свои ошибки, и неудачные шаги агента.
Проект исследовательский. Автор не публиковал ни бенчмарков, ни результатов прогонов моделей, а часть работы называет незавершённой. Ниже - что уже работает, какие есть ограничения и кому такой подход может пригодиться.
Что такое GUI harness и почему это необычный подход к локальным LLM
GUI harness - автономное приложение целиком в одном исполняемом файле. Автор описывает его в видео-анонсе на r/LocalLLaMA как альтернативу привычному стеку вокруг LLM, где чат живёт в браузере, модели поднимаются отдельными серверами, а зависимости ставятся вручную. Здесь наоборот: скачал файл, запустил, работаешь.
Ключевые компоненты внутри одного бинарника
В один bin-файл скомпилированы интерпретатор кода, llama.cpp, whisper.cpp, omnivoice.cpp и другие части. Роли распределены так:
- llama.cpp - инференс языковой модели;
- whisper.cpp - распознавание речи;
- omnivoice.cpp - голосовая часть взаимодействия;
- интерпретатор кода - исполняет то, что генерирует модель, включая код интерфейса;
- собственные текстовый и layout-движки - отвечают за разметку и отрисовку, написаны с нуля.
Практический смысл такой упаковки - отсутствие внешних зависимостей. Не нужно поднимать сервер модели, ставить Python-окружение, возиться с Docker или открывать браузер. Файл можно держать на флешке и запускать на другой машине. Разница в ресурсах заметна сразу: 40 МБ против типичной связки «облачный клиент плюс локальный рантайм модели».
Чем GUI harness отличается от привычных интерфейсов для LLM
Веб-оболочки, десктопные приложения на Electron и командные строки объединяет одно: набор элементов интерфейса задан разработчиком заранее. GUI harness не использует веб-браузер, у него собственные текстовый и layout-движки, а графика выводится как векторные компоненты, похожие на SVG. Формулировка автора - «basically fancy SVG».
Из этого следует неочевидный вывод: каждый пиксель на экране появляется из кода, сгенерированного моделью. Интерфейс не зафиксирован в сборке, его описывает LLM в момент работы. Такой подход означает, что кнопки, панели и списки не встроены в приложение, а собираются на лету из ограниченного набора геометрических функций.
Как запустить GUI harness и какие требования к железу
Сценарий запуска укладывается в два действия: скачать exe-файл и кликнуть по нему дважды. Установка, Docker, браузер и настройка окружения не требуются.
Варианты сборки: CPU и CUDA
Автор упоминает CPU-версию, в которую CUDA не вкомпилирована: около 40 МБ на диске, 70-100 МБ оперативной памяти до момента запуска LLM. Отдельная сборка с CUDA прямо не названа, но сама формулировка «CPU (no CUDA compiled in)» подсказывает, что вариант с GPU-ускорением существует. Его характеристики в описании не раскрыты, поэтому цифр по VRAM и скорости для него я не привожу.
Основной расход ресурсов начинается с моделью. Сколько займёт конкретная LLM, зависит от числа параметров, типа квантования и длины контекста. Как оценивать VRAM, влияние формата nvfp4 и стоимости прогона на своём GPU, разобрано в материале про практическое сравнение GLM-5.3-Flash и DeepSeek-V4-Flash-0731 с методикой проверки на собственном железе.
Использование OpenRouter для доступа к SOTA-моделям
Опционально система может брать модели из OpenRouter, чтобы проверять SOTA-варианты. Режим полезен в двух случаях: когда локальной конфигурации не хватает под нужный размер модели и когда хочется сопоставить поведение открытой модели с закрытой на одинаковых задачах.
Это внешний канал, и он меняет профиль проекта: данные уходят с локальной машины, а результат зависит от чужой инфраструктуры. Что учитывать при выборе между локальным запуском и облачным API, включая контекстное окно, KV-cache и стоимость инференса, разобрано в статье о сравнении локальных и облачных моделей в 2026 году.
Векторный интерфейс: как LLM генерирует GUI из простых фигур
Механика выглядит так: пользователь обращается голосом или текстом, LLM генерирует код, код исполняется и выдаёт векторные компоненты. Рисует не человек и не дизайнер в редакторе, а модель в реальном времени.
Семь векторных примитивов и их роль
Код может использовать только семь простых векторных функций, у каждой есть несколько параметров:
Rectangle- прямоугольник;Circle- круг;Line- линия;Image- изображение;Text- текст;List- список;Div- контейнер, часть макета.
Набора хватает на всё: Button, Slider, Color picker, Calendar и остальные элементы собраны из этих примитивов. Кнопка в такой модели - прямоугольник с текстом поверх. Дополнительный уровень структуры даёт Div: источник прямо называет его частью макета, а внутри Div бывает сетка.
Как создать собственный GUI-компонент
Интерфейс полностью hackable: пользователи могут создавать новые GUI-компоненты, которых до этого никто не видел. Причина в том, что интерфейс здесь - это код. Новый элемент достаточно описать через те же семь функций и их параметры, отдельная библиотека виджетов не нужна.
У подхода есть цена. Стабильность картинки зависит от того, насколько хорошо модель удерживает контекст: если макет рождается из генерируемого кода, то при слабой работе с контекстом интерфейс будет вести себя непредсказуемо. Автор называет работу с контекстом главным направлением для улучшений, и это прямо связано с качеством генеративного GUI.
Откат любых действий: как работает встроенное хранилище
Хранилище написано с нуля и не опирается на файлы и папки операционной системы. Оно записывает каждое изменение в системе. Отсюда две возможности: откатить собственные ошибки и откатить ошибки LLM.
Почему откат действий агента - критичная функция
Агент правит код и базу знаний, не видя экран. Одно неудачное изменение расходится по зависимым частям проекта, и заметить это глазами нельзя. Без отката от ошибки агента пришлось бы избавляться вручную.
Здесь действие обходится так, как будто его никогда не было. Сценарий срабатывает в двух случаях: пользователь кликнул и пожалел об этом, либо агент вышел из-под контроля. Для агентных систем это не удобство, а страховка: правки вносятся автоматически, и цена одной ошибки выше, чем при ручном редактировании.
Гибкость хранения истории: час, день, неделя
Держать полную историю не обязательно. Можно оставить только последний час, день или неделю. Это ограничивает объём накопленных изменений и упрощает навигацию по ним.
Деталей реализации автор не раскрывает: как именно переключается глубина истории, где хранятся данные и как чистится старое, в описании нет. Известно только, что история живёт внутри приложения, а не в виде отдельных файлов на диске.
Какие модели тестирует автор и почему важен reasoning
Список текущих прогонов: gemma-31b@fp8, Qwen-27b@fp8 и DeepSeek-V4-flash@fp8. Все три запускаются в 8-битном формате, то есть на весах, которые заметно тяжелее привычных 4-битных квантов.
Опубликованных результатов нет: неизвестно, какая из трёх моделей лучше справляется с генерацией интерфейса, сколько шагов агента требуется на задачу и где ломается контекст. Автор надеется, что скоро получится перейти к моделям менее 20B. Пока это надежда, а не подтверждённый факт.
Почему reasoning открытых моделей помогает в отладке
Открытые модели показывают цепочку рассуждений. Для проекта такого типа это практический инструмент: видно, как модель пришла к решению, и где именно в контексте возникла ошибка.
A big advantage of open-weight models is they show reasoning, which helped me in so many cases expose "bugs" in context.
В переводе: крупное преимущество открытых моделей в том, что они показывают рассуждения, и это много раз помогало находить «баги» в контексте. Такой лог полезен, когда агент генерирует код интерфейса и не сходится с ожиданиями.
Прозрачность reasoning не гарантирует стабильности. Известны случаи, когда модель после вызова инструмента выдаёт блок рассуждений, будто исходной задачи не было; симптомы, гипотезы и план диагностики разобраны в статье про сбои reasoning-блоков в Qwen Flash Next после tool call.
Контекст-инжиниринг: главное направление для улучшений
Готовность контекст-инжиниринга автор оценивает примерно на 50% и говорит, что улучшений нужно много. Сама формулировка показывает, где проходит граница между работающим прототипом и инструментом на каждый день.
Самая заметная проблема UX названа прямо: ожидание, пока агент закончит работу. Её автор и решает через улучшение работы с контекстом, а не через ускорение интерфейса. Как оценивать модели и новые релизы без шума вокруг них, включая качество рассуждений, контекст, скорость и требования к VRAM, собрано в чек-листе по оценке новых AI-моделей.
Нестандартный UX: brush, минимализм и голосовое управление
Макеты в GUI harness минималистичны. Показательный пример: в навигации слева нет кнопок Delete или Rename. Функции второго уровня выполняются иначе - пользователь указывает на часть экрана и говорит, что с ней сделать.
Как работает brush и зачем он нужен
Brush - невербальная часть коммуникации. Нужно удерживать клавишу CTRL и «рисовать» мышью или тачпадом. Инструмент позволяет выбрать Div, то есть часть макета, либо сетку внутри Div.
Смысл в том, что для правки конкретного элемента не нужно объяснять словами, где он находится. Достаточно указать на область и сказать, что с ней делать. Такой канал дополняет голос и текст, а не заменяет их.
Почему минимализм - это осознанный выбор
Автор объясняет минимализм соображениями UX: меньше визуального шума и меньше элементов, за которые нужно отвечать. Компенсация - указание на экран плюс разговор.
Цена решения в другом: привычных кнопок нет, поэтому интерфейс требует привыкания, а часть действий выполняется медленнее, чем в классической панели инструментов. Голос и текст остаются основными каналами ввода, а агент работает вслепую, редактируя код и базу знаний.
Кому и зачем нужен GUI harness: сценарии использования
Для разработчиков и исследователей AI-агентов
Проект интересен прежде всего тем, кто следит за локальными AI-системами и агентными интерфейсами. Три понятных сценария:
- Эксперименты с генеративным интерфейсом, где GUI не зашит в сборку, а выводится моделью.
- Проверка локальных моделей на агентных задачах, где важнее всего удержание контекста и способность писать рабочий код.
- Изучение отката как механизма безопасности агента, который правит файлы и базу знаний без человеческого контроля.
Отдельный интерес - сравнение подходов. Опция OpenRouter позволяет прогнать те же сценарии на SOTA-модели и увидеть, где именно локальный запуск упирается в ограничения.
Ограничения и перспективы проекта
Ограничения стоит назвать прямо. Это исследовательский прототип, а не продукт для ежедневной работы: контекст-инжиниринг готов примерно наполовину, ожидание агента названо главной UX-проблемой, результаты тестов моделей не опубликованы, а переход к моделям менее 20B пока остаётся планом.
Модели уровня 27-31B в fp8 требуют серьёзного железа, конкретные требования зависят от квантования и длины контекста. Стоит также помнить, что все описанные функции и цифры взяты из рассказа автора, независимой проверки не было.
Дальше логичный шаг - посмотреть видео-анонс и оценить, насколько подход с генеративным GUI и полным откатом действий подходит под ваш стек. Если вы уже запускаете локальные модели и строите агентов, GUI harness даёт редкий пример системы, где интерфейс, модель и история изменений собраны в одном файле.