Is the OpenRouter API reachable right now?
A live probe of openrouter.ai from NetOkay’s edge, and how to tell an OpenRouter problem from an upstream model provider or your own network.
In short: The card below asks openrouter.ai/api/v1/models, a public endpoint that returns 200 without a key. If it answers here, OpenRouter’s front door is open; a stalled model request is then either the upstream provider or your path.
Last updated
Live probe · NetOkay Worker → openrouter.ai
Right now, from NetOkay’s edge
Loading the latest observation of openrouter.ai…
One keyless GET to https://openrouter.ai/api/v1/models, cached for a minute
per Cloudflare location. On a healthy day this probe sees HTTP 200, because the models
list is public.
What this probe shows, and what it does not
The NetOkay Worker resolves openrouter.ai through Cloudflare DNS, opens a TLS connection and sends one GET without credentials, following no redirects. Any HTTP status, including 401, 403 or 405, means the host answered. Several providers refuse keyless automated requests at their edge with a 403 in a few milliseconds; that still proves DNS, TLS and the front door, but it is the provider’s edge answering, not necessarily the API application behind it. The result is one observation from one Cloudflare location, refreshed at most once a minute and never stored.
It cannot see your API key, quota, region, model availability or account state, and it does not travel your network path. A healthy probe and a failing application are compatible; the sections below are for that case.
OpenRouter specifics
-
API host:
openrouter.ai, with the API under/api/v1/. The models list is public, so this probe expects a 200 rather than a 401. -
Streaming: OpenAI‑style server-sent events. While an upstream model is
still working, OpenRouter sends SSE comment lines such as
: OPENROUTER PROCESSINGto keep the connection alive. A client that treats comment lines as data will fail to parse them; a proxy that strips comments removes the keep‑alive. - Three parties: A request passes through your network, OpenRouter, and the upstream provider that serves the model. OpenRouter reports upstream failures inside the response body with the provider’s status code, so a 200 stream can still carry an error object.
- Error codes: 401 invalid key; 402 insufficient credits; 429 rate limit, sometimes passed through from the upstream provider; 502 the chosen provider failed and no fallback succeeded.
- Official status: status.openrouter.ai covers OpenRouter itself; upstream provider incidents are reported on their own status pages.
Reachable here but failing for you?
- Run the homepage checks from the network where the app fails. The 30‑second idle stream shows whether something on your path closes silent connections, which is what a long model pause looks like to a proxy.
- Read the idle result. Closed during the silence points at a proxy, gateway or NAT idle limit under 30 seconds. Start and done arriving together points at response buffering. Both have fixes in the streaming guide.
- Compare environments. If the browser passes and a container, server or agent fails, compare the public IP each one uses, then run the CLI from the failing environment against openrouter.ai.
OpenRouter API status FAQ
My stream shows odd lines starting with a colon. Is that an error?
No. Lines beginning with a colon are SSE comments; OpenRouter uses them as keep‑alives while a provider is still generating. A correct SSE parser ignores them.
The probe is 200 but my model request hangs. What next?
The probe only proves OpenRouter’s host answers. A hang is usually the upstream provider or an idle limit on your path. Run the homepage idle stream check, then try the same model with a different provider preference.
Why is this probe 200 when other providers show 401?
OpenRouter’s models endpoint is public. Other providers require a key for every endpoint, so their healthy answer to a keyless request is 401 or 403.