[Feature]: Support OpenRouter’s native Batch API
Prerequisites
- I have searched existing issues and discussions to avoid duplicates
Problem to solve
OpenRouter provides an asynchronous Batch API, but Bifrost’s OpenRouter provider currently returns unsupported_operation for batch requests.
Users processing offline workloads through OpenRouter must call it outside Bifrost or configure separate direct-provider integrations. This prevents them from using the same gateway controls, logging, and cost tracking as their synchronous requests.
Bifrost’s OpenRouter documentation also still describes Batch as unavailable upstream, although OpenRouter now documents it.
Proposed solution
Extend the existing OpenRouter provider to support its native Batch API at /api/v1/batches, using Bifrost’s existing batch interfaces where compatible.
The integration should:
- Support submission, listing, status retrieval, result retrieval, and terminal-batch deletion.
- Reuse the existing inline-request representation rather than require an uploaded input file.
- Preserve
custom_id, lifecycle status, request counts, per-request responses and errors, and supported provider-selection options. - Use existing OpenRouter credentials while preserving Bifrost’s virtual-key access boundaries. OpenRouter’s batch listing is workspace-scoped, so upstream visibility alone should not determine which batches a Bifrost caller can access.
- Integrate asynchronous usage and cost settlement without charging again when callers poll or retrieve results repeatedly.
- Update the provider documentation and add coverage for validation failures, mixed successful/failed results, and accounting.
OpenRouter currently supports Chat Completions, Responses, Anthropic Messages, and embeddings request shapes. Each batch uses one model and one request shape.
Alternatives considered
- Call OpenRouter directly: works, but requires an application-side exception to the gateway.
- Use direct-provider Batch APIs through Bifrost: useful where configured, but requires separate provider integrations rather than the existing OpenRouter account.
- Send concurrent synchronous requests: does not provide the asynchronous Batch API or its batch pricing.
Area(s)
Core (Go), Framework, Transports (HTTP), Plugins, Docs
Additional context
Important differences from file-based OpenAI batches:
- Requests are submitted inline as
{ custom_id, body }items. - Creation returns
202 Acceptedbefore asynchronous validation finishes. - Completed results are returned inline when retrieving the batch; there is no separate upstream results-download endpoint.
- The documented completion window is
24h. - Terminal deletion is not cancellation.
usage.costreports OpenRouter’s charge. For BYOK batches, it covers only OpenRouter’s fee—not inference billed directly by the provider.- OpenRouter requires batch metadata fields to appear before
requestsin the serialized JSON body.
References:
Is OpenRouter Batch support already planned, or would an implementation using the existing batch interfaces be welcome?
Source: maximhq/bifrost