Браузер вместо API: как я объединил DeepSeek, Qwen и ChatGPT в одного локального агента

Значимый прорыв формирует отрасль ИИ: ITstaks 9 минут назад Браузер вместо API: как я объединил DeepSeek, Qwen и ChatGPT в одного локального агента Средний 9 мин 446 Искусственный интеллект Open source * Node. JS * Кейс Из песочницы Под капотом AI Free: три разных способа работы с веб-провайдерами, единый агентный рантайм, память, skills и много кода восстановления после сбоев. У веб-версий больших языковых моделей есть странное свойство: для человека они доступны в один клик, а для программы между «отправить вопрос» и «получить ответ» внезапно вырастает целая инфраструктура.

Одному сервису нужен proof-of-work. Другой подписывает каждый запрос кодом из своего фронтенда. Третий формирует служебные токены глубоко внутри React-приложения.

Технические детали

Сессии истекают, вкладки закрываются, контекст страницы исчезает при навигации, а интерфейс может измениться без предупреждения. При этом мне хотелось получить не ещё один агрегатор чатов, а локальный инструмент разработчика: чтобы модель могла читать файлы проекта, предлагать и вносить изменения, запускать разрешённые команды, работать в браузере и помнить результаты прошлых задач. Так появился AI Free — open-source приложение, в котором веб-сессия становится транспортом для модели, а поверх неё работает общий агентный рантайм.

Проект я разрабатываю один: от интеграций с провайдерами и агентного рантайма до desktop-интерфейса, расширения VS Code, тестов и релизов. Поэтому здесь особенно важны простые границы между модулями — без них соло-разработка такого количества интеграций быстро стала бы неуправляемой. Интерфейс AI FreeВ этой статье я разберу не интерфейс приложения, а главные инженерные решения проекта: почему для трёх провайдеров понадобились три разных транспорта, где проходит граница между провайдером и агентом и почему восстановление после ошибок оказалось важнее самого первого успешного запроса.

Проект использует пользовательские сессии веб-сервисов и зависит от их текущих интерфейсов. Это не официальный API и не обещание вечной совместимости. Пользователь сам отвечает за соблюдение правил выбранного сервиса, а для коммерческих и критичных сценариев разумнее использовать официальные API.

Почему нельзя сделать один универсальный клиентВ начале кажется, что задача сводится к обычному HTTP:авторизоваться;отправить текст;прочитать поток ответа;сохранить идентификатор диалога. Но браузерные приложения давно не являются тонкими оболочками над публичным endpoint. Часть протокола живёт в JavaScript и WASM, часть привязана к cookies и состоянию вкладки, а часть вообще запускается только штатным обработчиком интерфейса.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.