Skip to main content
Total latency = slowest single request. Batch 20 prompts, wait as long as 1.
POST /api/v1/batch
Response
cost_cents on each result is that item’s real metered charge for its actual token usage — not a fixed per-model number, so the same prompt on the same model can bill slightly differently between runs. Results come back in request order, tagged by index. Each also carries tokens and (for auto) a routing object.

Parameters

Billing: each successful request bills its exact metered token usage at that model’s $/MTok rate; failures aren’t charged. An estimated maximum for the whole batch is held against your balance up front and the unused portion refunds once every item completes.
Fallback chains ("a>b>c") aren’t valid model values here and are rejected up front with a validation_error. Ensemble models (ensemble, ensemble-quality) do pass validation — they’re valid model IDs elsewhere in the API — but batch has no ensemble execution path, so each one fails at runtime as a per-item error (success: false) rather than a clean validation rejection. You aren’t charged for it, but don’t rely on ensembles working inside /batch.

Streaming results

Set stream: true to get each result the moment it finishes instead of waiting for the slowest one — useful when a couple of the 20 prompts are much slower than the rest:
POST /api/v1/batch (stream)
The response is text/event-stream: one type: "result" event per completed request (in whatever order they finish, tagged by index), followed by one final type: "summary" event and a [DONE] sentinel:
Billing works the same as non-streaming: the full estimate is held up front and the unused portion is refunded once the summary event fires.

The classic use case — classification at scale

Handle partial failures per item:

Limits

Batching identical work at the lowest price? Pair with auto-cheap per request, or estimate the total first — estimates are free.