Claude API Raises Request Limit to 128 MB: What Changes for Developers

Anthropic raised the maximum request size for its first-party Messages API and Token Counting API from 32 MB to 128 MB on October 28. That gives developers four times the request-body capacity, helping with large multimodal inputs. It does not give Claude a four-times-larger context window.

This is a useful infrastructure change precisely because request bytes and model tokens can become bottlenecks at different points. A request can be too large to submit even before the model has a chance to process it.

Which Claude API limits changed

The release notes identify two affected APIs: Messages and Token Counting. The announcement specifically applies to the first-party Claude API, so developers should not assume that every cloud-provider endpoint changed with it.

Anthropic's current API overview lists the following limits:

Endpoint	Maximum request size
Messages and Token Counting	128 MB
Message Batches	256 MB
Files	500 MB
Sessions, Agents and Environments	32 MB

These are endpoint-specific request limits. A Files upload limit does not mean the same-sized content can be placed directly inside a Messages request, and the new Messages limit should not be copied into a Managed Agents integration without checking its endpoint.

More bytes do not mean more context

A request body is the data sent to the server. A context window is the amount of model input and output that can fit into a particular interaction. They are related, but they measure different things.

For example, a workflow that includes encoded images may spend substantial request-body space on the representation sent over the network. Giving that request more room can remove an upload obstacle without changing how much text or visual information the selected model can use.

The practical implication is narrower than “send everything.” Developers still need to choose relevant material and check the model's limits. Sending a larger payload does not establish that an answer will be better, faster or cheaper.

Count tokens before submitting the larger request

Anthropic's Token Counting guide explains that the endpoint accepts structured message inputs, including system prompts, tools, images and PDFs, and returns an input-token count.

Raising both endpoints together is useful: an application can inspect an input that fits the new Messages request ceiling without being stopped by the old 32 MB counting ceiling first. The count helps with routing and prompt sizing; it does not replace the other validation an application needs.

For a document-review workflow, that suggests two separate checks. First, confirm that the serialized request fits the transport limit. Then check whether its model input fits the intended context and cost budget. Combining those checks into one approximate file-size rule can hide the reason a request fails.

Handle a 413 differently from a rate limit

The API error reference identifies 413 request_too_large as a request exceeding the allowed byte size. That is different from a 429 rate_limit_error.

Retrying an unchanged oversized body does not make it smaller. If a request still exceeds the new ceiling, the useful response is to reduce or reorganize what is being submitted, while also checking any lower limits imposed by the application's own proxy or gateway.

For teams already managing large inputs, the first task is to check whether an old 32 MB assumption remains in client-side validation. Removing an obsolete restriction may make the added capacity usable. Removing all input controls would be a different, and much less defensible, change.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn API changes and engineering work into clear developer stories without making them sound like marketing.

Book a 30-minute call.