Смена модели меняет условия интеграции, а не только её идентификатор

28 сентября Anthropic выпустила Claude Sonnet 5.5, сообщив о росте скорости и эффективности выполнения задач. Командам, которые сами формируют запросы к Messages API, стоит уделить руководству по миграции не меньше внимания, чем заявлениям о производительности. В нём описаны изменения допустимых параметров и обработки истории диалога. Пользователям Claude Managed Agents, напротив, по словам Anthropic, достаточно обновить название модели. Ниже речь идёт о собственных интеграциях с API. [1] [2]

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

Sonnet 5 принимала thinking: {"type": "disabled"}. Sonnet 5.5 возвращает для этой настройки ошибку 400. Минимальный режим размышления новой модели — between_tools; он доступен при уровнях усилия low, medium и high, но отклоняется при xhigh и max. Это изменение контракта запроса, а не просто настройки качества. Командам, использовавшим disabled для ограничения задержки, нужно осознанно выбрать новый режим и заново измерить рабочий процесс, а не рассчитывать, что прежний запрос продолжит работать. [2]

Режим between_tools отключает расширенное размышление перед ответом, но сообщения о ходе работы между вызовами инструментов по-прежнему могут приходить в блоках thinking. Цикл работы с инструментами должен возвращать эти блоки вместе с сообщением ассистента без изменений. Следует проверить клиенты, которые считают первый блок содержимого текстом либо восстанавливают ответ ассистента только из текста и вызовов инструментов. При чтении ориентируйтесь на тип блока; для продолжения передавайте сообщение ассистента целиком в том виде, в котором его вернул API. [2] [6]

Sonnet 5.5 отклоняет значения tool и any, принудительно задаваемые через tool_choice. Anthropic рекомендует auto и строгие схемы инструментов там, где они поддерживаются. Строгая схема ограничивает формат состоявшегося вызова; при auto модель по-прежнему может ответить без вызова. Для этой модели Amazon Bedrock не поддерживает строгие вызовы инструментов, поэтому там приложения должны самостоятельно проверять входные данные инструмента. [2] [4]

Это важно для работы системы. Если перед ответом процесс обязан получить актуальную запись, правильно оформленный ответ не доказывает, что запись была получена. Считайте шаг завершённым только после получения и проверки обязательного результата инструмента. Закрепите правило в приложении и проверьте оба пути: корректный вызов инструмента и прямой ответ, когда вызов был обязателен. Это архитектурный вывод из задокументированного поведения инструментов, а не утверждение о том, как часто Sonnet 5.5 пропускает вызовы.

Блоки thinking, созданные Sonnet 5.5, может повторно использовать только создавшая их учётная запись или связанная с ней запись. Если такой блок отправит несвязанная учётная запись, API отбросит его до инференса и всё же успешно выполнит запрос; без соответствующего диагностического заголовка это произойдёт незаметно. При смене модели блок также может оказаться нечитаемым. Поэтому успешный ответ маршрутизатора не доказывает, что модель получила прежние рассуждения. [3]

Есть и отдельное правило для предшествующей части диалога: при повторной отправке подписанного блока thinking прежние системные инструкции, инструменты и сообщения должны оставаться неизменными. Для учётных записей, созданных 31 августа 2026 года или позднее, проверка включена по умолчанию; у более старых записей настройки по умолчанию иные. Поэтому отсутствие ошибки с одним ключом не служит доказательством для всех. Сохраняйте историю только с добавлением новых записей и проверяйте при миграции сохранение и возобновление диалога, изменение инструментов, обрезку истории на стороне клиента и смену маршрута. Где это поддерживается, смотрите input_transformations, чтобы увидеть отброшенные блоки. [3]

Руководство по миграции также требует обрабатывать отказы. Отказ должен учитываться в логике ответа и проверки продукта. Повторять его вслепую как сбой сетевого запроса — значит путать решение по правилам использования с недоступностью сервиса. Anthropic описывает ограниченный необязательный серверный переход на другую модель для некоторых категорий отказов в Claude API. Это не делает любой отказ поводом для повторной попытки и не обещает одинакового поведения у всех поставщиков хостинга. [5]

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

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

Лишь после этого сравнивайте долю принятых задач, затраченное время и стоимость одной принятой задачи при явно указанном уровне усилия. Заявления Anthropic о скорости и стоимости полезны как гипотезы для такого эксперимента, но не заменяют его. Общий вывод выходит за рамки этого релиза: модель — часть протокола между приложением, инструментами, историей и пользователями. Обновление завершено, когда этот протокол по-прежнему даёт предусмотренный результат. [1]