Batch API economics: when the -50% applies

Published 2026-08-14 · Prose last reviewed 2026-11-09 · Figures recomputed nightly from the 2026-11-12 catalogue snapshot

A FinOps guide by OptimNow · prices from the live OptimToken catalogue

A batch tier sells the same model at roughly half the token price, on one condition: you submit a file of requests and get the results back asynchronously. Prompt caching cuts a larger percentage, but only off input tokens. Batch is the discount that applies to output as well, which is why it moves a bill that generation dominates. What it costs instead is latency, and it is not offered on every model. This guide shows where the −50% is real, with numbers from current prices.

What batch pricing is

A batch API is not a faster way to send a batch of requests: it is a slower one. You upload a job, typically a JSONL file of requests. The host, the company that runs the model and sells it by the token, schedules the job on spare capacity. It commits to returning results within a stated window, 24 hours at OpenAI, Anthropic, Google and Mistral. In exchange, both input and output tokens are billed at a discount, typically 50%. The host wins because batch jobs smooth out its GPU utilization; you win if, and only if, nobody is waiting on the answer.

Which workloads qualify

The test is one question, whether anybody needs the result before tomorrow. If not, batch it. Four classes of back-office work pass that test:

• Invoice and document processing: extraction runs on documents that arrived in a queue, not on a person in a chat window.
• Call and meeting summaries: the recording is finished; the summary can land an hour later.
• Evaluations and backfills: regression suites, re-scoring historical data, enrichment of an existing corpus.
• Content generation at volume: product descriptions, translations, tagging.

What never qualifies: anything interactive. Support chat, coding assistants, agent loops that chain on each other's output: a 24-hour ceiling is meaningless there. Of the 8 use-case presets on the pricing table, 3 are marked batch-eligible for this reason: meeting summary, invoice processing and call summary.

Who publishes batch prices

The −50% is published for a minority of the catalogue. Today, 74 of 311 models on OptimToken publish batch rates. A batch tier is not a property of the model, it is a property of the model maker's billing: it clusters in a handful of catalogues and is absent from the rest.

OpenAI, Google, Anthropic and xAI price at least 30% of their own catalogue at a batch rate. Alibaba (2 of 40), Mistral (1 of 20), Meta (1 of 17) and DeepSeek (1 of 14) publish one or two isolated rows. That is a model decision rather than a billing policy, and should not be read as batch support. Zhipu and Moonshot publish none at all, across 25 catalogued models between them. For those model makers the strategy is a low list price rather than a discount tier, which is a reasonable answer to the same problem and a very different one to plan around. If your shortlist sits entirely in that last group, batch is not a lever you have.

When a batch rate exists, it is almost always half

The rate is the predictable part. Of the 74 models publishing a full batch tier, 63 price it at exactly 50% off a 30/70 blend of input and output. The median is 50%. Unlike prompt-cache rates, which spread across the whole range, batch pricing has converged on one number.

The other 11 publish a different rate, and a migration is costed off the published rate, not off the headline. gpt-oss-120b (78%) and DeepSeek V4.1 Flash 1017 (69%) discount batch by more than half. Qwen3.8 Max (0902) (42%), Qwen3.7 Plus (28%), MiniMax M3 (27%), Inkling Small (20%), Grok 4.3 (20%), Muse Glimmer 30B (20%), Grok 4.6 (20%), Grok 4.7 (20%) and gpt-oss-20b (14%) publish a batch rate below the headline. The check is one subtraction against the list price, and it belongs in the migration plan rather than after it.

Worked example: invoice processing at 100K requests/month

Using the Invoice Processing preset (1,500 input + 600 output tokens per request, an async workload), at 100,000 requests per month:

Two lessons. First, when batch rates exist, the saving is real money at volume: no code changes to the prompts, just a different submission path. Second, a cheap model at list price can still undercut an expensive model at batch price. GLM 5.3 Flash is the cheapest model on this preset, leaving out deprecated models and outlier listings, that publishes no batch rate and clears the Standard quality bar, the bar this preset starts from. At the price we quote ($0.0399/M in, $0.0784/M out) it costs 42.1x less than Claude Sonnet 5's batch rate for this extraction-style workload. That quoted price is Relace's rate, for a build quantized to fp4, one of 37 hosts selling the model; the model page lists the others. Batch discounts are an optimisation within a model choice, not a substitute for making the model choice well. Compare the two side by side before assuming the discount settles it.

The caveats that bite in production

• The SLA caps the wait; it makes no promise about how fast a job finishes. Jobs often complete in minutes, but the only guarantee is the window, 24 hours at the 4 model makers named above. Downstream steps must tolerate the worst case.
• No streaming. Results arrive as a completed file. If your pipeline expects token streams, it needs a second, non-streaming path.
• Job size and queue limits. Hosts cap requests per batch and enqueued tokens per model. A month-end invoice spike can hit those caps exactly when you need throughput.
• Results expire. Output files are retained for a limited period: collection must be automated, not manual.
• Batch × cache interaction is murky. Prompt-cache discounts are published for the standard tier; few hosts publish a batch-tier cache-read rate. The after-discounts column on the pricing table assumes the standard cache rate under batch, which is the conservative reading (the formula is here).

When not to bother

Skip batch when the workload is interactive, or when a deadline sits closer than the SLA window. Skip it too when the monthly spend is small. An engineer-day of pipeline work does not pay back on a $40/month job, and at that scale a budget model at list price is the better lever. And never batch-migrate a workload before checking whether a cheaper model would beat the discount outright. The pricing table sorts by cost after discounts per use case for exactly that question. The order of work follows FinOps maturity. A team at Crawl, with no per-workload token bill yet, starts by measuring which jobs are async and what they cost at list. A team at Walk or Run, with that allocation in place, reads the saving off the table above and schedules the migration against it.

Figures on this page come from the 2026-11-12 price snapshot and rebuild nightly.

The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want your own async workloads sized against the batch and cache rates you are entitled to, OptimNow runs that review.

Data snapshot: 2026-11-12 · Compare all models · Cloud compute pricing · All guides