# Why a batch has one provider even on a multi-provider gateway

OpenRouter routes each accepted batch through one eligible provider. Per-request results improve outcome handling but do not make every row an independent provider-routing decision.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-22
Original announcement: https://openrouter.ai/blog/announcements/batch-api/
Canonical URL: https://retrivium.ai/retrospectives/retro-openrouter-batch-single-provider/

OpenRouter's Batch API resolves a batch to one provider after applying the caller's constraints. This makes the batch the routing unit, even though results return for individual requests. A multi-provider gateway does not imply that every row of an accepted asynchronous job independently switches between providers.

## The announced routing unit is the batch

The [September 22, 2026 launch](https://openrouter.ai/blog/announcements/batch-api/) says each batch executes on a single provider. The default choice uses the cheapest eligible batch endpoint after provider, data-policy and BYOK settings are applied.

These are two distinct decisions: constraints define eligible candidates, and selection chooses one for the job. A globally available model name does not establish that every provider route supports the same batch product or remains eligible under the caller's policy.

## Individual results do not redefine provider selection

The announcement describes per-request results, so problematic rows need not invalidate every other result. That result granularity is useful to applications handling a large collection of work.

It should not be confused with per-row routing. The caller can inspect outcomes individually while the accepted batch retains a single execution provider. Treating those units as identical would produce the wrong failure and retry expectations.

## Earlier gateway controls supplied the policy context

[Workspaces on April 22, 2026](https://openrouter.ai/blog/announcements/introducing-workspaces/) established scoped access and policy. [Response caching on April 30](https://openrouter.ai/blog/announcements/response-caching/) established another gateway optimization around repeated requests. Neither earlier feature determines the execution unit of a later batch.

Our causal hypothesis is that asynchronous scheduling benefits from a clear job-level execution owner. Binding the job to an eligible provider gives the scheduling window and result lifecycle a stable object. This is an interpretation of the design, not a disclosed account of internal implementation choices.

## Keep an execution-unit ledger

An illustrative ledger can prevent application assumptions from crossing units:

| Unit | Decision or evidence attached to it |
| --- | --- |
| Submission | Caller constraints and selected model |
| Accepted batch | The provider executing the job |
| Individual request | Its result or failure outcome |
| Later submission | A new routing decision under its applicable settings |

The last row matters when an application chooses to submit unfinished work again. A later job is another decision, not evidence that the original accepted batch silently changed its provider. The caller should preserve the relationship between its work items and the jobs that attempted them.

## Evaluate the job contract at its real scope

The historical addition is asynchronous multi-request work within a multi-provider platform. Its routing flexibility operates before acceptance, while per-request results support application handling after execution.

[Provider routing](/journal/openrouter-provider-routing/) explains eligibility and selection. [Routing and fallback](/journal/inference-routing-fallback/) explains why execution roles need explicit boundaries. The Batch API is most accurately understood by keeping the batch, the provider and the individual result as separate linked objects.