The post has been translated automatically. Original language: Russian
On September 11, 2026, a preliminary release of DSPy 3.4.0b1 was released, a beta of a popular framework in which working with language models is described not by the text of the product, but by module signatures and optimizers. The authors call this release transitional: it transfers the execution of requests to a single engine interface, adds local launch of the generated code and asynchronous agent mode. There is no stable version 3.4.0 yet, but the list of incompatible changes has already been fixed.
Own engine layer instead of a single adapter
Previously, DSPy gave all model calls to an external library, the router. Now the framework has its own request and response types, and the engine selection mode is set to "auto" by default: where possible, the request goes through the native implementation, and for unsupported routes, a compatible path remains through the old library. At the same time, the interface for its backends is open — it is enough to implement one method that accepts the request object and returns the response object. This significantly simplifies the connection of the company's internal gateway or its own proxy to the models.
Cache compatibility is preserved: previously recorded responses remain readable, while new ones are stored as regular serialized data. There are also reservations that the notes are honest about. Native calls requesting multiple response options are performed in sequential requests, rather than a single request with a quantity parameter on the provider's side, which means both the delay and the cost are higher. Replays are now controlled by the framework itself, while the stream, from which at least one fragment has already left, is not re-requested.
Local interpreter and refinement: It's not a sandbox.
LocalInterpreter has appeared — execution of the generated Python in a separate subprocess on the current interpreter, while maintaining the state and imports within the session. Previously, such a scenario required third-party runtime. It works with both the RLM module and the Flex module.
An important detail that was highlighted separately in the notes: this is not a security mechanism. The code runs with the same access to the file system and host credentials as the main process. The isolation here is process-based, not protective.
Agent, optimizer, and obvious errors instead of silence
The experimental ReActV2 agent has learned how to work asynchronously: asynchronous invocation and asynchronous tools are available. The situation was fixed when a failure at the final output step left an incomplete prediction result, and the call history of external tools became structured.
The GEPA optimizer accepts its own code suggestion generator via a separate parameter — domain hints can be set without rewriting the built-in behavior. The examples where the program crashed no longer disappear from the sample: they are assigned a preset failure score. An empty evaluation set now causes an obvious error instead of a silent failure, and synchronous streaming pushes source errors outward.
What does this mean in practice?
It makes sense to upgrade to beta on a separate branch and definitely not in production. The first thing to check is whether there are any experimental types of requests, responses, and messages from branch 3.3 left in the code: they were deleted in 3.4, and imports from the old type module crashed with a migration error. Separately, look at direct calls to models with OpenAI—style messages and native implementations of the model's base class methods. They are marked as obsolete and will be removed in 3.5. The lower limit of Pydantic will also rise, no lower than 2.11.0, and this often entails a reassembly of the dependencies of the entire service.
Of the practical rakes, I would expect two. The first is an increase in the bill and response time where you requested several options from the model in one call: on the native path, these are now several consecutive requests. "The second" is the output fields named "history" and "termination_reason" in the agent: they are no longer accepted, and the old scheme simply will not start.
The draft text was prepared with the participation of AI, the facts were checked against the original source — official notes for the release of DSPy 3.4.0b1 on GitHub
Одиннадцатого сентября 2026 года вышел предварительный выпуск DSPy 3.4.0b1 — беты популярного фреймворка, в котором работа с языковыми моделями описывается не текстом промпта, а сигнатурами модулей и оптимизаторами. Авторы называют этот выпуск переходным: он переносит исполнение запросов на единый интерфейс движков, добавляет локальный запуск сгенерированного кода и асинхронный режим агента. Стабильной версии 3.4.0 пока нет, но список несовместимых изменений уже зафиксирован.
Свой слой движков вместо единственного адаптера
Раньше все вызовы моделей DSPy отдавал внешней библиотеке-маршрутизатору. Теперь у фреймворка появились собственные типы запроса и ответа, а режим выбора движка по умолчанию выставлен в значение «auto»: где возможно, запрос идёт через нативную реализацию, а для неподдержанных маршрутов остаётся совместимый путь через прежнюю библиотеку. Заодно открыт интерфейс для своих бэкендов — достаточно реализовать один метод, принимающий объект запроса и возвращающий объект ответа. Это заметно упрощает подключение внутреннего шлюза компании или собственного прокси к моделям.
Совместимость с кешем сохранена: ранее записанные ответы остаются читаемыми, а новые кладутся в виде обычных сериализованных данных. Есть и оговорки, о которых в заметках сказано честно. Нативные вызовы с запросом нескольких вариантов ответа выполняются последовательными запросами, а не одним запросом с параметром количества на стороне провайдера — значит, и задержка, и стоимость выше. Повторами теперь управляет сам фреймворк, при этом поток, из которого уже ушёл хотя бы один фрагмент, повторно не запрашивается.
Локальный интерпретатор и уточнение: это не песочница
Появился LocalInterpreter — исполнение сгенерированного Python в отдельном подпроцессе на текущем интерпретаторе, с сохранением состояния и импортов в пределах сессии. Раньше для такого сценария требовался сторонний рантайм. Работает как с модулем RLM, так и с гибким модулем Flex.
Важная деталь, которую в заметках выделили отдельно: это не механизм безопасности. Код выполняется с тем же доступом к файловой системе и учётным данным хоста, что и основной процесс. Изоляция здесь процессная, а не защитная.
Агент, оптимизатор и явные ошибки вместо тишины
Экспериментальный агент ReActV2 научился работать асинхронно: доступен асинхронный вызов и асинхронные инструменты. Устранена ситуация, когда сбой на шаге финальной выдачи оставлял неполный результат предсказания, а история вызовов внешних инструментов стала структурированной.
Оптимизатор GEPA принимает собственный генератор предложений по коду через отдельный параметр — доменные подсказки можно задавать, не переписывая встроенное поведение. Примеры, на которых программа упала, больше не исчезают из выборки: им проставляется заданная оценка неудачи. Пустой набор для оценки теперь вызывает явную ошибку вместо тихого сбоя, а синхронная потоковая выдача пробрасывает ошибки источника наружу.
Что это значит на практике
Обновляться на бету имеет смысл на отдельной ветке и точно не на продакшене. Первое, что стоит проверить, — не осталось ли в коде экспериментальных типов запросов, ответов и сообщений из ветки 3.3: в 3.4 они удалены, а импорты из старого модуля типов падают с ошибкой миграции. Отдельно посмотрите прямые вызовы моделей сообщениями в стиле OpenAI и собственные реализации методов базового класса модели — они помечены как устаревшие и будут убраны в 3.5. Поднимется и нижняя граница Pydantic, не ниже 2.11.0, а это часто тянет за собой пересборку зависимостей всего сервиса.
Из практических граблей я бы ждал двух. Первое — рост счёта и времени ответа там, где вы запрашивали у модели несколько вариантов за один вызов: на нативном пути это теперь несколько последовательных запросов. Второе — поля вывода с именами «history» и «termination_reason» в агенте: они больше не принимаются, и старая схема просто не заведётся.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальные заметки к выпуску DSPy 3.4.0b1 на GitHub