Claude's API Now Takes 128 MB Requests, Up From 32 MB. Bedrock Still Caps at 20 MB. Check Which Number Your Code Actually Hits.
Anthropic raised the maximum request size for the Messages and Token Counting endpoints from 32 MB to 128 MB. That is a fourfold jump, and if you send PDFs, screenshots or long transcripts inline, it removes a limit you have probably coded around.
The catch is that the number in the headline is only the limit for one route to the model. Depending on how you reach Claude, your real ceiling can be a fifth of that.
The limits as documented
Anthropic's API overview lists these maximum request sizes for its first-party API: 128 MB for Messages and Token Counting, 256 MB for the Message Batches API, 500 MB for the Files API, and 32 MB for Sessions, Agents and Environments. Go over and you get a 413 request_too_large error.
Partner platforms have their own limits, and the page tells you to check each one. Amazon Bedrock is 20 MB. Claude models on Google Cloud, when Google managed, are 30 MB. Claude Platform on AWS, Claude models on Google Cloud when Anthropic managed, and Microsoft Foundry accept Messages and Token Counting requests up to 32 MB.
So the same 60 MB payload works on one route and fails on the others. The 32 MB to 128 MB change was reported in a daily AI digest on October 30, and the context-window limits still apply separately. A big request is not a big context. You can fit in the byte limit and still blow past the token window.
Why I'd care even if I never send 100 MB
Most solo products do not send 100 MB. But file-heavy features creep: a user uploads a scanned contract, a 90-page deck, a folder of receipts. Base64 inflates files by about a third, so a 24 MB PDF becomes a roughly 32 MB request, which was exactly the old edge. Features that used to fail quietly at that boundary will now work, which is nice, until you move providers and they start failing again.
If you route through a gateway or SDK wrapper, check whether it enforces its own limit. A reverse proxy with a default body-size cap of a few megabytes is the more common culprit than the model API itself.
Three changes I'd make
First, handle the 413 explicitly. Catch request_too_large and return a human message such as "that file is too big for this feature," not a generic error. Log the byte size, so you learn where users actually land.
Second, check size before you send. Compute the encoded payload length and compare it against a constant you set per provider. Put that constant in config, so changing your route changes one value. If you support more than one platform, set it to the smallest limit among them.
Third, use the Files API for anything large or reused. Upload once, reference many times, and stay well under the per-request cap. This also saves you from re-sending the same 20 MB document on every turn of a conversation.
The honest counter-take
You could say this is a non-event. Few apps hit 32 MB, and a raised cap just moves the failure from "too big" to "too slow and too expensive." That is fair. Sending 100 MB inline is usually a design smell, and the token cost of a huge document dwarfs any transfer concern.
I would also be careful with my own read here: I am relying on the docs page for the numbers, and the platforms update these limits without much notice, so verify the figure for your specific route before you hard-code it. But I would still make the three changes above. They cost an hour, and they turn a mysterious production error into a clear message.
Author
Lukas
@lukcombinator