Seventy of the models on OpenRouter ship a second, cheaper version of themselves. Claude Opus 5.5 costs $4 per million input tokens; claude-opus-5.5:batch costs $2. Same model, half price, one condition: you give up the right to an immediate answer. Most people have never used one.
What a batch endpoint is
A batch endpoint takes your request and returns the result later rather than streaming it back now. The provider fills the work into spare capacity, which is worth enough to them that they hand you roughly half the price.
We checked all 70 batch variants currently listed. The median discount is 50% on input and 50% on output, and the majority are exactly half price on both sides. GPT-6 Astra, Sol and Luna, Claude Opus 5.5 and Fable 5.1 all follow the straight 50% rule.
When batch is the obvious choice
The condition for using batch is simple: nobody is sitting there waiting for the answer. That covers more work than people assume.
- Bulk classification and tagging. Ten thousand support tickets categorised overnight. Nobody is watching.
- Document processing pipelines. Summarising or extracting from an archive.
- Evaluation runs. Testing a prompt across hundreds of cases to compare models. This one is especially wasteful to run at full price, because eval runs are large and inherently non-urgent.
- Content backfill. Generating metadata, alt text or descriptions for an existing catalogue.
- Synthetic data generation. Large volumes, no deadline measured in seconds.
The rough test: if you would be happy to start the job and check back after lunch, you are paying double for no reason by using the standard endpoint.
When it is the wrong tool
Anything a person is waiting on. Chat, autocomplete, interactive agents, anything in a request-response cycle with a user at the other end. The saving is irrelevant if the experience is broken.
Also anything where you need to react to the answer to decide the next step. Multi-turn agentic work does not batch well, because each turn depends on the last.
The arithmetic on a real workload
Say you are classifying 50,000 documents, averaging 2,000 input tokens and 200 output tokens each. That is 100 million input tokens and 10 million output tokens.
On GPT-6 Luna at $0.10 and $0.50, that is $10 plus $5, so $15. On the batch variant at half price, $7.50. A small saving in absolute terms because Luna is already cheap.
Run the same job on Claude Opus 5.5 at $4 and $20 and it is $400 plus $200, so $600. Batch takes it to $300. The saving scales with how expensive the model is, which means batch matters most precisely where you were most reluctant to use the good model.
That is the real unlock. Batch pricing is not primarily a way to spend less on work you were already doing. It is a way to run frontier models on work you had written off as too expensive for them.
A note on comparison
None of this tells you which model to run the job on. If you are about to process 50,000 documents, the expensive mistake is not picking the wrong endpoint type; it is committing the whole run to a model that turns out to be worse at your task than one costing a fifth as much.
Test on a sample first, across several models at once, and read the outputs side by side before you commit the budget. That comparison is exactly what Deepest is built for, and it is a lot cheaper than discovering the problem after 50,000 calls.
Frequently Asked Questions
How long does a batch request actually take?
It depends on the provider and on how busy they are, and it is not guaranteed. Providers generally publish a target turnaround window rather than a hard latency figure. Treat it as "hours, not seconds" and design around that rather than around a specific number.
Is the model itself different on a batch endpoint?
No. It is the same model and the same weights. What you are trading is scheduling priority, not quality.
Why would a batch endpoint ever cost more?
We do not have a stated reason from the providers, and we would rather say so than guess. What we can say is that it is measurable right now for two of the 70 variants we checked, and that it is a good argument for reading the actual rate instead of trusting the pattern.
