Три критических изменения API в Claude Sonnet 5: что обязан проверить каждый оператор перед миграцией

Публикации о выходе Sonnet 5 сосредоточились на ценообразовании и benchmark-результатах. За кадром осталось главное: три поведенческих изменения на уровне API, которые молча сломают production-интеграции для команд, мигрирующих с Sonnet 4.6. Это не редкие пограничные случаи — они срабатывают на самых распространённых паттернах вызовов API.

Если ваша routing-политика уже направляет трафик на claude-sonnet-5, немедленно запустите аудит по чеклисту ниже.

Что изменилось

Официальная документация Anthropic What's new in Claude Sonnet 5 фиксирует три breaking-изменения и один скрытый множитель стоимости:

1. Adaptive thinking включён по умолчанию

В Sonnet 4.6 запросы без поля thinking выполнялись без extended thinking. В Sonnet 5 те же запросы теперь запускаются с adaptive thinking: модель сама решает, когда и сколько думать на каждый запрос.

Чтобы явно отключить thinking:

thinking = {"type": "disabled"}

Последствий два. Первое: любой сценарий, полагавшийся на latency-профиль Sonnet 4.6 без thinking, получит непредсказуемую задержку без явного отключения thinking. Второе: max_tokens — жёсткое ограничение на весь вывод, включая thinking-токены; значение max_tokens, подобранное под текст ответа Sonnet 4.6, теперь может обрезать вывод после добавления thinking-токенов. Пересмотрите все ограничения max_tokens для нагрузок, которые ранее не использовали thinking.

2. Sampling-параметры с нестандартными значениями возвращают 400

Передача temperature, top_p или top_k с любым нестандартным значением теперь возвращает ошибку 400. Это то же ограничение, которое Anthropic ввёл для Opus 4.7 и Fable 5; теперь оно распространяется на уровень Sonnet впервые.

# Sonnet 5 вернёт 400
response = client.messages.create(
    model="claude-sonnet-5",
    temperature=0.7,  # НЕ ПРИНИМАЕТСЯ
    ...
)

# Правильно: убрать параметр или передать значение по умолчанию
response = client.messages.create(
    model="claude-sonnet-5",
    # temperature опущен — используется значение по умолчанию
    ...
)

Любая система, передающая нестандартные temperature, top_p или top_k в Sonnet 4.6, немедленно начнёт получать ошибку 400 после миграции. Это затрагивает огромное количество production-интеграций: LangChain, LlamaIndex и большинство SDK-обёрток expose temperature как параметр верхнего уровня с ненулевыми значениями по умолчанию.

3. Ручной extended thinking удалён

Паттерн thinking: {type: "enabled", budget_tokens: N} был объявлен устаревшим в Sonnet 4.6; в Sonnet 5 он полностью удалён и возвращает ошибку 400.

# Не поддерживается в Sonnet 5 (ошибка 400)
thinking = {"type": "enabled", "budget_tokens": 32000}

# Используйте adaptive-режим
thinking = {"type": "adaptive"}
# или явно задайте уровень effort
effort = {"level": "high"}

Если ваш production-код вызывает Sonnet 4.6 с ручным thinking-бюджетом — например, интенсивный reasoning-воркфлоу для code review — такой код сломается в Sonnet 5 без внесения изменений.

4. Новый tokenizer — ~30% больше токенов для одного и того же текста

Sonnet 5 использует новый tokenizer. Один и тот же входной текст в Sonnet 5 производит примерно на 30% больше токенов, чем в Sonnet 4.6. Это не изменение API-контракта — форма запроса и ответа остаётся прежней — но затрагивает всё, что измеряется или бюджетируется в токенах:

• Поля usage: счётчики токенов в API-ответах для эквивалентных промптов будут выше.
• Вместимость контекстного окна: 1М-токенное окно вмещает меньше текста на токен, так что промпты вблизи старого лимита могут теперь его превышать.
• Ограничения вывода max_tokens: ограничение, подобранное для Sonnet 4.6, может раньше обрезать вывод в Sonnet 5.
• Стоимость запроса: тарификация за токен не изменилась, но каждый токен покрывает меньше текста; стоимость эквивалентного промпта может вырасти до 30%.

Не переиспользуйте счётчики токенов, измеренные для Sonnet 4.6. Пересчитайте их напрямую для Sonnet 5 для любого бюджета, имеющего значение.

Почему это важно для AI-инженерных команд

Командам, использующим AI gateway или многоуровневую routing-прослойку, необходимо рассматривать эти изменения на двух уровнях.

Для прямых вызовов API риски очевидны: жёсткие ошибки 400 на параметры temperature и thinking, если не удалить их до миграции; скрытое ухудшение latency, если adaptive thinking срабатывает на низколатентных путях; скрытый рост расходов при несбалансированных токенных бюджетах.

Для операторов gateway и routing-политик проблема тоньше. Если вы маршрутизируете claude-sonnet-latest через автоматическое обновление alias на Sonnet 5, любой downstream-вызов с temperature немедленно начнёт получать 400. Если ваш gateway проксирует поля параметров без фильтрации несовместимых с моделью значений — вы становитесь точкой молчаливого отказа. Это аргумент в пользу routing-политик, включающих правила трансформации параметров, а не только подстановку имени модели.

Та же проблема актуальна для fallback-цепочек. Если ваша основная модель — GPT-5.5 или Gemini 3.5 Flash с temperature=0.8, а fallback-цель — Sonnet 5, каждый fallback-вызов вернёт 400 вместо успешного fallback-ответа.

Точка зрения router/operator

Матрица совместимости параметров для routing-уровней

Поддержка routing-политики для нескольких provider требует знания того, какие параметры принимает каждая модель. Sonnet 5 делает этот вопрос ещё более критичным:

Нормализация параметров на уровне gateway — удаление или приведение к значению по умолчанию несовместимых с моделью полей перед отправкой — это теперь требование корректности, а не опциональная оптимизация, если вы направляете трафик от вызовов с temperature на Sonnet 5.

Чеклист пересчёта токенного бюджета

Перед переключением production routing-уровня на Sonnet 5:

1. Запустите подсчёт токенов заново для промптов на 10-м, 50-м и 90-м перцентилях длины против claude-sonnet-5. Базовое значение сдвинулось примерно на 30%.
2. Увеличьте бюджеты max_tokens для вывод-интенсивных путей как минимум на 30%, чтобы избежать обрезки.
3. Перепроверьте утилизацию контекстного окна для нагрузок вблизи лимита. Промпты, комфортно умещавшиеся в Sonnet 4.6, могут переполниться в Sonnet 5, если объём текста превышает эквивалент ~770K токенов Sonnet 4.6.
4. Пересчитайте прогнозы расходов. Используйте счётчики токенов Sonnet 5 для пересчёта ожидаемых ежемесячных затрат по основным типам запросов до закрытия ценового окна 31 августа.

Учёт thinking-токенов на routing-уровне

Adaptive thinking добавляет скрытое потребление токенов. Если ваш routing-уровень биллингует downstream-пользователей по счётчикам токенов из поля usage, thinking-токены теперь входят в общее количество output-токенов — это меняет семантику биллинга вашего routing-уровня. usage.output_tokens в Sonnet 5 включает thinking-токены при срабатывании adaptive thinking; в Sonnet 4.6 для тех же вызовов (без включённого thinking) этого не было.

Если вы показываете пользователям стоимость каждого запроса, вероятно, потребуется отдельная обработка биллинга thinking-токенов или информирование пользователей об этом изменении.

На что обратить внимание пользователям TheRouter

Командам, маршрутизирующим через TheRouter или любой AI gateway к Anthropic, следует:

1. Проверить, указывает ли alias Sonnet в вашем provider на claude-sonnet-5 сейчас или будет обновлён автоматически. Уточните список моделей gateway до переключения.
2. При прямом routing на claude-sonnet-5 выполнить проверку совместимости параметров со схемой запросов — особое внимание уделить полям temperature, top_p, top_k и thinking.
3. Сверьтесь с обзором моделей Claude API для получения актуальных ID моделей и руководством по миграции Anthropic для структурированного чеклиста миграции.

Если необходимо обновить несколько точек интеграции, skill /claude-api migrate в Claude Code автоматизирует исправление параметров по всей кодовой базе.