Claude API requests go to 128 MB: what fits now, and which limit bites first
On October 28 Anthropic raised the maximum request size for the Messages API and the Token Counting API from 32 MB to 128 MB on the first-party Claude API, according to the release notes. It is a one-line change, and for document-heavy agent pipelines it removes the failure I hit most often: a 413 request_too_large on a batch of scanned PDFs that would have fit in the context window easily. The interesting part is everything the change did not touch.
The new limits table
The API overview now lists these maximums: Messages and Token Counting at 128 MB, Message Batches at 256 MB, the Files API at 500 MB, and Sessions, Agents and Environments still at 32 MB. Anything over the limit returns 413 request_too_large.
The partner platforms did not move. Bedrock caps requests at 20 MB, Claude Models on Google Cloud (Google managed) at 30 MB, and Claude Platform on AWS, Claude Models on Google Cloud (Anthropic managed) and Microsoft Foundry at 32 MB. If your pipeline fails over from the first-party API to Bedrock during an outage, a request that worked a minute ago now fails at about a sixth of the size. I would rather find that in a test than in an incident review.
Bytes are no longer the binding limit
The PDF documentation allows up to 600 pages per request, or 100 when the request's context window is under 1M tokens, and estimates 1,500 to 3,000 tokens per page because each page is also processed as an image. Do the multiplication: 600 pages at 1,500 tokens is 900,000 tokens, and at 3,000 it is 1.8M. A 600-page dense PDF does not fit in a 1M window, whatever its size in bytes. The docs say as much: dense PDFs "can fill the context window before reaching the page limit".
Images follow the same pattern. The vision docs accept up to 600 images per request, at most 10 MB each base64-encoded, and an image costs ceil(width/28) times ceil(height/28) visual tokens. A 1000 by 1000 image is 1,296 tokens, so 600 of them come to about 778,000 tokens. On the high-resolution tier (Claude 4.7 and later models) one image can reach 4,784 visual tokens, and 600 of those would be about 2.9M. Once a request has more than 20 images, every image in it must stay within 3,000 px per side.
| Payload | Bytes | Tokens | What fails first |
|---|---|---|---|
| 600 sparse PDF pages | can fit in 128 MB | about 0.9M | Fits a 1M window, barely |
| 600 dense PDF pages | can fit in 128 MB | up to 1.8M | Context window |
| 600 full high-res images | often over 128 MB | about 2.9M | Context window |
The 128 MB limit moves the wall from your HTTP client to the context window. It does not remove the wall.
Where it actually helps
Base64 inflates binary data by a third, so 128 MB of request body carries roughly 96 MB of raw files. The realistic wins are medium-sized document sets that used to need splitting purely because of bytes: scanned contracts at high DPI, image-heavy slide decks exported to PDF, and computer-use loops where screenshots pile up in the conversation history.
That last case hides a trap. An agent loop resends the whole conversation on every turn. If you inline a 40 MB PDF as base64 in turn one, you upload it again on turns two through thirty, and you pay its input tokens again unless prompt caching is set up correctly. The PDF docs recommend uploading large files once with the Files API and referencing them by file_id. With 128 MB allowed, it becomes much easier to get this wrong without any error telling you.
How I would configure a pipeline today
Keep the request size limit as a per-platform constant, never a global one: 128 MB for Messages on the first-party API, 32 MB, 30 MB or 20 MB on the partner platforms, and 32 MB for Sessions and Agents even on the first-party API. Measure the serialized body before sending, and route anything over the target platform's limit to a Files API upload instead of a split.
Then put a token preflight in front of every large call. The Token Counting endpoint got the same 128 MB limit, so you can count exactly the payload you are about to send. If the count is above roughly 80% of the model's window, split by section before the model sees it, because output and thinking need room too. I explained why the usable window is smaller than the advertised one in the context window is bigger than the context you can use, and what a 1M window does to retrieval design in Claude Opus 5 and the RAG layer.
Finally, test the failover path with a 25 MB request. If it reaches Bedrock and dies with a 413, you have found the bug that the 128 MB limit quietly introduced into your architecture.