Simon Willison выпустил LLM 0.37 — обновление CLI-инструмента и Python-библиотеки для работы с языковыми моделями. Новый дефолтный вариант, gpt-6-luna, стоит вдвое меньше предыдущего gpt-5.6-luna, а также в релиз добавили модели gpt-6.1-sol, gpt-6.1-terra и команду для подключения OpenAI-совместимых endpoint.

Релиз вышел 2 ноября 2026 года и собирает примерно два месяца новых функций и исправлений. Для тех, кто не выбирал модель вручную, главное изменение уже произошло: LLM будет использовать другой дефолт.

LLM 0.37 меняет модель по умолчанию — и снижает цену вдвое

LLM — это проект Simon Willison: консольный инструмент и Python-библиотека для использования LLM-моделей. Версия 0.37 не выглядит как один большой новый режим работы, но заметно расширяет практические сценарии: автор добавил модели, улучшил подключение сторонних совместимых сервисов и доработал эмбеддинги для мультимодальных данных.

Самое прикладное изменение — смена модели по умолчанию. Если пользователь не настроил собственный default model, LLM 0.37 выберет gpt-6-luna вместо gpt-5.6-luna. По словам Willison, новая дефолтная модель стоит в два раза дешевле предыдущей.

Это не означает, что каждый запрос автоматически станет «в два раза выгоднее» в конкретной инфраструктуре: в заметке нет тарифов, валюты, расчёта стоимости токенов или сравнительных бенчмарков. Но для пользователя, который полагался на настройки LLM по умолчанию, смена важна именно как готовый выбор автора инструмента.

Было в LLM по умолчаниюСтало в LLM 0.37Что известно из релиза
`gpt-5.6-luna``gpt-6-luna`Новая модель стоит вдвое меньше предыдущей
Пользовательский default modelПользовательский default modelНастройка пользователя сохраняет приоритет
Базовый набор моделейДобавлены `gpt-6.1-sol` и `gpt-6.1-terra`Новые модели доступны в релизе

Willison также добавил gpt-6.1-sol и gpt-6.1-terra. В исходной заметке не объясняется, чем они отличаются друг от друга, от gpt-6-luna и от прежних вариантов по качеству, цене, скорости или контекстному окну. Поэтому выбирать их как замену дефолту только по названию было бы преждевременно.

Для разработчика это выглядит как аккуратная оптимизация поведения «из коробки». Если LLM встроен в скрипты, локальные эксперименты или повседневную работу в терминале, более дешёвый дефолт способен снизить стоимость без переписывания команд — но только для тех, кто не закрепил собственную модель в конфигурации.

Команда llm openai endpoint add убирает часть ручной настройки

В LLM 0.37 появилась команда llm openai endpoint add. Она нужна, чтобы проще настраивать дополнительные модели, работающие через OpenAI-совместимые endpoint. Endpoint — это сетевой адрес API, к которому программа отправляет запросы к модели.

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

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

Именно поэтому LLM 0.37 стоит воспринимать не как обещание полной взаимозаменяемости любых API, а как появление более удобной точки настройки для дополнительной модели. Совместимость endpoint обычно зависит от того, насколько конкретный сервис повторяет ожидаемый формат запросов и ответов.

ВозможностьЧто добавлено в LLM 0.37Чего релиз не уточняет
Подключение моделейКоманда `llm openai endpoint add`Полный синтаксис команды
Тип интеграцииOpenAI-совместимые endpointСписок сервисов и провайдеров
Работа с модельюНастройка дополнительных моделейОсобенности авторизации и параметров
МиграцияБолее простой способ конфигурацииНужны ли изменения в старых настройках

Похоже, это обновление рассчитано на пользователей, для которых LLM уже стал универсальной оболочкой над несколькими моделями. Им не обязательно менять привычный интерфейс CLI при появлении нового совместимого endpoint: достаточно, что инструмент умеет добавить его как ещё одну доступную модель.

Эмбеддинги теперь подходят не только для текста и одинаковых файлов

LLM 0.37 обновляет поддержку эмбеддингов: инструмент теперь принимает ситуацию, в которой разные бинарные данные имеют разные content-type. Content type — это тип содержимого файла или данных, например текст, изображение, аудио или видео.

Willison прямо связывает это изменение с Gemini Embedding 2. Эта модель, как указано в заметке, умеет создавать эмбеддинги для текста, аудио, изображений и видео. Эмбеддинг — это числовое представление содержимого, которое используют, например, для семантического поиска и поиска похожих материалов.

Раньше в LLM не хватало возможности корректно учитывать, что один набор данных может состоять из бинарных файлов разных типов. Обновление закрывает именно этот инфраструктурный пробел: инструмент должен передавать информацию о типе содержимого так, чтобы мультимодальная модель понимала, что перед ней — не один и тот же формат данных.

Для практики это важно тем, кто строит поиск не только по текстовым документам. Например, в одном индексе могут соседствовать заметки, изображения, аудиозаписи и видео. LLM 0.37 не обещает готовую поисковую систему для такого набора, но делает поддержку моделей с мультимодальными эмбеддингами более реалистичной на уровне входных данных.

Тип данныхУпомянут в связи с Gemini Embedding 2Зачем нужен content type
ТекстДаЧтобы модель получила текст как текст
ИзображенияДаЧтобы отличать изображения от других бинарных данных
АудиоДаЧтобы корректно передавать аудиоконтент
ВидеоДаЧтобы корректно передавать видеоконтент

При этом в релизе нет данных о качестве поиска, ограничениях по размеру файлов, стоимости эмбеддингов, поддерживаемых кодеках или формате хранения векторов. LLM 0.37 добавляет необходимую совместимость с разными типами контента, но не заменяет проектирование всей мультимодальной RAG-системы.

Двенадцать авторов исправлений — и пример того, как AI-PR не обязательно ломают open source

В релиз LLM 0.37 вошли исправления от 12 авторов. Willison пишет, что почти все эти вкладки были сделаны с помощью ИИ, но для его проекта поток AI-assisted pull request не стал проблемой, хотя многие open source-мейнтейнеры жалуются на такие PR.

Автор объясняет свой подход тем, что использует Opus 5.5 или GPT-6 Astra для первичной проверки и поиска наиболее полезных исправлений. Это не означает, что модели принимают изменения сами: Willison описывает их как помощников для триажа — предварительной сортировки и оценки входящих предложений.

Его формулировка хорошо описывает рабочее отношение к таким PR: он воспринимает их как баг-репорты с приложенными примерами. Иногда он принимает предложенный патч, а иногда использует его как основу и реализует собственное исправление.

Для мейнтейнера здесь интересен не «рецепт безболезненного AI-кодинга», а конкретная схема: ИИ помогает не заменить проверку, а снизить нагрузку на этапе сортировки. Для LLM это сработало в рамках данного релиза, но автор не утверждает, что подход одинаково подойдёт любому проекту.

LLM 0.37 — полезное обновление прежде всего для уже использующих инструмент разработчиков. Оно меняет дефолт на более дешёвую модель, упрощает добавление OpenAI-совместимых endpoint и расширяет работу с мультимодальными эмбеддингами. А вот публиковать выводы о качестве новых моделей, реальной экономии и широте совместимости пока рано: этих данных в анонсе нет.

Источники