AWS Claude 400 Error: как найти причину и исправить запрос
Ошибка HTTP 400 при работе с Claude через AWS Bedrock выглядит просто: сервер получил запрос и отказался его обработать. На практике за одним и тем же кодом скрываются совершенно разные проблемы. Неверный model ID, неподходящий JSON, несовместимый режим thinking, сломанная история tool use, ограничения квоты или настройки хранения данных требуют разных решений.
Поэтому первое правило простое: не отправляйте тот же запрос снова в надежде, что AWS передумает.
Сначала смотрите на текст ошибки
Сохраните полный ответ AWS. Нужны:
- код исключения;
- полный текст ошибки;
- Region;
- model ID или inference profile;
- используемый endpoint;
- Request ID.
Для Claude Code дополнительно проверьте версию командой claude –version и выясните, идет ли запрос напрямую в AWS или через gateway.
HTTP 400 сам по себе мало что говорит. Например, ValidationException действительно может означать неправильный формат запроса. Но InvokeModel способен вернуть ServiceQuotaExceededException тоже с HTTP 400. В таком случае проблема связана с квотой аккаунта, а не с JSON.
У Converse другая картина: ValidationException относится к 400, AccessDeniedException к 403, а throttling обычно приходит как 429.
Быстрая диагностика
| Что написано в ошибке | Что проверить |
|---|---|
| Invalid model identifier | Model ID, inference profile и Region |
| Malformed input, missing field, extraneous key | Формат JSON именно для выбранного API |
| Extra inputs are not permitted | Версию Claude Code, beta-функции и gateway |
| Tool-use или thinking block mismatch | Предыдущие сообщения и историю инструментов |
| Ошибка thinking mode или token budget | Возможности конкретной модели |
| Data retention | Политику аккаунта, Region и модель |
| ServiceQuotaExceededException | Квоту AWS и текущее использование |
Такой подход намного быстрее, чем менять параметры AWS наугад.
Проверьте, для какого API написан ваш JSON
Одна из самых частых причин 400 появляется после миграции между API. В AWS можно работать с Claude через несколько интерфейсов, и похожие названия здесь легко вводят в заблуждение.
Для native InvokeModel используется тело Claude Messages с anthropic_version, messages и max_tokens.
Для Converse структура другая. Там используются messages, content, а параметры генерации находятся в inferenceConfig.
У совместимого Anthropic Messages endpoint формат снова отличается и использует HTTP-заголовок anthropic-version.
Поэтому перенос JSON из одного примера в другой часто заканчивается 400.
Особенно легко ошибиться с max_tokens, inferenceConfig, старым полем prompt или параметрами из text completion API.
Для минимального native InvokeModel запрос может выглядеть так:
{
“anthropic_version”: “bedrock-2023-05-31”,
“max_tokens”: 64,
“messages”: [
{
“role”: “user”,
“content”: [
{
“type”: “text”,
“text”: “Reply with OK.”
}
]
}
]
}
Этот JSON нельзя просто скопировать в Converse. У него другой контракт.
Уберите из запроса все лишнее
Хороший способ найти виновника: собрать минимальный запрос.
Сначала оставьте только обычное текстовое сообщение. Уберите tools, изображения, guardrails, thinking и дополнительные параметры. Используйте тот же Region и ту же модель.
Если минимальный запрос проходит, возвращайте функции по одной:
- system instructions;
- историю диалога;
- tools;
- thinking;
- дополнительные параметры.
Как только появляется 400, подозреваемый найден.
Этот метод особенно полезен после обновления SDK или смены модели. Приложение может автоматически продолжать передавать старые параметры, которые новая модель уже не принимает.
Если ошибка появилась в Claude Code
Claude Code способен отправлять beta-поля и специальные заголовки. Gateway при этом может пропустить поле дальше, но потерять соответствующий anthropic-beta header. На выходе получится 400.
Сначала проверьте версию:
claude –version
Если сообщение требует более новую версию, обновите Claude Code.
Для проблем с экспериментальными beta-функциями можно протестировать отдельную сессию:
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 claude
Эта переменная убирает Anthropic-specific beta headers и beta tool-schema fields. Она при этом не отключает обычные cache_control.
Есть еще один неприятный сценарий: ошибка возникает только внутри существующего диалога. Причиной может быть нарушение соответствия между tool call и его результатом или проблема с thinking block.
В таком случае Claude Code рекомендует вернуться назад через /rewind или нажать Esc два раза. Ручное удаление случайных частей истории хуже: можно окончательно нарушить связь между вызовом инструмента и его результатом.
Проверьте модель и thinking
Модель, которая работает в одном AWS Region, не обязательно доступна по тому же идентификатору в другом.
Проверьте фактический modelId или inference profile, который использует приложение. Если AWS требует inference profile для выбранной модели, используйте существующий профиль для конкретного аккаунта и Region.
Отдельно проверьте thinking. Современные модели Claude используют разные режимы рассуждения, и старые настройки нельзя механически переносить на новые версии.
Например, AWS отдельно описывает adaptive thinking и более старые варианты конфигурации extended thinking. Некоторые модели отклоняют неподдерживаемые режимы с HTTP 400.
При обычном extended thinking значение budget также связано с max_tokens. Если запрос отправляет слишком большой или несовместимый budget, исправление JSON в других местах ничего не даст.
Большой диалог тоже может вызвать 400
На первый взгляд запрос может быть коротким. Но приложение способно отправлять вместе с ним всю историю разговора, десятки описаний инструментов и дополнительные инструкции.
Поэтому при ошибке лимита токенов проверяйте сразу две вещи:
- размер входного контекста;
- запрошенный объем выходных токенов.
Попробуйте новый короткий диалог с тем же model ID. Если он работает, проблема может находиться в накопленной истории, а не в самой модели.
Retention error требует проверки политики AWS
Если AWS прямо сообщает о проблеме с data retention, менять поля JSON бессмысленно.
Проверьте:
- выбранную модель;
- Region;
- эффективную политику аккаунта;
- разрешенные режимы хранения данных.
С настройками retention особенно опасно следовать старым инструкциям из блогов. AWS меняет эти механизмы, а старые статьи могут описывать уже неактуальную схему.
Сначала выясните, какие режимы разрешены именно для вашего аккаунта и выбранной модели. После этого проверяйте конфигурацию.
Когда ошибка действительно требует retry
Здесь легко потратить часы.
Если запрос содержит неправильный параметр, повторение отправки ничего не изменит. То же самое касается неправильного model ID, неподдерживаемого thinking mode и сломанной структуры Messages.
Retry имеет смысл при временных сбоях, throttling и некоторых проблемах с квотами.
Поэтому правильная последовательность выглядит так:
сохранить ошибку → определить exception → проверить Region и модель → выполнить минимальный запрос → вернуть параметры по одному → проверить исходную конфигурацию.
Если исправленный запрос снова падает, передавайте в поддержку AWS не скриншот с надписью 400, а Request ID, время ошибки, Region, model/profile ID, используемую операцию и очищенный от секретов пример запроса.
Один такой набор данных полезнее десятка повторных попыток.
