Claude API 413 request_too_large: the limit is now 128 MB — Bedrock and third-party limits, and how to send large PDFs and screenshots

Short answer: according to the Claude docs, the first-party Claude API now accepts Messages and Token Counting requests up to 128 MB (up from 32 MB). Batch is 256 MB and the Files API is 500 MB. That only covers Anthropic's own API: Amazon Bedrock is still 20 MB, Google-managed Claude on Vertex is 30 MB, and Claude Platform on AWS, Anthropic-managed Google Cloud and Microsoft Foundry are 32 MB. Third-party gateways set their own caps too.

We tested Messages requests from 10 MB to 130 MB with our own key:

• up to about 50 MB everything returned 200 in 5 to 9 seconds;
• from about 54 MB we got 413, and the largest requests were rejected in about 1 second.

So when you see 413, don't switch models. Measure the request body, then shrink images, split PDFs and drop old screenshots. The context window did not grow: fitting in 128 MB does not mean it fits in tokens.

Create an API Key and use Claude in Claude Code →

How to recognize 413 request_too_large

The official API returns HTTP 413 with error type request_too_large:

{
  "type": "error",
  "error": {
    "type": "request_too_large",
    "message": "Request exceeds the maximum allowed number of bytes."
  }
}

According to the official errors page, on the first-party Claude API this error is returned by Cloudflare before the request reaches the API servers. That means:

• the request never reached the model, produced no output and used no tokens;
• retrying the same request will not help; the body has to get smaller;
• it is a different problem from 400 invalid_request_error (bad format), 429 (rate limit) and 529 (overloaded).

Through a third-party gateway the 413 body looks different. In our test we saw two forms: the gateway's own message (in Chinese, "request body too large, please reduce content and retry"), and bad response status code 413, meaning the upstream returned 413. Treat both as "request too large". For other errors see Claude Haiku 5.5 API error troubleshooting.

Measure your request body first:

import json
body = json.dumps(payload).encode()
print(f"{len(body) / 1024 / 1024:.1f} MB")

Request limits by platform

Figures are from the official API overview; the docs also say each cloud platform's own documentation is authoritative. According to AlphaSignal, the increase is aimed at image-heavy requests.

Other limits apply alongside size (according to the Vision docs and PDF docs):

• each image can be at most 8000×8000 px; with more than 20 images in one request, every image's long side must be 3000 px or less (2000 px before, according to AlphaSignal), otherwise you get invalid_request_error mentioning many-image requests;
• up to 600 images per request, 100 for models with a 200K context window;
• PDFs are limited to 600 pages per request, 100 when the context window is under 1M tokens;
• base64 adds about a third: a 3 MB PNG becomes about 4 MB.

Fix 1: compress and downsample images

The model does not look at your full resolution. According to the docs, Claude 4.7 and later models resize images to a long side of 2576 px, and other models to 1568 px. Sending 4K screenshots just multiplies the bytes. Resize before sending:

from PIL import Image
import base64, io

def shrink(path, max_side=1568, quality=80):
    im = Image.open(path).convert("RGB")
    im.thumbnail((max_side, max_side))
    buf = io.BytesIO()
    im.save(buf, "JPEG", quality=quality, optimize=True)
    return base64.b64encode(buf.getvalue()).decode()

Rules of thumb:

• convert screenshots to JPEG (quality 75 to 85), much smaller than PNG;
• keep the long side at 1568 px, go to 2576 px only for small text;
• with more than 20 images, always keep the long side under 3000 px;
• send an image once in a conversation and refer to it in text afterwards.

Fix 2: send large PDFs by Files API file_id

On the official API, upload big files to the Files API (500 MB per file), then reference the file_id in Messages so the body only carries an ID:

curl https://api.anthropic.com/v1/files \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: files-api-2025-04-14" \
  -F "file=@report.pdf"
# -> {"id": "file_011C...", ...}

{"type": "document", "source": {"type": "file", "file_id": "file_011C..."}}

According to the docs, multi-turn and agent workflows resend the full history every turn, so base64 images are re-sent every time; with file_id the body stays small as images accumulate.

If your gateway does not support the Files API (calling the upload endpoint on our gateway returned 400 in this test), split the PDF and send it in parts, each within 100 pages and the request limit:

qpdf report.pdf --pages . 1-100 -- part1.pdf
qpdf report.pdf --pages . 101-200 -- part2.pdf

Each PDF page is processed as an image, so lowering the resolution of embedded images in scanned PDFs shrinks them a lot.

Fix 3: in long computer use and Claude Code sessions, drop old screenshots

Computer use and screenshot-heavy agents hit 413 most often: every step adds a screenshot in tool_result, every turn resends the whole history, and after a few dozen steps the body passes 100 MB. According to the docs, screenshots inside tool_result also count toward the 20-image threshold.

What to do:

• keep only the last few screenshots and replace older ones with a line of text ("step 12: settings page open");
• in your own agent loop, summarize the history every N steps and continue from the summary;
• in Claude Code, run /compact or start a new session for long tasks. For how Claude Code compaction triggers, see Claude Code idle compaction.

To point Claude Code at a third-party endpoint, put the global config in ~/.claude/settings.json:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.aicodewith.ai",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY"
  },
  "model": "claude-sonnet-5-5"
}

The address is https://api.aicodewith.ai without /v1. Full steps: Claude Code third-party API setup; for the October 21 API version and SDK changes see Claude API 2026-10-21 migration.

Test: how large a request our gateway accepts

Method: claude-sonnet-5-5, max_tokens 16, a single Messages request carrying several base64 images (16×16 px images with padding bytes to keep tokens low), from 10 MB up to 130 MB, POSTed to https://api.aicodewith.ai/v1/messages.

Result: in our test, Messages requests through our gateway returned 200 up to about 52 MB and 413 from about 54 MB, below the official 128 MB. Everyday chats with images, a few screenshots or a PDF of a few dozen pages are far below that; if you really need to send tens of MB, the three fixes above are the safer path. A few requests dropped the connection during upload and worked on resend. We deleted the test script and request files afterwards.

Create an API Key and connect Claude to Claude Code →

FAQ

With 128 MB, can I send more content?

The byte limit grew; the context window did not. A large image resized to the model's working resolution has a fixed token count, so extra bytes are wasted bandwidth. Text usually hits the context window long before 128 MB.

What is the difference between 413 and 400 "prompt is too long"?

413 means too many bytes and the request is stopped before the model; prompt is too long means too many tokens for the context window and the request did reach the API. Shrink bytes for the first, remove content or compact history for the second.

Why do I still get 413 on Bedrock?

Bedrock's limit is 20 MB and Google-managed Vertex is 30 MB; 128 MB applies only to the first-party Claude API. Compress to the platform's own limit.

Can Batch carry bigger requests?

A whole batch can be 256 MB, but each item is still a Messages request. Batch is for many offline jobs, not a way around the per-request size.

Will retrying fix 413?

No. The same body is rejected every time; make it smaller first.