Пока большинство спорит, какой облачный AI-инструмент лучше, автор под ником v1st на Habr провёл шестимесячный эксперимент в другую сторону: взял Opencode, мигрировал его на Emacs Lisp и получил терминального агента, который работает полностью локально. Видеокарта на 12 Гб, модель с 8 млрд параметров, контекст 32К — и никакой зависимости от внешних API.
Зачем вообще отказываться от облака
Вопрос, который лежит в основе эксперимента, сформулирован жёстко: можно ли на локальной машине с GPU 12 Гб получить от компактной LLM (8B параметров) пользу, сопоставимую с моделями на 100B–1T параметров из облака? Не «похожую», а реально сопоставимую для задач разработки ПО.
Для проверки гипотезы нужен был агент с тремя свойствами: не привязан к конкретной модели, полностью открытый исходный код, достаточно гибкий для быстрых экспериментов. Claude Code и аналоги отпали сразу — закрытые. Opencode подошёл.
Почему Opencode переписали на Emacs Lisp
Оригинальный Opencode написан преимущественно на Go. Вместо того чтобы форкать его и работать с чужой архитектурой, автор решил мигрировать кодовую базу на Emacs Lisp. Логика здесь не ностальгическая, а прагматичная — три причины в одном инструменте.
Emacs — это одновременно терминал с портами под разные платформы (включая Android через Termux), среда исполнения, где LLM может вызывать встроенные функции Emacs Lisp напрямую без обращения к shell, и экосистема с живыми репозиториями пакетов Elpa/Melpa. Для агента, которому нужен гибкий tool calling, это удобнее, чем городить обёртки поверх Go.
Сама миграция была выполнена с помощью того же Opencode: репозиторий склонировали локально, запустили экземпляр с моделью minimax m2.5 (на тот момент доступной бесплатно), попросили агента проанализировать собственную кодовую базу и предложить план переноса на Emacs Lisp. Агент задал уточняющие вопросы, предложил план — и выполнил его. MVP появился в конце апреля — начале мая 2026 года.
Как агент хранит память и борется с галлюцинациями
Одна из первых проблем, которая вскрылась в ходе работы: агенту нужна собственная память — не просто история сессий, а структурированное хранилище артефактов разработки. Без этого каждая новая задача начинается с нуля.
В качестве хранилища выбрали OWL/RDF triplestore с SPARQL-эндпоинтом на базе Apache Jena Fuseki с расширениями Lucene/HNSW. Это не самый очевидный выбор, но у него есть конкретное преимущество: поддержка федеративных SPARQL-запросов. Проще говоря, если несколько агентов складывают решения в свои хранилища и часть из них публикуется, любой агент в сети может запросить эти решения стандартным запросом. Задел на мультиагентную архитектуру.
Галлюцинации — вызовы несуществующих функций — решаются на шаге верификации кода. Когда LLM генерирует функцию, прототип обращается в хранилище за списком реально существующих функций, семантически похожих на вызываемые. Этот список передаётся в контекст повторного запроса, и модель переписывает код с опорой на то, что действительно есть. Не идеально, но работает без дополнительных параметров или файн-тюнинга.
Как выглядит типовая сессия
За полгода — почти 500 итераций и 2000 закрытых задач — сложился устойчивый рабочий сценарий. Вот как выглядит одна сессия в хронологии из статьи:
| Время (UTC) | Событие |
|---|---|
| 13:16:50 | Запуск прототипа, проверка состояния хранилища (тёплый старт или новая задача) |
| 13:16:59 | Пользователь формулирует задачу в чате |
| 13:17:25 | Агент классифицирует задачу, формирует структуру артефактов в хранилище, сохраняет формулировку |
Структура артефактов задачи описана как шаблон OWL/RDF/TTL-онтологии — её можно запросить через SPARQL прямо из хранилища. Это означает, что агент не держит контекст задачи только в памяти сессии: он материализует его в граф, к которому можно вернуться после перерыва.
Что это значит для разработчика, который хочет попробовать
Эксперимент показывает: локальный суверенный агент — не теоретическая конструкция. При правильно выбранном стеке 8B-модель на потребительском GPU справляется с реальными задачами разработки. Правда, порог входа здесь выше, чем подключить Cursor или GitHub Copilot.
Нужно понимать Emacs Lisp хотя бы на базовом уровне, разобраться с Docker-окружением, поднять Apache Jena Fuseki и настроить SPARQL-эндпоинт. Это несколько часов работы, а не пятиминутная установка расширения в VS Code.
Зато результат — агент, который не отправляет ваш код в облако, не зависит от доступности API конкретного провайдера и накапливает знания о вашем проекте в структурированном локальном хранилище. Для задач, где конфиденциальность кода критична, или для работы в изолированных сетях — это реальная альтернатива, а не компромисс.
В ходе эксперимента также тестировались модели из семейств minimax, deepseek, mimo, glm, nemotron — агент изначально проектировался как не привязанный к конкретной модели, и это свойство оказалось полезным: можно переключаться между моделями без переработки логики агента.