413 request_too_large: тело запроса больше 20 MiB

Ошибка 413 request_too_large означает, что тело HTTP-запроса к go2llm превысило допустимый размер — 20 MiB. Это проверка на уровне шлюза, до модели запрос вообще не доходит: деньги не резервируются и не списываются. Причина почти всегда одна — в запрос попал крупный файл целиком (изображение в base64, PDF, длинная история диалога с вложениями), а не параметры генерации.

Страница составлена 2026-09-22, обновлена 2026-09-22.

Как выглядит ошибка

При превышении лимита go2llm отвечает статусом 413 и тем же JSON-конвертом, что и остальные ошибки шлюза — error.type и error.code у этого кода равны request_too_large, error.message описывает превышение лимита словами, error.request_id начинается с gw_. Точный текст message для этой страницы живым запросом не зафиксирован — при проверке с медленным каналом загрузки запрос с телом за 20 MiB не успевает целиком дойти до сервера за разумное время, и клиент видит собственный таймаут раньше, чем ответ 413. Это само по себе полезный симптом: если запрос с крупным телом зависает без ответа даже на быстром канале, проверяйте размер тела в первую очередь, а не сеть.

Причины

1. Изображение или PDF отправлены целиком в текстовый запрос

Самый частый случай — попытка передать вложение в POST /v1/messages или POST /v1/chat/completions в кодировке base64. Текстовые endpoint'ы go2llm не принимают бинарные вложения в принципе и обычно отдают 400 unsupported_content_type раньше, чем запрос дорастёт до 20 MiB — но при очень крупном файле (сканы высокого разрешения, многостраничный PDF) можно упереться именно в лимит размера тела, если файл огромный. Разбор соседней ошибки — 400 unsupported_content_type.

2. Слишком длинная история диалога с вложенным контентом

Если приложение накапливает историю сообщений и не обрезает её, а в истории когда-то были крупные текстовые блоки (например, вставленный лог или дамп данных), суммарный размер тела растёт незаметно для разработчика — каждое отдельное сообщение может выглядеть разумным, а сумма — нет.

3. Изображение в `POST /v1/images/generations` через input-параметры

Для генерации изображений тело запроса обычно маленькое — промпт текстом, а не файл. Превышение здесь чаще всего означает, что в prompt или в служебные поля попал не текст, а закодированный файл по ошибке клиентского кода.

Как починить

Шаг 1. Найдите, что именно раздувает тело запроса. Посчитайте размер тела перед отправкой, а не после ошибки:

import json

body = {"model": "claude-sonnet-5", "max_tokens": 1024, "messages": messages}
size_bytes = len(json.dumps(body).encode("utf-8"))
print(f"{size_bytes / 1024 / 1024:.2f} MiB")
if size_bytes > 20 * 1024 * 1024:
    raise ValueError("тело превышает лимит go2llm в 20 MiB ещё до отправки")

Шаг 2. Если это изображение или PDF — не кодируйте файл в тело текстового запроса вообще: текстовые endpoint'ы go2llm их не принимают независимо от размера. Для изображений используйте отдельный POST /v1/images/generations.

Шаг 3. Если это история диалога — обрежьте её на клиенте до отправки: оставляйте последние N сообщений или суммаризируйте старые вместо накопления полного лога. Это не только чинит 413, но и снижает счёт: чем больше тело, тем больше входных токенов оплачивается на каждый запрос.

Шаг 4. Проверьте фактический размер тела уже после сборки, одним запросом:

curl -s -o /dev/null -w "upload size: %{size_upload} bytes\nhttp code: %{http_code}\n" \
  https://go2llm.tech/v1/chat/completions \
  -H "Authorization: Bearer $GO2LLM_API_KEY" \
  -H "content-type: application/json" \
  --data-binary @request-body.json

Чем лимит go2llm отличается от лимита Anthropic

У прямого API Anthropic лимиты выше и разные по endpoint'ам: Messages API и Token Counting API — до 32 MB, Batch API — до 256 MB, Files API — до 500 MB. У go2llm лимит один и общий — 20 MiB на любой POST-запрос, без деления по endpoint'ам, потому что Batch API и Files API у go2llm не опубликованы вовсе — доступны только /v1/messages, /v1/chat/completions, /v1/responses, /v1/images/generations и /v1/messages/count_tokens. Источник по прямому API: platform.claude.com/docs/en/api/errors, раздел Request size limits, сверено 2026-09-22.

Официальная документация Anthropic отдельно отмечает: «On the direct Claude API, Cloudflare returns this error before the request reaches the API servers» — то есть у вендора отсечение происходит на уровне CDN, ещё до бэкенда. У go2llm проверка размера — часть самого шлюза.

Для практики это означает: запрос, который проходит впритык на прямом API Anthropic (например, 25 MB), на go2llm получит 413, даже если формально укладывается в лимит Messages API вендора. Если вы переносите интеграцию с прямого API на go2llm и раньше отправляли крупные тела осознанно, лимит нужно сузить до 20 MiB на своей стороне.

Как избежать 413 в будущем

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

413 не входит в список кодов, которые имеет смысл ретраить: повторная отправка того же тела даст тот же ответ. Уменьшите тело — это единственная рабочая починка.

Связанные ошибки

400 unsupported_content_type — бинарные вложения в текстовом endpoint, часто срабатывает раньше 413 на том же типе запроса.
409 idempotency_conflict — тоже про /v1/images/generations, но про повторное использование Idempotency-Key, а не про размер тела.
429 rate_limit_error — лимит частоты запросов, а не размера одного запроса.
Справочник всех кодов и docs/errors.

FAQ

Можно ли увеличить лимит 20 MiB для своего ключа? Нет, лимит общий для всех ключей и не настраивается в кабинете — в отличие от квоты в долларах, списка моделей, IP allow-list и срока действия, которые настраиваются индивидуально.

Списываются ли деньги за запрос, который вернул 413? Нет. go2llm резервирует стоимость только после того, как запрос прошёл проверки на уровне шлюза, включая размер тела — 413 останавливает запрос раньше резервирования.

413 — это про размер запроса или про размер ответа? Только про размер входящего тела запроса. Размер ответа модели ограничивается параметром max_tokens (или max_output_tokens), а не этим кодом.

Почему у Anthropic лимит 32 MB, а у go2llm — 20 MiB? go2llm не переиспользует лимит вендора напрямую: 20 MiB — собственное ограничение шлюза, действующее одинаково для всех поддерживаемых моделей и провайдеров, а не только для тех запросов, что в итоге уходят к Anthropic.

Получить ключ и сделать первый запрос за 3 минуты → go2llm.tech. Цены на все модели — на странице тарифов, инструкции по подключению — в документации.