OpenRouter OpenAI Batch Endpoints Down: 3 Ways to Keep the 50% Discount

On August 26, 2026, every openai/*:batch model slug on OpenRouter stopped resolving to a provider — 35 of them, in one silent sweep. The slugs still answer metadata requests, so nothing looks broken until you send an actual completion and get a four-word answer: No endpoints found for openai/gpt-5:batch. If your agency runs nightly batch jobs for client work through OpenRouter, that is your production run failing at 3am with a message that points at your key, your billing, or your code — none of which is the problem.

For AI agencies, this is a pricing-path alert, not a model outage. Batch API pricing is how agencies price bulk client work (evals, data extraction, large content jobs) against realtime work, and the discount route is the difference between quoting a job at a sane margin and eating double the token cost. Here is what actually changed, the three routes that still hold the 50% discount, and how to check every model ID in your config before the next sweep bites you.

What "no endpoints found" actually means

OpenRouter separates two things most clients collapse into one. There is a model entry — a catalogue record with a description, a context length and a price sheet — and there are endpoints — the actual provider routes that can serve a request. Delete the routes and keep the record, and you get a slug that looks alive from the outside.

That is exactly the state openai/gpt-5:batch is in. Ask for its metadata and you get a full record back. Ask for its endpoints and you get an empty array:

GET https://openrouter.ai/api/v1/models/openai/gpt-5:batch/endpoints
{"data":{"id":"openai/gpt-5:batch","name":"OpenAI: GPT-5", ... ,"endpoints":[]}}

Send a completion and OpenRouter has nowhere to route you — the request comes back 404 with "No endpoints found for openai/gpt-5:batch." Swap in whichever slug you were calling and the string changes to match: gpt-4o:batch, o3:batch, all the way back to gpt-3.5-turbo:batch. The shape is identical either way, which is why regenerating a key or topping up credit changes nothing. Every variant of "OpenRouter batch API not working" traffic traces back to the same cause: an empty routing table behind a record that still exists.

The sweep: 35 OpenAI batch models, 42 departures total

The removal was not a quiet trim of two or three stale entries. OpenRouter's catalogue went from 422 models to 380 between the August 25 and August 26 snapshots, and 37 of the 42 departures carried the :batch suffix. Thirty-five of those 37 were OpenAI. The full list runs the length of the vendor's history on the platform:

The other two were z-ai/glm-5.2:batch and moonshotai/kimi-k2.7-code:batch — so this was not an OpenAI-only event, it was mostly one. Anthropic kept 11 batch variants, Google kept 10, and Thinking Machines, NVIDIA and MiniMax kept one each. Call anthropic/claude-opus-5:batch today and it still bills at $2.50 per million input against $5.00 on the standard route — the same clean 50% the OpenAI variants used to give you.

Nobody announced any of this. There was no changelog entry, no deprecation banner on the model pages, no expiration_date field ticking down. The catalogue simply had 42 fewer rows the next morning. The pattern is familiar if you follow this space: it is the same silent-removal failure mode that hit DeepSeek model IDs on OpenRouter earlier, and the same one behind Kimi K2.5's deprecation.

The base models are fine — only the suffix died

Worth separating clearly, because the first instinct on seeing a 404 from openai/gpt-5:batch is to assume GPT-5 is down. It is not. OpenRouter's OpenAI vendor page still advertises 96 models with roughly 2.8 trillion tokens per week of volume through the platform, and openai/gpt-5 resolves to three live routes:

So the outage is narrow and specific: you lost a pricing tier, not a model. Everything you were sending to openai/gpt-5:batch will run today against openai/gpt-5 at exactly double the token cost — which is the fastest possible unblock and the worst possible answer to leave in place. If you do not change anything, your next batch job quietly bills at 2x and your client margin takes the hit.

Route One: OpenRouter's beta Batch API takes the plain slug

The thing the :batch suffix used to do now lives at its own endpoint. OpenRouter ships a Batch API, marked Beta in the docs sidebar, at POST https://openrouter.ai/api/beta/batches. It bills batch requests "at 50% of the model's standard per-token pricing", supports a single completion window of 24 hours, and takes the ordinary model slug rather than a suffixed one:

{
  "endpoint": "/v1/chat/completions",
  "model": "openai/gpt-4o",
  "requests": [
    { "custom_id": "req-0001", "body": { "messages": [{"role": "user", "content": "Hello"}] } }
  ]
}

Two constraints will bite before the pricing does. The Batch API is text-only, so validation rejects any request carrying image, audio, video or file content parts — which rules it out if your batch was doing document extraction or multimodal work. And a successful submission returns 202 Accepted with status: "validating", meaning OpenRouter has queued your batch and nothing more; treating a 202 as completion is the single easiest way to ship a pipeline that silently drops work.

The 24-hour window is the part that quietly changes your infrastructure requirements. Submitting is a single call, but somebody has to poll for results and collect them, potentially most of a day later — a laptop that sleeps at 6pm is not that somebody. Budget the poll as part of the job, or the discount pays for itself in ops time.

Route Two: openai/flex keeps the discount without the wait

The early write-ups missed this part entirely. OpenAI's service tiers are still on OpenRouter; they moved from model slugs to provider endpoint tags. Ask openai/gpt-5.6-sol for its endpoints and three OpenAI routes come back, each with its own price sheet:

Flex is exactly half of standard — the same discount :batch gave you — and it is synchronous. No 24-hour window, no polling, no collection step. For most workloads that were on batch purely for the price rather than the asynchrony, this is a straight upgrade.

The catch is that these tiers require explicit opt-in. OpenRouter's provider routing docs are direct about it: service tier endpoints are not matched by base slugs — they require explicit opt-in. You name the tag in the provider block:

{
  "model": "openai/gpt-5.6-sol",
  "messages": [{"role": "user", "content": "Hello"}],
  "provider": { "only": ["openai/flex"] }
}

The second catch is coverage, and it is the one that will decide this for you. Flex exists on the GPT-5.6 family. It does not exist on openai/gpt-5, openai/gpt-4o, openai/o3 or openai/gpt-4.1 — all of which came back with nothing but standard openai and azure tags when checked on August 28. If your batch pipeline was pinned to an older ID, there is no discounted tier left for it on OpenRouter at all, and your real choice is to move the workload forward a model generation or move it off the platform.

Route Three: OpenAI's own Batch API never went anywhere

OpenAI still runs batching directly, and the terms are unchanged: a 50% cost discount compared to synchronous APIs, a separate pool of higher rate limits that does not draw down your per-model limits, and batches that complete "within 24 hours (and often more quickly)". Per batch you get up to 50,000 requests and a 200MB input file, and you can create up to 2,000 batches an hour.

The cost of going direct is the thing you were on OpenRouter for. You give up the unified key, the fallback routing, and the ability to move a workload to Anthropic or Google by editing a string. If OpenAI is the only vendor in your batch pipeline, take the direct route and stop thinking about it. If you were batching across vendors, splitting one job across two APIs to save 50% on part of it is how you end up with reconciliation code nobody wants to own.

What the three routes cost per task

Run the math on a typical agency batch job — 10K input tokens, 2K output tokens per task, the shape of an eval or extraction workload:

On a 100,000-task monthly delivery, the difference between standard and flex on GPT-5.6 Sol is about $2,000/month in raw token cost ($4,000 vs $2,000) before retries and overhead. That is exactly the line item the AI Agency Pricing Calculator exists to model — and exactly the line that silently doubles if a dead :batch slug falls back to standard pricing without anyone noticing.

How to check any model ID before it bites you

The check takes one call and no key. Ask for a model's endpoints and count the array:

curl -s https://openrouter.ai/api/v1/models/openai/gpt-5:batch/endpoints \
| python3 -c "import json,sys; print(len(json.load(sys.stdin)['data']['endpoints']))"

Zero means the ID is a headstone. Anything else means it routes. Run it against every model string in your config, not only the one that threw — the sweep took 42 entries and you may be holding more than one dead slug. Check at minimum: every :batch variant, every pinned model you quote to clients, and every fallback route in your provider block.

For the recurring version, diff the full /api/v1/models response daily and alert on any slug that disappears or gains a non-null expiration_date. There is no mailing list for this and no changelog to subscribe to; the catalogue is the announcement. Which means the alert only works if it runs every day whether or not you opened your laptop.

What to pin before the next OpenRouter sweep

The lesson from August 26 is not that OpenRouter is unreliable; catalogues change and 42 rows moving in a night is a normal Wednesday for an aggregator carrying 380 models. The lesson is that most of us pin the model and treat the price tier as scenery, when the tier is the part that gets deleted.

openai/gpt-5 survived. openai/gpt-5:batch did not — and the difference between them was six characters and 50% of your bill. A practical checklist for your agency's quoting and tooling:

• Audit every model string in your configs today. Endpoint-count check on each one; anything returning zero gets replaced or flagged before it runs.
• Decide the discount route per model family. GPT-5.6 models → provider: {"only": ["openai/flex"]}. Older models and multi-vendor batch → OpenRouter beta Batch API or OpenAI direct, with the 24-hour poll built into the job.
• Put the tier check on a clock. A tier that vanishes with no notice is only a real problem if you find out from a failed production run at 3am rather than from a diff that ran at 6am.
• Quote with the discount, budget with the fallback. Price client bulk work at the batch rate but keep the standard-rate number in the model so a route change never flips a margin negative silently.

Frequently asked questions

Sources

• MoClaw, "No Endpoints Found for OpenAI Batch Models" (Aug 28, 2026): moclaw.ai
• OpenRouter API, "List models" (/api/v1/models, live read Aug 28, 2026): openrouter.ai
• OpenRouter, OpenAI vendor page (96 models, ~2.8T tokens/wk): openrouter.ai
• OpenRouter, Batch API Quickstart (beta, 50% per-token pricing, 24h window, text-only): openrouter.ai/docs
• OpenRouter, Provider routing docs (service tiers require explicit opt-in): openrouter.ai/docs
• OpenAI, Batch API documentation (50% discount vs synchronous, 50K requests/batch, 24h completion): platform.openai.com

Accuracy note: All catalogue numbers (422→380 models, 35 OpenAI :batch removals, 42 total departures, 24 surviving batch variants, flex tier pricing, GPT-5 route pricing) were read from OpenRouter's live /api/v1/models API on Aug 28, 2026 and documented by MoClaw's investigation the same day; verified again against OpenRouter's OpenAI vendor page. The 50% discount terms for OpenRouter's beta Batch API and OpenAI's direct Batch API are from the respective official docs. Batch pricing and model availability on an aggregator change without notice — re-run the endpoint check before quoting client work.