The post has been translated automatically. Original language: Russian
On September 15, 2026, version 1.6.0 of the official Anthropic SDK for Python was released, the second notable build in a week after 1.5.0 on September 10. Both versions are interesting not so much for the new fields in the API schemas, but for the changes in the behavior of the client himself: the logic of repeated attempts has changed, a beta mechanism for compacting correspondence has appeared, and the rules for working with credential files have been clarified. For those who run a service in production that runs on the HTTP model, this is exactly the part of the release that is worth reading before updating the dependency.
Compacting correspondence in beta
In 1.6.0, the compactification parameter and signed compactification blocks have been added — they are still in beta status. The idea is that a long message history can be collapsed, and the result of the convolution can be passed on as a separate block of content. In the same release, a separate change corrected the descriptions of the parameters of this beta in the documentation — a sign that the interface is still being clarified, and it's too early to tie production code to it.
The second beta is next: the thinking_mismatch_allowed entries have been added to the input data transformations. Plus, an unpleasant detail of the scheme has been fixed — the message event and the delta event now use the same type of input conversion, rather than two different ones. If you parse streaming events manually, rather than using ready-made SDK helpers, this unification simplifies parsing.
Retries: Retry-After and asynchronous client
The most practical part of the release is the four fixes to the delay logic. The client now takes into account the values of the Retry-After header for more than 60 seconds, rather than ignoring them; incorrect header values are discarded, and at the same time the transmitted MaxRetries is checked; if the value exceeds the acceptable range, the usual exponential delay is used.
The asynchronous client has been repaired separately: it repeats the request again in case of connection errors and is no longer blocked inside the coroutine during the replay cycle. Blocking waiting in asynchronous code is the classic reason that a service stops serving neighboring requests under load, although according to logs it "just waits for the model's response."
The client also learned how to work with asynchronous credential token providers, and version 1.5.0 introduced separate types of exceptions for credential and token file errors and added access rights verification: a credential file accessible to a group or other users is now rejected.
What does this mean in practice?
The update looks safe, but a couple of places require attention. The first is dependencies: the release raises the requirement for anyio to version 4.1 or later, so that in projects with the old anyio fixed, installation will require a reassembly of the environment. The second is timeouts. If the client previously ignored long Retry-After values, your own timeout layer might not notice this; now the request can honestly wait longer than a minute, and it's better to check the overall processing time budget in advance, especially if the model is called inside a web request.
The third is file rights. Checking access to the credentials file breaks scenarios where the secret lies in a shared directory or is mounted in a container with extended rights: before rolling out, you should make sure that only the owner reads the file. And finally, of the two betas — compactification and entry transformations — it is now reasonable to take only the first and only the flag: their schemes were corrected in the same release.
The draft text was prepared with the participation of AI, the facts were checked against the original source — the official release notes for version 1.6.0 of the SDK Anthropic for Python.
15 сентября 2026 года вышла версия 1.6.0 официального SDK Anthropic для Python — вторая заметная сборка за неделю после 1.5.0 от 10 сентября. Обе версии интересны не столько новыми полями в схемах API, сколько изменениями в поведении самого клиента: поменялась логика повторных попыток, появился бета-механизм компактации переписки и уточнились правила работы с файлами учётных данных. Для тех, кто держит в продакшене сервис, ходящий в модель по HTTP, это как раз та часть релиза, которую стоит прочитать до обновления зависимости.
Компактация переписки в бете
В 1.6.0 добавлен параметр компактации и подписанные блоки компактации — пока в статусе беты. Идея в том, чтобы длинную историю сообщений можно было свернуть, а результат свёртки передавать дальше в виде отдельного блока контента. В том же релизе отдельным изменением поправлены описания параметров этой беты в документации — признак того, что интерфейс ещё уточняется, и завязывать на него продакшен-код рано.
Рядом идёт вторая бета: в преобразования входных данных добавлены записи thinking_mismatch_allowed. Плюс к этому исправлена неприятная мелочь схемы — событие сообщения и событие дельты теперь используют один и тот же тип преобразования входа, а не два разных. Если вы разбираете потоковые события вручную, а не через готовые хелперы SDK, эта унификация упрощает разбор.
Повторные попытки: Retry-After и асинхронный клиент
Самая практичная часть релиза — четыре исправления в логике ретраев. Клиент теперь учитывает значения заголовка Retry-After больше 60 секунд, а не игнорирует их; некорректные значения заголовка отбрасываются, и заодно проверяется переданный maxRetries; если значение выходит за допустимый диапазон, используется обычная экспоненциальная задержка.
Отдельно починен асинхронный клиент: он снова повторяет запрос при ошибках соединения и больше не блокируется внутри корутины во время цикла повторов. Блокирующее ожидание в асинхронном коде — классическая причина того, что сервис под нагрузкой перестаёт обслуживать соседние запросы, хотя по логам «просто ждёт ответа модели».
Ещё клиент научился работать с асинхронными провайдерами токенов учётных данных, а в версии 1.5.0 появились отдельные типы исключений для ошибок учётных данных и файла с токеном и добавлена проверка прав доступа: файл учётных данных, доступный группе или прочим пользователям, теперь отклоняется.
Что это значит на практике
Обновление выглядит безопасным, но пара мест требует внимания. Первое — зависимости: релиз поднимает требование к anyio до версии 4.1 или новее, так что в проектах с зафиксированным старым anyio установка потребует пересборки окружения. Второе — таймауты. Если раньше клиент игнорировал длинные значения Retry-After, ваш собственный слой таймаутов мог этого не замечать; теперь запрос может честно подождать дольше минуты, и общий бюджет времени обработки лучше проверить заранее, особенно если вызов модели идёт внутри веб-запроса.
Третье — права на файлы. Проверка доступа к файлу учётных данных ломает сценарии, где секрет лежит в общем каталоге или монтируется в контейнер с расширенными правами: до выката стоит убедиться, что файл читает только владелец. И, наконец, из двух бет — компактации и преобразований входа — в бой сейчас разумно брать разве что первую и только за флагом: их схемы в этом же релизе правились.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальные заметки о выпуске версии 1.6.0 SDK Anthropic для Python.
Share
