413 request_too_large: your request body is over 20 MiB

A 413 request_too_large means the HTTP body of your request to go2llm went over the allowed size — 20 MiB. This is a gateway-level check, and the request never reaches a model: nothing is reserved, nothing is charged. Almost every case comes down to one thing — a large file landed in the request whole (a base64 image, a PDF, a long conversation history with attachments), not the generation parameters themselves.

Written 2026-09-22.

What the error looks like

Over the limit, go2llm answers with status 413 and the same JSON envelope as every other gateway error: error.type and error.code are both request_too_large, error.message spells out the limit in words, and error.request_id starts with gw_. The exact wording of message hasn't been captured from a live request for this page — on a slow connection, a body over 20 MiB doesn't fully arrive in reasonable time, and the client hits its own timeout before a 413 comes back. That's a useful symptom on its own: if a large-body request hangs with no response even on a fast connection, check the body size before you suspect the network.

What causes it

An image or PDF sent whole inside a text request

The most common case is an attempt to pass a file as base64 straight into POST /v1/messages or POST /v1/chat/completions. go2llm's text endpoints don't accept binary attachments at all, and they usually return 400 unsupported_content_type before the body ever grows to 20 MiB — but a genuinely huge file (a high-resolution scan, a long multi-page PDF) can hit the size limit first if it's big enough. See the related unsupported content type error for that case.

Conversation history growing without a trim

If an application keeps accumulating message history without ever trimming it, and that history once held large text blocks — a pasted log, a data dump — the total body size creeps up in a way that's invisible from any single message. Each message on its own can look reasonable; the sum doesn't.

Image params on POST /v1/images/generations

A request body for image generation is normally small — a text prompt, not a file. Hitting the limit here almost always means an encoded file ended up in prompt or one of the auxiliary fields by a client-side bug, not an intentional large payload.

How to fix it

Step 1. Find what's inflating the body. Measure it before you send, not after the error:

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("body exceeds go2llm's 20 MiB limit before it's even sent")

Step 2. If it's an image or a PDF, don't encode the file into a text endpoint's body at all — go2llm's text endpoints reject them regardless of size. For images, use the dedicated POST /v1/images/generations.

Step 3. If it's conversation history, trim it client-side before sending: keep the last N messages, or summarize the older ones instead of letting the full log accumulate. This fixes 413 and lowers the bill at the same time — the bigger the body, the more input tokens you pay for on every request.

Step 4. Check the actual body size after assembly with one request:

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

How go2llm's limit differs from Anthropic's

The direct Anthropic API sets higher limits that vary by endpoint: the Messages API and the Token Counting API allow up to 32 MB, the Batch API up to 256 MB, the Files API up to 500 MB. go2llm uses one limit for everything — 20 MiB on any POST request, with no split by endpoint, because go2llm doesn't expose a Batch API or a Files API at all: the only routes are /v1/messages, /v1/chat/completions, /v1/responses, /v1/images/generations, and /v1/messages/count_tokens. Source for the direct API's numbers: platform.claude.com/docs/en/api/errors, "Request size limits" section, checked 2026-09-22.

Anthropic's own docs make a separate point worth knowing: "On the direct Claude API, Cloudflare returns this error before the request reaches the API servers" — the cutoff on the vendor's side happens at the CDN, before any backend sees the request. On go2llm, the size check is part of the gateway itself.

In practice, this means a request that just squeaks under the direct Anthropic API's ceiling — 25 MB, say — will still hit a 413 on go2llm, even though it's technically inside the vendor's Messages API limit. Migrating an integration from the direct API to go2llm and used to sending large bodies on purpose? Narrow that to 20 MiB on your own side.

Avoiding it next time

Measure body size on the client before sending, rather than treating the server's response as the only check — on a slow connection, a request that's going to be rejected anyway still wastes time uploading first. For conversational apps, put a hard cap on history length, or add a summarization step for old messages: it fixes 413 and cuts cost, since input tokens are billed regardless of the outcome.

413 isn't worth retrying. Sending the same body again gets the same answer. Shrinking the body is the only real fix.

Related errors

• 409 idempotency_conflict — also about /v1/images/generations, but about reusing an Idempotency-Key, not body size.
• 429 rate_limit_error — a request-rate limit, not a single request's size.
• The full error reference.

FAQ

Can the 20 MiB limit be raised for my key? No. The limit is shared across every key and isn't configurable in the dashboard — unlike the dollar quota, the model list, the IP allow-list, and the expiry date, which are.

Does a request that returns 413 get charged? No. go2llm only reserves cost after a request clears gateway-level checks, including body size — a 413 stops the request before any reservation happens.

Is 413 about the size of the request or the response? Only the incoming request body. The size of the model's reply is capped by max_tokens (or max_output_tokens), not this code.

Why is Anthropic's limit 32 MB and go2llm's 20 MiB? go2llm doesn't reuse the vendor's limit directly — 20 MiB is the gateway's own limit, applied the same way to every supported model and provider, not only to requests that end up going to Anthropic.

Get a key and make your first request in 3 minutes → go2llm.tech. Per-model prices are on the pricing page, setup steps are in the docs.