A 413 request_too_large error is unusual among API failures: on the direct Claude API it is returned by Cloudflare, the edge network in front of the API, before your request body ever reaches Anthropic's servers — let alone the model. There is nothing to retry and no parameter to tweak; the payload itself has to shrink or move. The first step is knowing which ceiling you hit, because there isn't just one.
The three Anthropic ceilings
| Endpoint | Maximum request size |
|---|---|
| Messages API | 32 MB |
| Token Counting API | 32 MB |
| Message Batches API | 256 MB |
| Files API | 500 MB |
The 32 MB Messages limit covers the entire JSON payload — messages, system prompt, tool definitions, and every base64-encoded image or PDF inline. Base64 encoding inflates binary data by roughly a third, so "my images are only 20 MB on disk" can still overflow a 32 MB request. The Batch API's 256 MB applies to the whole batch submission, which is also capped at 100,000 requests, whichever limit is reached first. The Files API's 500 MB is per uploaded file, with a separate 500 GB total storage cap per organization.
Why vision workloads hit it first
Vision-heavy requests are the classic trigger. The Messages API allows up to 600 images per request on most current models — but at typical photo sizes you will hit the 32 MB payload ceiling long before you hit the image count. Anthropic's own vision documentation calls this out and recommends the fix: upload images once through the Files API and reference them by file_id, keeping the actual Messages payload tiny. The same trick applies to PDFs. Note the platform caveat, though — the Files API is available on the Claude API, Claude Platform on AWS, and Microsoft Foundry (beta), but not on Amazon Bedrock or Google Vertex AI, where images and PDFs must be sent as base64.
The 3P platforms have their own ceilings
If you're calling Claude through a cloud provider, the front door changes and so does the limit. Anthropic documents a 20 MB request payload limit on the legacy Amazon Bedrock surface (InvokeModel/Converse), and a 30 MB limit on Google Vertex AI — where images are additionally capped at 5 MB each and 100 per request. On these platforms the oversize rejection comes from the platform's own gateway, not Cloudflare, and the error shape follows the platform's conventions. The practical ordering to remember: Bedrock legacy (20 MB) < Vertex (30 MB) < direct API (32 MB), so a request that works against the first-party API can fail unchanged on Bedrock or Vertex purely on size.
Choosing the right ceiling on purpose
Once you know the tiers, you can design for them. Large document analysis? Upload once via the Files API (500 MB per file) and reference it in every subsequent Messages call — the message payload stays kilobytes-small and you stop paying the upload cost repeatedly. High-volume offline processing with big contexts? The Batch API's 256 MB envelope holds far more than any single Messages call could. Many images in one interactive request? Downscale before encoding — the vision docs note images above the model's resolution ceiling get downscaled server-side anyway, so sending full-resolution originals wastes payload budget for zero quality gain.
One diagnostic tip: because Cloudflare rejects oversize requests at the edge, a 413 arrives fast and without a normal Anthropic error body's context. If you see instant 413s only in production but not in staging, compare payload assembly — an unexpectedly inlined document or an unresized user upload is the usual culprit.
Where to go next
See the full API error code reference for the rest of the 4xx family, the Files API guide for the reference-by-ID pattern, and the 4xx error taxonomy for how to route each failure to the right fix.