No Endpoints Found for OpenAI Batch Models

Your nightly batch job died and the reason is four words long. If OpenRouter is answering no endpoints found for openai batch requests that ran fine last week, nothing is wrong with your key, your billing or your code. OpenRouter deleted the model IDs. On 26 August 2026 every openai/*:batch slug stopped resolving to a provider, 35 of them in one sweep, and because the slugs still answer metadata requests, nothing looks broken until you send an actual completion.

Key Takeaways:

• 35 OpenAI :batch model IDs left OpenRouter's catalogue on 26 August 2026, together with z-ai/glm-5.2:batch and moonshotai/kimi-k2.7-code:batch
• The base slugs are untouched; openai/gpt-5 still resolves and still serves
• 24 :batch variants survive, all from Anthropic, Google, Thinking Machines, NVIDIA and MiniMax
• Three routes back to a 50% discount: OpenRouter's beta Batch API, the openai/flex endpoint tier, or OpenAI's own Batch API
• Every number here was read from OpenRouter's live /api/v1/models on 28 August 2026

What No Endpoints Found for OpenAI Batch Actually Means

OpenRouter separates two things that most clients collapse into one. There is a model entry, which is a catalogue record with a description, a context length and a price sheet, and there are endpoints, which are 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 right now. 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 to it and OpenRouter has nowhere to route you, so 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: No endpoints found for openai/gpt-4o:batch., No endpoints found for openai/o3:batch. The shape is identical either way, which is why regenerating a key or topping up credit changes nothing. Every variant of no endpoints found for openai batch traffic traces back to the same cause: an empty routing table behind a record that still exists.

35 Model IDs Went Away in a Single Sweep

The removal was not a quiet trim of two or three stale entries. OpenRouter's catalogue went from 422 models to 380 between the 25 August and 26 August 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: gpt-5.6-luna, gpt-5.6-luna-pro, gpt-5.6-terra, gpt-5.6-terra-pro, gpt-5.6-sol, gpt-5.6-sol-pro, gpt-5.5, gpt-5.5-pro, gpt-5.4 and its nano, mini and pro variants, gpt-5.2, gpt-5.2-pro, gpt-5.1, gpt-5, gpt-5-pro, gpt-5-mini, gpt-5-nano, gpt-5-codex, the whole o-series back through o1, and the 4-series down to gpt-3.5-turbo.

The other two were z-ai/glm-5.2:batch and moonshotai/kimi-k2.7-code:batch, which matters if you read the early write-ups: 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, which is 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. If that pattern feels familiar, it is the same failure mode we wrote up when DeepSeek IDs started returning the same 404, 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 advertises 96 models, and openai/gpt-5 resolves to three live routes: OpenAI's own at $1.25 per million input and $10.00 output, Azure at the same numbers, and Azure Sweden Central slightly higher at $1.375 and $11.00.

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.

Route One: The 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, documented in the Batch API Quickstart. It bills batch requests "at 50% of the model's standard per-token pricing", supports a single completion window of 24h, 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. 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.

That 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, and a laptop that sleeps at 6pm is not that somebody. This is the gap MoClaw fills: a hosted cloud AI computer that stays up across the whole window so the poll has a machine to land on, running alongside your existing pipeline rather than replacing it.

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"] }
}

Running three price tiers across two mechanisms is where this stops being a one-line fix and starts being config that needs an owner. Picking the right tier per job, rather than pinning one string and hoping, is part of what MoClaw does for you: model and tier selection handled per task on a machine that already holds your credentials, sitting beside your OpenRouter setup instead of replacing it.

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 28 August. 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.

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, because the sweep took 42 entries and you may be holding more than one.

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, and that scheduling problem is the other half of what MoClaw handles, since a hosted machine keeps a daily diff running on its own clock instead of yours.

There is a broader habit worth building here too. Model IDs are cheap to pin and expensive to lose, and if you have not audited what your token spend is actually routed through lately, a sweep like this is a good prompt to.

FAQ

Why does OpenRouter say no endpoints found for my OpenAI batch model?

Because the model entry still exists but has zero providers attached to it. OpenRouter removed all 35 openai/*:batch slugs from its routing table on 26 August 2026 while leaving the catalogue records in place, so metadata calls succeed and completion calls 404.

Are the OpenAI batch models coming back?

Nothing in OpenRouter's docs or catalogue suggests they will. The :batch suffix is absent from the current Batch API documentation entirely, which reads like the suffix was the legacy mechanism and the beta endpoint is the replacement. OpenAI went first; the surviving 24 variants from other vendors are the ones to watch for the next sweep.

Is GPT-5 itself still available on OpenRouter?

Yes. openai/gpt-5 resolves to three live routes as of 28 August 2026, and OpenRouter's OpenAI page lists 96 models. Only the batch-priced variants were removed.

What is the cheapest way to run OpenAI batch jobs now?

If you are on a GPT-5.6 model, provider: {"only": ["openai/flex"]} gets you the same 50% synchronously. If you are on an older ID, OpenRouter's beta Batch API or OpenAI's direct Batch API both hold the 50%, with a 24-hour window attached.

Did other vendors lose their batch variants too?

Two did: z-ai/glm-5.2:batch and moonshotai/kimi-k2.7-code:batch. Anthropic, Google, Thinking Machines, NVIDIA and MiniMax kept theirs, 24 variants in total.

What to Pin Before the Next OpenRouter Sweep

The lesson from 26 August 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.

So pin both, check both, and put the 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. That is the last thing MoClaw is good for in this story: it is the always-on machine the daily check and the overnight batch both need, sitting next to your existing OpenRouter setup rather than asking you to give it up.