# OpenRouter Batch API: Half-Price Inference Has a Deadline, a Data Trail, and a Catch
**Plutonous** | September 22, 2026 | 6 min read
> A worked guide to OpenRouter Batch API costs, deadlines, ambiguous submissions, result reconciliation and data retention.
Tags: OpenRouter, Batch API, AI Inference, LLM Economics, Data Retention, Developer Tools, AI Operations, API Strategy
---
**TL;DR: OpenRouter launched Batch on September 22 with typically 50% token pricing, 70+ models and a 24-hour window.[1] Our hypothetical $1,280 workload falls to $640 before recovery costs. The important decision is whether the deadline and reconciliation plan survive an incomplete job.**
Cheap inference becomes expensive when its output arrives after the business decision. Batch processing puts that trade-off directly into a purchasing decision: which jobs can wait, and what will the organization do when waiting fails?
The real story isn't the percentage discount. It is the separation of interactive work from background production. Document labels, evaluation runs and backlog summaries are reasonable candidates. A customer waiting for a checkout response is buying a different service.
*Cover: generated editorial artwork showing queued work and a deadline clock. It does not depict measured throughput.*
### Why This Matters Now
A lower unit price justifies a pilot, not an automatic migration. Start with a workload whose outputs can be checked before they affect customers, whose completion time is flexible, and whose failure can be contained.
## The Budget: Calculate the Recovery Reserve First
Assume 400 million input tokens at $2 per million and 60 million output tokens at $8 per million. These are hypothetical rates, not a quote for a named model. Assume an exact 50% batch discount for this example.
| Cost | Standard | Batch assumption |
| --- | ---: | ---: |
| Input: 400 × $2 | $800 | $400 |
| Output: 60 × $8 | $480 | $240 |
| Total | **$1,280** | **$640** |
Suppose 3% of the workload needs a full-price recovery attempt. If those rows have the same average token cost as the whole workload, recovery adds $38.40: $1,280 × 0.03. Total spending becomes $678.40, leaving $601.60 saved. That is a sensitivity calculation, not a predicted error rate. Longer failed rows, repeated attempts and operational labor change the outcome.
With BYOK, the provider bills inference separately from OpenRouter's fee.[3] Reconcile both bills before declaring savings. A dashboard showing only one side of the transaction is an incomplete cost model.
Caching deserves its own experiment. OpenRouter documents that Anthropic batch requests may run concurrently and out of order, so one row's cache write is not guaranteed to benefit another row in the same batch.[6] Model the budget without assumed cache hits first. Add observed savings only after a representative run. Our [prompt-caching cost guide](/news/claude-prompt-caching-cost-break-even) explains the separate break-even question.
## The Deadline: Reserve Time for a Different Recovery Path
OpenRouter reports 230,000+ completed beta batches: median 7 minutes, P90 1 hour, P99 10.3 hours. This vendor sample is not an SLA or a success-rate denominator. Undisclosed workload and hardware conditions prevent a normalized inference-speed comparison.[1]
For a report due September 24 at 09:00 UTC, submitting September 23 at 06:00 UTC leaves 27 hours. Allocate 24 hours to the original attempt and three hours to recovery. A second full batch window cannot fit inside that reserve. The fallback must be something the team has measured within three hours: bounded synchronous work, a reduced report, or an explicitly missed deadline.
Write that choice before launch. Otherwise an operator under pressure will invent it with production data. Track acceptance time, terminal time, validated outputs, unresolved inputs and money spent on recovery. Compare complete jobs against their business deadline, not merely against an appealing median.
## The Recovery: Separate Known Failures from Unknown Outcomes
The quickstart returns a result array only for `completed` batches; `in_progress`, `failed`, `expired` and `cancelled` return `results: null`. List responses contain metadata, not row results. Counts cannot identify individual outcomes.[2]
That boundary demands two different operating procedures. The following is our recommended application design, not an API guarantee.
| Evidence available | Application action |
| --- | --- |
| Completed batch with result rows | Match `custom_id` to the frozen input ledger; validate each output and classify errors. |
| Known batch ID, no result rows | Keep the input set unresolved; do not infer identities from aggregate counts. |
| Submission timed out without an ID | Record an ambiguous attempt; investigate before replaying it. |
| Validated result already applied | Use an application idempotency key or upsert rule to prevent duplicate business writes. |
For a completed 10,000-row job, imagine 9,700 usable outputs and 300 identified errors. A new attempt can contain those 300 rows after input problems are corrected and the budget permits it. This example requires actual row evidence. It does not apply when all you possess is a count of 9,700.
If a POST times out before returning an ID, the documented list response does not provide row identities that prove which submission was accepted. No documented idempotency contract resolves that ambiguity. Do not present a blind replay as safe. Preserve the request fingerprint, timestamps and local attempt log for investigation; if the business elects to retry anyway, explicitly accept potential duplicate inference cost.
Correlation and business idempotency solve different problems. A stable identifier helps match an answer to an input. A uniqueness constraint on the downstream write prevents two accepted answers from sending two customer notifications. Neither makes the inference attempt itself exactly once.
## The Data Trail: Routing Policy and Stored Artifacts Are Separate
The launch specifies 30-day storage for inputs and results unless deleted.[1] The quickstart allows deletion of terminal batches; billing, generation and audit records remain.[2]
This matters because OpenRouter's general data page describes opt-in prompt logging and separately retained request metadata.[4] Use the feature-specific batch policy for the artifacts created by this workflow. Treat a general privacy headline as the beginning of review, not the complete storage inventory.
ZDR controls concern eligible provider inference endpoints; they do not automatically cover enabled third-party tools.[5] Provider routing also exposes allowlists and data-policy controls.[7] Record the approved route and the artifact owner separately. Choosing an acceptable inference provider does not answer who removes the batch output after downstream ingestion.
A useful inventory has four entries: original application data, submitted payload, returned result and accounting metadata. Give each an owner and a retention rule. Minimize identifiers before submission, persist only what the business needs, and record successful deletion without retaining another full copy in a debug log. Our [OpenRouter privacy and fallback guide](/news/openrouter-free-model-limits-privacy-fallbacks) covers the wider routing decision.
## The Purchase Decision: Compare Operating Systems, Not Discounts
Anthropic also offers a direct Message Batches API with a 50% discount.[8] That establishes an alternative, not equivalence in result handling, storage or service guarantees. For a single-provider workload, compare the direct integration with the router on the same inputs and acceptance criteria.
Run a bounded pilot with a frozen corpus. Keep prompts, model versions, output limits and quality checks consistent. Measure usable outputs by deadline and total recovery spending. Include integration maintenance in the decision: one shared route can be valuable even when the headline discount is available elsewhere.
### The Key Insight: Savings Need an Owner
Assign responsibility for the deadline, ambiguous submissions, downstream writes and artifact deletion. A token discount cannot compensate for an operating procedure that nobody owns.
The uncomfortable truth is that the best batch workload is not simply the biggest one. It is the one whose delay is affordable and whose uncertainty is manageable. Buy the discount only after defining what a completed business job means.
## Sources & References
1. [Batch API launch](https://openrouter.ai/blog/announcements/batch-api/)
2. [Batch API Quickstart](https://openrouter.ai/docs/batch-quickstart)
3. [Bring Your Own Key](https://openrouter.ai/docs/guides/overview/auth/byok)
4. [Data Collection](https://openrouter.ai/docs/guides/privacy/data-collection)
5. [Zero Data Retention](https://openrouter.ai/docs/guides/features/zdr)
6. [Prompt Caching](https://openrouter.ai/docs/guides/best-practices/prompt-caching)
7. [Provider Routing](https://openrouter.ai/docs/guides/routing/provider-selection)
8. [Batch processing](https://platform.claude.com/docs/en/build-with-claude/batch-processing)
*Last updated: September 22, 2026*
---
*Source: [LLM Rumors](https://www.llmrumors.com/news/openrouter-batch-api-cost-deadlines-retention)*