API Features & Capabilities

Batch API Platform Availability: Where Batches Work and Where They Don't

The 50% batch discount is one of the biggest cost levers in the Claude ecosystem — but Anthropic's Message Batches API only exists on two of the five surfaces. Plan for that before you architect around it.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Anthropic's Message Batches API takes up to 100,000 Messages requests (or 256 MB, whichever comes first) in a single asynchronous job, processes most batches in under an hour with a 24-hour ceiling, and charges 50% of standard prices on both input and output tokens. Results stream back as a .jsonl file, downloadable for 29 days. For classification backlogs, nightly document runs, and evaluation suites, it routinely halves the bill. The catch for enterprises on third-party platforms: it is an Anthropic endpoint (/v1/messages/batches), and it does not exist everywhere Claude does.

The availability picture, July 2026

PlatformMessage Batches APIBatch alternative
Claude API (1P)Available
Claude Platform on AWSAvailable
Amazon BedrockNot availableBedrock's own S3-based batch inference
Google Vertex AINot availableVertex batch prediction (BigQuery/GCS-based, 50% batch pricing)
Microsoft FoundryNot available

Two nuances keep this table honest. First, "not available on Bedrock or Vertex" does not mean those clouds have no batch story — it means they have a different one. AWS offers S3-based batch inference for Claude on Bedrock, and Google offers batch prediction fed from BigQuery or Cloud Storage at 50% batch pricing. These are cloud-native mechanisms with their own job formats, quotas, and result handling; code written against Anthropic's batches endpoint will not run on them unchanged. Second, Microsoft Foundry currently has no Message Batches API at all, even though many other advanced features are available there.

Working within the Anthropic Batches API

Where the endpoint exists (the Claude API and Claude Platform on AWS, which gets typically same-day parity with the first-party API), the mechanics are straightforward: each request in the batch carries a unique custom_id and a params object of ordinary Messages parameters; you poll the batch until processing_status becomes ended, then fetch results_url. Individual results come back as succeeded, errored, canceled, or expired — and only succeeded requests are billed. A few parameters are rejected inside batches, notably stream: true. Since batches can run longer than 5 minutes, Anthropic recommends the 1-hour prompt-cache duration for shared context, and batch rate limits are separate from live-traffic limits (Start tier: 1,000 requests/minute and 200,000 requests in the processing queue).

Operationally, batches are scoped to a Workspace — any API key in the same workspace can view a batch and its results — and a canceled batch may still contain partial results for requests that had already been processed. Requests that expire at the 24-hour mark are simply not billed, which makes the cost model forgiving: you pay only for results you actually receive.

Writing code that degrades gracefully

If your product ships on more than one platform, isolate "how do I run 10,000 prompts cheaply" behind a small interface with three implementations: the Anthropic Batches API, the cloud-native batch mechanism, and a rate-limited synchronous fallback. Route by capability, not by platform name checks scattered through the codebase:

BATCH_STYLE = {"claude_api": "anthropic_batches",
               "claude_platform_aws": "anthropic_batches",
               "bedrock": "cloud_native",     # S3-based batch inference
               "vertex": "cloud_native",      # BigQuery/GCS batch prediction
               "foundry": "sync_fallback"}

def run_bulk(platform, requests):
    style = BATCH_STYLE[platform]
    if style == "anthropic_batches":
        return submit_message_batch(requests)   # /v1/messages/batches
    if style == "cloud_native":
        return submit_cloud_batch(platform, requests)
    return run_sequential_offpeak(requests)

The synchronous fallback deserves real design, not an afterthought: without a batch discount, your levers are prompt caching for the shared prefix, a cheaper model tier where quality allows, and spreading the run over off-peak hours to stay inside rate limits. Budget accordingly — the same workload costs twice as much per token there.

Rule of thumb: decide where bulk workloads run before committing to a platform. If halving bulk-inference cost via Anthropic's Batches API matters and you want to stay inside AWS, Claude Platform on AWS supports it natively; on Bedrock and Vertex, plan for the cloud-native batch pipelines instead.

Where to go next

The batch lifecycle in full is covered in Batch Processing. Platform-specific workarounds get their own guides: the Bedrock batch workaround and the Vertex batch workaround. For the broader picture, see the feature matrix.

Sources