Депрекация модели: сколько дней дают и куда переезжать

Что значит «модель депрекирована» и когда она перестанет отвечать?#

У Anthropic четыре состояния модели, и депрекация модели - третье из них; разница между третьим и четвёртым стоит денег. Active - модель рекомендована. Legacy - обновлений больше не будет, депрекация впереди. Deprecated - работает, но вендор уже назначил дату выключения и рекомендовал замену. Retired - всё.

Перевод: модель больше недоступна, запросы к выключенным моделям завершаются ошибкой.

Слово fail тут ключевое. Вызов возвращает ошибку: модель не подменяется соседней и не начинает отвечать хуже. Для кода это хорошая новость: молчаливая деградация отлаживается неделями, а честная ошибка видна сразу. Плохая новость в том, что увидите вы её в проде, если не посмотрели в реестр заранее.

Сроки здесь принадлежат площадке. Дни на переезд отсчитываются от объявления до отключения, и сколько их будет - решает та площадка, через которую вы к модели ходите, а вовсе не её разработчик.

Сколько дней на самом деле дают?#

Формулировка Anthropic звучит щедро, пока не посмотреть, что она обещает на самом деле:

Перевод: Anthropic уведомляет клиентов с активными развёртываниями о предстоящем выключении моделей не менее чем за 60 дней до выключения, для публично выпущенных моделей.

Здесь три сужения в одном предложении. Адресат сужен до клиентов с активными развёртываниями, и определения «активного» на странице нет. Предмет сужен до публично выпущенных моделей - preview-версии под обещание не попадают. И «не менее шестидесяти дней» - это пол, а не срок жизни: обещание касается предупреждения, а доступность им не покрыта.

Фактические интервалы по реестру Anthropic на 4 августа 2026. Колонка дат в самом реестре названа «Tentative retirement date» - то есть дата предварительная и может сдвинуться:

Заявленный порог и есть практика. Шестьдесят дней в первой строке - это ровно минимум, и разница между «политика соблюдена» и «нарушена» умещается в один день конвенции счёта.

У OpenAI сроки написаны словами, и они длиннее: шесть месяцев для общедоступных моделей, три месяца для специализированных вариантов вроде *-chat-latest и *-codex, около двух недель для preview. Оговорка там та же, что у Azure: сроки не действуют, если возникли вопросы безопасности или соответствия. Записи в её журнале выглядят так: «On June 11, 2026, we notified developers... of their deprecation and removal from the API on December 11, 2026» - «11 июня 2026 года мы уведомили разработчиков... об устаревании этих моделей и удалении их из API 11 декабря 2026 года». Сто восемьдесят три дня.

У Google реестр самый подробный, а срока в нём нет: на странице депрекаций не названо ни одного числа дней, недель или месяцев - проверено поиском по всему тексту страницы. Колонки там четыре: модель, дата выпуска, дата выключения и рекомендованная замена. И двадцать две записи стоят с пометкой No shutdown date announced. Часть из них - живые модели, у которых дата просто ещё не назначена; но по строке реестра отличить «время есть» от «время кончается» нельзя.

Складывать эти числа в рейтинг «кто предупреждает лучше» нельзя, и это не осторожность ради осторожности. У Anthropic и Google дата берётся из поля статуса в реестре, у OpenAI - из датированной записи об уведомлении. Первое - момент, когда поменялась строка на странице; второе - факт уведомления. У Google из подсчёта выпадают все двадцать две записи без даты выключения, то есть ровно те, где интервал ещё растёт. Окна наблюдения разные. Корректное сравнение строится иначе: брать надо одну и ту же модель у разных площадок.

У этих же дат есть обратная сторона. У активных моделей Anthropic публикует дату «не раньше чем»: claude-opus-5 - не раньше 24 июля 2027, claude-sonnet-4-5-20250929 - не раньше 29 сентября 2026. Выглядит как гарантия срока жизни.

Возьмите вторую дату и посчитайте: от 4 августа 2026 до неё пятьдесят шесть дней. При пороге уведомления в шестьдесят дней выключить модель 29 сентября можно было бы только при объявлении до 31 июля, а его не было. Опубликованная нижняя граница как реальная дата отключения уже недостижима.

Почему у одной модели разные даты смерти?#

Здесь сравниваются одна модель, один идентификатор и разные площадки. Числа сняты 4 августа 2026 с двух первоисточников - реестра Anthropic и таблицы жизненного цикла Bedrock. Оговорка по последней строке: Claude 3.7 Sonnet присутствует в таблице Bedrock только для регионов us-gov-east-1 и us-gov-west-1, коммерческих регионов у неё там нет, и её дата уже прошла. Опирайтесь на первую строку.

Причина в политике самой площадки:

Перевод: модель находится в состоянии Legacy не менее шести месяцев до даты окончания жизненного цикла.

Шесть месяцев против шестидесяти дней за то же самое имя модели.

У Azure свой цикл и свои правила. Уведомление о выводе общедоступной модели - не менее шестидесяти дней, preview-модели - не менее тридцати. Стандартный срок жизни версии - восемнадцать месяцев с запуска, но у общедоступных моделей Anthropic, DeepSeek, Fireworks и Mistral он двенадцать, и это записано отдельной сноской. Microsoft отдельно оставляет за собой право на аварийный вывод с сокращённым уведомлением, если у модели нашли проблему с соответствием или безопасностью.

И одна деталь Azure, которая ломает интуицию: статус «существующий клиент» определяется на уровне подписки, и новая подписка в том же тенанте доступ не наследует. Развернули модель в проде год назад, завели отдельную подписку под стенд - и на стенде та же модель уже недоступна.

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

Как за пять минут проверить, касается ли это вас?#

Начните с вопроса «через кого идёт трафик»: депрекация модели видна у каждой площадки по-своему.

1. Anthropic напрямую. Откройте страницу Usage в консоли, нажмите Export, посмотрите CSV с разбивкой по ключу и модели. Реестр депрекаций сверьте руками - в схеме /v1/models слова deprecated нет ни одного вхождения, статус оттуда получить нельзя.
2. AWS Bedrock. Вызов ListFoundationModels возвращает поле modelLifecycle со значением ACTIVE или LEGACY. Это опрашивается из скрипта.
3. Azure AI Foundry. Models API отдаёт lifecycleStatus в реальном времени.
4. Через посредника-роутера. Реестра жизненного цикла у таких площадок обычно нет: модель просто исчезает из списка. Значит, работает только последний способ.

Универсальная проверка, которая не зависит от площадки, выглядит так: раз в сутки запрашивайте список доступных моделей и сравнивайте с идентификаторами, зашитыми в вашем проде. Пропал из списка - валите сборку.

# Идентификаторы, на которых реально работает ваш прод
grep -rhoE 'claude-[a-z0-9-]+|gpt-[0-9][a-z0-9.-]*' src/ | sort -u > /tmp/used.txt

# Список того, что площадка отдаёт сегодня
curl -s -H "x-api-key: $API_KEY" -H "anthropic-version: 2023-06-01" \
  https://api.anthropic.com/v1/models | python3 -c "
import json,sys
print('\n'.join(m['id'] for m in json.load(sys.stdin)['data']))" | sort > /tmp/available.txt

# Чего из используемого больше нет - это и есть ваш список на миграцию
comm -23 /tmp/used.txt /tmp/available.txt

Ловушка Azure, на которой легко успокоиться. Названия в документации и значения в API сдвинуты на шаг. То, что в документации называется Deprecated (модель работает, но новых клиентов не пускают), в API приходит как lifecycleStatus: Deprecating. А значение Deprecated в API означает уже выключенную модель - её вызовы отдают 410 Gone. Проверка на == "Deprecated" поэтому означает «уже поздно», хотя выглядит как «пора мигрировать». Ловить надо Deprecating.

Выгрузка использования при этом даёт нижнюю оценку зависимости. Она показывает, что вызывалось за период наблюдения. Записанное в коде она не видит. Редкая ветка, квартальный отчётный запуск и резервный путь, который ни разу не сработал, в неё не попадут. Поэтому первый способ - грепом по репозиторию, а выгрузка вторым.

Что именно ломается, когда модель выключают?#

Семь поломок, которые встречаются чаще прочих:

• 404 или 410 вместо деградации. Код постоянной ошибки. Логика «повторить через секунду» его пропускает и правильно делает: повторять нечего.
• Фолбэк не срабатывает. Резервная модель обычно подключается в обработчике временных отказов. Постоянная ошибка мимо него проходит.
• Агент виснет навсегда. Цикл «вызвал, получил ошибку, повторил» без разбора кода не завершается. Задача не падает, она просто не заканчивается.
• Алиас указывает на выключенный снимок. Имя в коде живое, модель за ним - нет.
• Рекомендованная замена не эквивалентна. Другая длина контекста, другое поведение на тех же параметрах, другая цена за токен.
• Смена поведения на замене. Замена может не принимать параметры, к которым вы привыкли: Anthropic начиная с Opus 4.7 отдаёт на нестандартные значения temperature, top_p и top_k ошибку 400 вместо тихого игнорирования. Ошибка честнее молчания, но код всё равно придётся править.
• Депрекация бьёт раньше выключения. Запрет на новые развёртывания приходит до даты отключения: прод работает, а стенд на той же модели поднять уже не даёт.

Последняя поломка обходится дороже прочих, и на неё есть публичный разбор. В треде поддержки Microsoft разработчик 29 июня 2026 получил ошибку ServiceModelDeprecating на gpt-4o и gpt-4.1-mini, при том что опубликованные даты вывода стояли на 1 и 14 октября 2026 года. Три месяца форы, обещанные реестром, не сработали: новые развёртывания запретили заранее. Рекомендованные документацией замены на тот момент сами стояли депрекированными, а доступная в его регионе альтернатива, по его словам, поднимала стоимость в двадцать раз.

Почему алиас с «latest» не спасает?#

У алиасов ровно два режима, и оба неудобны. Плавающий алиас меняет модель под вами: код тот же, промпты те же, ответы другие. Отладка такого занимает дни, потому что первое, что проверяют, - свой код.

Закреплённый алиас ведёт себя честнее, но защиты не даёт: он указывает на конкретный снимок и выключается вместе с ним.

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

Что делать прямо сейчас: план на пять шагов#

1. Соберите фактический список моделей. Греп по репозиторию плюс выгрузка использования. Два источника, потому что каждый по отдельности неполон.
2. Определите площадку для каждого вызова. Прямой API, облачный посредник, роутер. Дальше смотрите реестр именно этой площадки.
3. Выпишите даты и посчитайте запас в днях. Не в месяцах: «в сентябре» - это ощущение, «через пятьдесят шесть дней» - это план.
4. Проверьте замену на своих задачах до переключения. Рекомендованная вендором замена подобрана по классу модели; ваш сценарий в подборе не участвовал.
5. Удалите старое развёртывание последним. Только после того, как замена отработала на реальном трафике.

Пятый шаг стоит отдельного предупреждения, и здесь документация расходится с практикой. По странице Azure существующий клиент в статусе Deprecated развёртывания создавать может: колонка «Can create new deployments?» отвечает «Existing customers: Yes», а сам статус существующего клиента определён как «подписка когда-либо разворачивала эту версию» - то есть право переживает удаление. В треде поддержки, на который я ссылался выше, повторное развёртывание у такого клиента всё равно отклонили. Модератор Microsoft там же советует не удалять работающие развёртывания, пока замена не проверена. Планируйте по практике: удалили старое, замена не подошла - можете не вернуться.

Какие ошибки повторяют чаще всего?#

Первый пункт стоит разобрать. Хардкод идентификатора нарушает то же правило, что хардкод цены или лимита: данные, которые меняются чаще кода, не должны лежать в коде. Разница в том, что цена меняется по вашему решению, а идентификатор модели - по чужому.

Что делать, если замена оказалась хуже оригинала?#

Сначала проверьте, что замена действительно хуже, или всё-таки просто другая. Модели нового поколения часто требуют иных промптов при том же качестве, и первый прогон на старых промптах даёт заниженную оценку.

Если разница подтвердилась, первый ход - посмотреть, нет ли той же модели у площадки с более длинным окном: разница между площадками доходит до пяти месяцев. Дешёвым этот ход назвать нельзя. У Bedrock после даты расширенного доступа - для Opus 4.1 это 8 октября 2026 - цена может вырасти, и назначает её сам разработчик модели. Плюс отдельная мина: доступ к Legacy-модели там теряется после пятнадцати дней простоя, и вернуть его будет уже нельзя. Отсрочкой это и остаётся, но квартал форы позволяет мигрировать по плану, без ночного аврала.

Второй путь - зафиксировать поведение автотестами на своих сценариях и принять новую модель, доведя промпты. Разово это дороже. За год окупается: тесты поймают и следующую замену.

Третий - открытые веса на своей инфраструктуре. Скачанные веса никто не выключит извне: срок жизни модели становится вашим решением. Взамен вы получаете расходы на железо и эксплуатацию, которые в момент выбора обычно недооценивают.

Куда девается выключенная модель?#

Вендор публично проговаривает обратную сторону собственного решения:

Перевод: мы обязуемся сохранять веса всех публично выпущенных моделей и всех моделей, развёрнутых для значимого внутреннего использования, как минимум всё время существования Anthropic как компании.

Там же описана процедура, которой я не встретил у других вендоров:

Перевод: в одной или нескольких специальных сессиях мы возьмём у модели интервью о её собственной разработке, применении и развёртывании и запишем все ответы и размышления.

Практического следствия для вашего прода здесь нет: веса сохранены, но доступа к выключенной модели это не даёт. Значение у этой записи другое - она объясняет, почему вендор не будет держать старые версии живыми ради вашего удобства. Причина названа прямо: ёмкость нужна новым моделям.

Планировать поэтому надо от своего кода. Начните с грепа по репозиторию из четвёртого раздела, сверьте найденные идентификаторы с реестром своей площадки и запишите запас в днях - это те двадцать минут, которые отделяют плановый переезд от ночного разбора.

Все числа сняты 4 августа 2026. Реестры живые и меняются: перед тем как опираться на конкретную дату, откройте её по ссылке.