Claude API raises its request size limit to 128 MB and launches a Usage and Cost Analytics API in beta

Anthropic has made two changes to the Claude API in consecutive days that matter to anyone sending large documents to Claude or trying to understand what their organization spends on it. On October 28, 2026, the company raised the maximum request size for the Messages API and the Token Counting API on the first-party Claude API from 32 MB to 128 MB, a fourfold increase in how much data a single call can carry. On October 29, it launched the Usage and Cost Analytics API in beta, a new pair of endpoints that report token usage and cost for both Claude Console and Claude Enterprise organizations, with filtering and grouping by model, workspace, API key and the user or service account behind each request.

Both changes are documented in the Claude Platform release notes and in the updated API documentation. Neither changes model prices or rate limits, but together they touch two of the most common friction points in production deployments: requests rejected because a batch of PDFs or images is too heavy, and cost reporting that cannot easily answer who or what generated a bill.

The second announcement also reorganizes Anthropic's reporting surface. The existing Usage and Cost API, along with the `usage_report`, `cost_report`, `user_usage_report` and `user_cost_report` endpoints of the Claude Enterprise Analytics API, is now classified as legacy. Anthropic states that all of these endpoints remain supported, and it has published migration guides for both groups of users.

··········

THE NEW REQUEST SIZE LIMITS ON THE FIRST-PARTY CLAUDE API.

The request size limit is the maximum number of bytes a single HTTP request may contain, including the prompt text, the conversation history and any base64-encoded images or PDFs embedded in the message. Until October 28, Messages and Token Counting requests on the first-party API were capped at 32 MB. The documentation now lists 128 MB for both endpoints, while the other endpoint limits are unchanged.

........

Endpoint (first-party Claude API)	Before	After
Messages API	32 MB	128 MB
Token Counting API	32 MB	128 MB
Message Batches API	256 MB	256 MB
Files API	500 MB	500 MB
Sessions, Agents, Environments	32 MB	32 MB

........

A request that goes over the limit still fails with an HTTP 413 `request_too_large` error. Anthropic's error documentation specifies that on the first-party API this error is returned by Cloudflare before the request reaches the API servers, which means an oversized request is rejected at the edge and does not consume model capacity.

The change applies only to the first-party Claude API. According to the API overview, partner-operated platforms keep their own limits: Amazon Bedrock limits requests to 20 MB, Claude Models on Google Cloud (Google managed) to 30 MB, and Claude Platform on AWS, Claude Models on Google Cloud (Anthropic managed) and Microsoft Foundry support Messages and Token Counting requests of up to 32 MB. A team that runs the same application on several platforms therefore now faces a wider gap between environments, and code that relies on the new ceiling will not port unchanged to a cloud marketplace deployment.

··········

WHAT 128 MB MEANS FOR PDFS, IMAGES AND LONG-CONTEXT REQUESTS.

The practical effect is clearest with documents and images sent inline. When a file is embedded as base64, the encoding inflates it by roughly a third, so the old 32 MB ceiling left room for about 24 MB of raw binary data in a single request, while 128 MB allows roughly 96 MB. These are approximations based on the standard base64 ratio, before counting the text of the prompt itself.

The other limits that govern multimodal requests did not change, and they now become the binding constraint more often. The vision documentation sets a maximum of 10 MB per image (base64-encoded) on the Claude API, a maximum of 8000 x 8000 pixels per image, and up to 600 images per request for models with context windows above 200,000 tokens (100 for models with a 200k-token window). Requests with more than 20 images must keep every image at or below 3,000 pixels on each side. At the maximum per-image size, the old 32 MB limit fit three such images in a request; the new limit fits twelve.

........

Limit	Value on the first-party Claude API
Request size (Messages, Token Counting)	128 MB
PDF pages per request	600 (100 below a 1M-token context window)
Image size	10 MB per image, base64-encoded
Image dimensions	8000 x 8000 px (3,000 px if more than 20 images)
Images per request	600 (100 for 200k-context models)

........

For PDFs, the documentation now lists the 128 MB request ceiling alongside a limit of 600 pages per request, reduced to 100 pages when the request's context window is under 1M tokens, and specifies that both limits apply to the entire payload, including any other content sent with the documents. Anthropic estimates that each PDF page typically uses 1,500 to 3,000 text tokens depending on density, and because each page is also converted into an image, image token costs apply on top. A larger request size therefore does not make large documents cheaper: it removes a transport bottleneck, while the token bill still scales with the number and density of pages.

The documentation continues to recommend the Files API for large inputs. Uploading a PDF or image once and referencing it by `file_id` keeps request payloads small, avoids re-sending the same bytes on every turn of a conversation, and works within the separate 500 MB Files API limit. The higher inline ceiling is most useful for one-off jobs, stateless pipelines that cannot manage file lifecycles, and workloads that combine many medium-sized images or scanned pages in a single call.

··········

THE USAGE AND COST ANALYTICS API: ENDPOINTS AND ACCESS.

The second change is aimed at the people who have to explain an API bill. The Usage and Cost Analytics API exposes two endpoints, `GET /v1/organizations/analytics/usage`, which returns token and request counts, and `GET /v1/organizations/analytics/cost`, which returns cost in US dollars. Every request must carry the `anthropic-beta: analytics-usage-cost-2026-08-24` header in addition to the usual `anthropic-version` header.

Access depends on the type of organization. Claude Console organizations call the API with an Admin API key or another Admin API credential, such as an OAuth token with the `org:admin` scope; individual accounts cannot use the Admin API. Claude Enterprise organizations use a key with the `read:analytics` scope, created in claude.ai by the primary owner after the Analytics API is enabled. On Claude Platform on AWS the endpoints use AWS authentication and the IAM actions `ListAccountUsage` and `ListAccountCost`, and each request covers only the workspaces in that endpoint's region. On Claude Models on Google Cloud (Anthropic managed), the required IAM permissions are `usageAnalytics.list` and `costAnalytics.list`.

The data model is built around ranked rows rather than fixed time buckets. Each row represents one combination of the dimensions the caller groups by, and up to five dimensions can be combined in `group_by[]`. The documentation lists dimensions including model, workspace, API key, actor and actor type, service tier, context window, inference geography, speed, product, Claude Tag channel and user, RBAC group, user profile, and the Managed Agents identifiers for agent, environment, deployment and session. On the cost endpoint, two further splits, by cost type (tokens, web search, code execution, session usage) and by token type, do not count toward the five-dimension limit.

........

Parameter	What the documentation specifies
Time range	Start on or after January 1, 2026, within the last 365 days
Maximum span	31 days per request (24 hours with 1-minute buckets)
Time buckets	1m, 1h or 1d, or omitted for whole-range totals
Grouping	Up to five dimensions in group_by[]
Filters	Up to 100 values per filter, ORed within a filter, ANDed across filters
Page size	1 to 1,000 rows, default 20
Cost unit	USD, decimal strings in cents with six decimals

........

Cost rows carry two amounts. The `amount` field reflects cost after discounts and before credits, while `list_amount` reflects list prices, which lets finance teams separate the effect of negotiated discounts from raw consumption. Both are decimal strings in cents with six decimal places, so `"41280.000000"` corresponds to $412.80, and the documentation advises against parsing large values with binary floating point. Priority Tier requests appear with zero token cost, because the commitment fee is billed separately and is not included in this data.

··········

WHAT CHANGES FOR TEAMS ALREADY USING THE LEGACY REPORTS.

The legacy Usage and Cost API, served at `/v1/organizations/usage_report/messages` and `/v1/organizations/cost_report`, remains supported, as do the four Enterprise report endpoints. Anthropic's recommendation is to use the new API for any new integration, and the migration guide makes clear that moving an existing one is not a drop-in replacement.

The most significant operational difference is freshness. The legacy usage data typically appeared within about five minutes of a request completing. The new API's data typically refreshes within 4 hours and can take up to 24 hours, and values can still be revised until about seven days after the end of a calendar month. Every response includes a `data_refreshed_at` timestamp, and the documentation advises setting `ending_at` at or before a previously returned value for stable results, and querying only months that ended at least seven days earlier for invoicing-grade totals. Teams that use the legacy endpoint for near-real-time spend alerts should account for this before switching.

........

Aspect	Legacy Usage and Cost API	Usage and Cost Analytics API
Typical data delay	About 5 minutes	About 4 hours, up to 24 hours
Bucket parameter	bucket_width, default 1d	time_bucket_width, no default
Range per request	Bounded by bucket counts	31 days maximum
User attribution	account_ids[], service_account_ids[]	actor_ids[], group_by[]=actor
Cost detail	Amount only	amount plus list_amount
Code execution	Cost endpoint only	Rows with model set to null

........

Several smaller changes require code edits. The `bucket_width` parameter becomes `time_bucket_width`, `context_window[]` becomes `context_windows[]`, and account and service account filters are replaced by a single actor model. Grouping by the free-text `description` field is removed in favour of structured dimensions such as model, cost type, token type and service tier. The default workspace now appears with its real workspace ID rather than `null`, unknown IDs in filters match nothing instead of returning an error, and `inference_geo` and `service_tier` return `null` where the legacy API returned placeholder strings. For Enterprise customers, the per-user reports map to `group_by[]=actor` combined with `actor_types[]=user_actor`, and the `claude-tag` product value becomes `claude_tag`, although both spellings are accepted.

The documentation includes an example of the new client call in the Python SDK, which handles paging automatically:

client = anthropic.Anthropic()

rows = client.beta.organization.analytics.cost.list(
    starting_at="2026-09-01T00:00:00Z",
    ending_at="2026-10-01T00:00:00Z",
    group_by=["model", "cost_type", "token_type"],
)

for row in rows:
    print(
        f"{row.group.model} {row.group.cost_type} {row.group.token_type}: {row.cost.amount}"
    )

For organizations that use Claude Code, the documentation's suggested query for per-user Claude Code cost is the cost endpoint with `products[]=claude_code` and `group_by[]=actor`, which brings coding-assistant spend into the same reporting pipeline as API traffic.

··········

HOW THE TWO CHANGES FIT ANTHROPIC'S RECENT PLATFORM UPDATES.

The two announcements follow a dense month of platform changes documented in the same release notes. On October 20, Anthropic introduced user profiles, which let platforms and resellers tell Anthropic which end customer each request belongs to, and on October 22 it launched Claude Models on Google Cloud (Anthropic managed), covered by Data Studios in its report on managed Claude agents on Google Cloud. The new analytics API exposes several of these additions as reporting dimensions, including `user_profile_id`, the Claude Tag fields and the Managed Agents identifiers, so organizations can attribute cost to the same entities they now manage through the platform.

The request size change, in turn, aligns the inline limit more closely with the scale of the newest models. Anthropic's own documentation ties PDF page limits to the context window, allowing 600 pages only in requests with a context window of 1M tokens or more, and a 32 MB payload ceiling could be reached well before such a request used its token budget. Readers comparing per-token costs across the Claude family can find the latest pricing context in Data Studios' coverage of Claude Haiku 5.5.

··········

WHAT IS ESTABLISHED AND WHAT REMAINS OPEN.

The documented facts are specific. Since October 28, 2026, Messages and Token Counting requests on the first-party Claude API may be up to 128 MB, while partner platforms keep limits between 20 MB and 32 MB and the per-image, per-page and per-request image limits are unchanged. Since October 29, the Usage and Cost Analytics API is available in beta to Console and Enterprise organizations, with detailed attribution by model, workspace, key and actor, explicit separation of discounted and list cost, and slower data freshness than the endpoint it is meant to replace.

Several points are not yet documented. Anthropic has not published a deprecation or retirement date for the legacy usage and cost endpoints, only that they remain supported. The analytics documentation does not state a rate limit specific to the new endpoints beyond a reference to the organization-level limit, and the beta label means parameters and response fields may still change before general availability. Anthropic has also not said whether partner platforms will raise their own request size limits to match the first-party API. For developers, the immediate decision is practical: large inline payloads can now be sent directly where the first-party API is used, while cost reporting pipelines should be migrated deliberately, with the longer data delay built into any alerting logic.

··········

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org