OpenRouter Adds Batch API With Half-Price AI Requests for Non-Urgent Work

The new endpoint is designed for work that can wait, but its beta results suggest the practical delay may often be far shorter than its 24-hour maximum.

By 3 min read
OpenRouter Adds Batch API With Half-Price AI Requests for Non-Urgent Work
OpenRouter Adds Batch API With Half-Price AI Requests for Non-Urgent Work

Listen to this story

The audio brief

About 1:25
0:001:25
Read transcript
OpenRouter has launched a Batch API that can cut AI request costs by half or more, as long as the work does not need to finish immediately. Developers can queue jobs for completion within 24 hours, making the service a fit for labeling datasets, generating embeddings for older material, scoring evaluations, summarizing ticket backlogs, or running one prompt across thousands of rows. The deadline is a ceiling, not a promise of round-the-clock delay. In a two-week beta covering more than 230,000 batches, the median turnaround was seven minutes, and 90% finished within an hour. But the slowest one percent took as long as 10.3 hours, so teams still need to design around variability rather than assume instant results. Pricing depends on the model, with more than 70 models available, and web-search calls still use standard rates. Each batch runs through a single provider. OpenRouter chooses the cheapest eligible batch endpoint after applying allowlists, data policies, and bring-your-own-key settings. The API supports chat completions, responses, messages, and embeddings, with results returned independently so one failed row does not sink the whole batch. Inputs and results are retained for 30 days unless deleted, while images and files need public URLs. Audio, video, and web-search are excluded. The key constraint to watch is whether the savings justify giving up predictable timing, especially for larger or time-sensitive queues.

Story brief

3 key points

OpenRouter has introduced a Batch API for queue-based AI workloads, letting developers trade guaranteed immediacy for completion within 24 hours and model-dependent discounts of 50% or more. The beta suggests many jobs may finish much sooner: 90% completed within an hour, while the 99th percentile reached 10.3 hours across more than 230,000 batches. The service supports several text and embedding request formats,...

  1. 01

    More than 230,000 beta batches were completed; median turnaround was seven minutes and 90% finished within one hour.

  2. 02

    The 24-hour window is a ceiling, not a latency guarantee; the beta’s 99th-percentile completion time was 10.3 hours.

  3. 03

    Each batch runs on one provider, with routing shaped by cost, allowlists, data policies, and bring-your-own-key settings.

OpenRouter has launched a Batch API that turns patience into a pricing lever. Developers can submit large or non-urgent AI jobs for completion within a 24-hour window and generally pay 50% or less of normal per-token rates, across more than 70 models.

The offer is not meant for an app waiting on a user. It is for work that can be moved out of the immediate request path: labeling a corpus, generating embeddings for older material, scoring an evaluation set, summarizing a ticket backlog, or applying one prompt across thousands of rows overnight. The trade is explicit: lower token prices in exchange for a provider-controlled completion window.

A lower bill, with timing no longer guaranteed

That distinction changes the product from a simple cheaper endpoint into a scheduling choice. A normal request is valuable when an answer must arrive now; a batch is valuable when a team can separate the cost of processing from the moment someone needs the result. OpenRouter says the discount varies by model, while web-search calls continue to bill at standard rates.

Fast in beta is not the same as immediate

The early results make the 24-hour ceiling look conservative for many jobs, but they also show why this is not a latency promise. OpenRouter’s two-week beta data puts the 99th-percentile completion time at 10.3 hours. Submission time mattered more than request count, according to the company: batches sent between 5 a.m. and noon Pacific were significantly slower, and the slowest tenth took two to 4.5 hours.

Batch size still has an effect at the margins. OpenRouter says a single-request batch finished in five to 11 minutes depending on the hour, while batches with 1,000 or more requests finished in 12 to 21 minutes. Its slowest tenth of batches larger than 100 requests, submitted from midnight to noon Pacific, took as long as 6.8 hours.

Broad request support, narrower media support

The API is built to fit several existing OpenRouter request shapes rather than impose a new task format. It supports chat completions, responses, messages and embeddings, and results return independently, so failed rows do not cause an entire batch to fail.

Operating limits to account for

  • Each batch runs on one provider. By default, OpenRouter selects the cheapest eligible batch endpoint after applying provider allowlists, data-policy settings and bring-your-own-key settings.
  • Inputs and results remain available for 30 days unless the customer deletes the batch.
  • Images and files must use public URLs. Audio, video and OpenRouter’s web-search plugin are unavailable in batch jobs.

Those boundaries narrow the best fit. The Batch API can reduce costs for text-heavy work with a known queue and a flexible deadline. It is less suited to tasks needing private file uploads, media processing, web-search calls at batch pricing, or a predictable response time. For teams that can wait, the relevant comparison is not between models alone, but between paying for immediacy and paying for volume.

Sources

  1. openrouter.aiOpenRouter Batch API: half-price inference by bundling requests — OpenRouter Blog

Loading discussion...

YOUR READING SPACE

Notifications