OpenCode с LM Studio работает через локальный сервер, совместимый с OpenAI: в opencode.json описывают провайдера с адресом http://127.0.0.1:1234/v1, перечисляют загруженные модели и выбирают нужную командой /models. Код при такой схеме остаётся на компьютере разработчика, а качество правок определяют размер модели и память машины. Вариант годится, когда репозиторий запрещено отправлять в облако и команда готова читать каждый diff глазами.
Связка на компьютере
LM Studio отдаёт загруженную модель по адресу локального сервера, а OpenCode подключается к нему как к обычному провайдеру через пакет @ai-sdk/openai-compatible.
Работа делится так: LM Studio держит веса в памяти и отвечает на запросы по протоколу, знакомому клиентам OpenAI. OpenCode живёт в терминале, читает файлы проекта, предлагает правки и запускает команды по вашему разрешению. Между ними проходит только текст запросов и ответов, причём внутри одного компьютера. Интернет нужен на этапе скачивания модели, а запросы к самой модели остаются на компьютере.
Здесь разбирается именно локальная модель как поставщик для OpenCode. Подключение инструментов и серверов MCP к этому агенту описано в статье про OpenCode MCP и ограничение инструментов, а сам сервер LM Studio, его сетевые режимы и авторизация подробно разобраны в материале про локальный endpoint LM Studio. Здесь остаётся стык между ними: что вписать в конфиг, какую модель взять и как убедиться, что правка пригодна.
Ожидания от такой связки задайте заранее. Локальная модель средней величины уверенно переименует функцию, допишет тест по образцу или объяснит чужой модуль, но длинные рефакторинги через десяток файлов получаются у неё заметно слабее облачных систем. Поэтому первый рабочий сценарий берут короткий: одна функция, один файл, понятный критерий готовности.
Конфиг провайдера
По документации OpenCode, LM Studio подключается блоком provider в файле opencode.json. Внутри задают ключ провайдера (в примере документации это lmstudio), пакет @ai-sdk/openai-compatible, отображаемое имя, адрес в options.baseURL и список моделей. Для порта по умолчанию адрес выглядит как http://127.0.0.1:1234/v1. Если вы поменяли порт на вкладке сервера в LM Studio, тот же номер вписывают и сюда.
- Загрузите в LM Studio модель под код и запустите локальный сервер на вкладке разработчика. Запомните идентификатор модели, который показывает программа.
- В корне проекта или в пользовательской папке настроек OpenCode создайте
opencode.json. Добавьте блокproviderс ключомlmstudio, пакетом@ai-sdk/openai-compatibleи адресом вoptions.baseURL. - В раздел
modelsвпишите идентификатор из LM Studio как ключ и понятное имя как значениеname. Идентификатор должен совпасть символ в символ с тем, что отдаёт сервер. - Запустите
opencodeв папке репозитория и командой/modelsвыберите добавленную модель. Задайте безобидный вопрос про структуру проекта и сверьте ответ с реальными файлами.
Файл с адресом локального сервера обычно свободен от секретов, поэтому его можно положить в репозиторий и обсудить в ревью, если вся команда сидит на одинаковой схеме. Но порт и имя модели у коллег могут отличаться, и тогда конфиг удобнее держать на уровне пользователя, оставляя в проекте только правила для агента. Сверьте и версию OpenCode: структура настроек со временем меняется, а источником истины остаётся страница документации.
Модель и память
Выбор модели упирается в оперативную память или видеопамять. Сами веса занимают место, а к ним добавляется контекст: чем больше файлов агент держит в разговоре, тем тяжелее его обработать. Для OpenCode контекст важнее, чем для чата, потому что агент подмешивает в запрос содержимое файлов и результаты команд. Если окно контекста в LM Studio задано слишком малым, длинный разговор оборвётся посреди работы, и причину в самом OpenCode искать бесполезно.
| Параметр | Где задаётся | Что проверить |
|---|---|---|
| Идентификатор модели | LM Studio и ключ в блоке models | Совпадение написания, иначе OpenCode получит отказ |
| Размер контекста | Настройки загрузки модели в LM Studio | Хватает ли окна на файл плюс разговор |
| Умение вызывать инструменты | Карточка выбранной модели | Модель корректно отвечает на запросы чтения и правки файлов |
| Адрес и порт | options.baseURL в конфиге | Совпадение с вкладкой сервера и закрытость от сети |
Отдельный вопрос — способна ли конкретная модель работать с инструментами. OpenCode просит у модели вызвать чтение файла или запуск команды, и слабая в этом отношении модель вместо вызова пишет рассуждение или ломает формат. Проверяется это за пять минут на безобидной задаче вроде «покажи структуру каталога и назови точку входа». Если модель запутывается уже здесь, переходите к другой модели вместо добавления в конфиг новых параметров. Сравнить способы локального запуска поможет материал про выбор между Ollama и LM Studio.
Какой репозиторий вы готовы показать локальной модели первым?
Границы данных
Локальный сервер снимает вопрос об отправке кода стороннему облаку, но остальные границы остаются. Агент видит всё, до чего дотягивается в рабочей папке: файлы окружения, выгрузки клиентов, ключи в старых коммитах. Локальность модели даёт тут мало защиты, потому что файл с секретом попадёт в запрос к вашему же серверу и осядет в истории разговора на диске. Поэтому ключи и персональные данные держат за пределами каталога, куда запускают агента.
- Запускайте OpenCode в копии репозитория или в отдельной ветке, где нет файлов с настоящими секретами.
- Оставляйте режим, при котором агент спрашивает разрешение на каждую команду и каждую запись в файл, пока вся команда ещё присматривается к инструменту.
- Держите сервер LM Studio на адресе 127.0.0.1; открывайте его в сеть офиса только после настройки авторизации из отдельной статьи.
- Проверьте, куда OpenCode и LM Studio пишут историю разговоров, и включите эту папку в правила хранения компании.
Если машина общая или к ней подключаются по удалённому доступу, адрес 127.0.0.1 перестаёт быть гарантией: любой, кто сидит на той же машине, может обратиться к серверу. Для серверов, которые обслуживают нескольких разработчиков сразу, нужна уже настоящая инфраструктура, и тогда уместна консультация по внедрению ИИ в разработку с разбором ролей и журналирования.
Проверка diff
Принцип остаётся тем же, что и с любым кодовым агентом: модель предлагает, сервис и тесты проверяют, человек принимает. Локальная модель ошибается чаще облачной, поэтому дисциплина здесь строже. Любая правка проходит три шага: чтение diff целиком, прогон тестов и линтера отдельной командой, а затем осмысленный коммит от имени разработчика, который отвечает за изменение.
На диффе ищите три типичных дефекта. Первый: модель переписала больше, чем просили, и задела соседние функции. Второй: исчезли проверки ошибок или условия, которые выглядели лишними. Третий: появились вызовы несуществующих функций или библиотек, ведь локальные модели нередко придумывают имена методов. Зелёный тест гарантирует мало, поэтому сборку и запуск приложения проверяют так же, как после правки коллеги.
Для первой недели заведите журнал: задача, модель, число правок руками после агента, причина отказа от результата. Через десяток задач станет видно, на каких работах локальная схема окупается, а какие лучше делать вручную или другим инструментом. Тогда решение о расширении получает опору в вашей практике вместо чужих отзывов.
Возьмите тестовый репозиторий без секретов и одну небольшую функцию с понятным тестом. Подключите LM Studio по схеме выше, попросите агента дописать недостающий тест, затем прочитайте diff и запустите набор. Если результат устраивает, переходите к реальному проекту, а при вопросах по организации работы обсудите ИИ-агента для разработки с нами.