Blog / Model watch

OpenRouter Provider Uptime: How Much Does It Vary by Model?

2026-10-17cdnping editors8 min read

The same model id on OpenRouter is often served by several inference providers. Switch providers and uptime can differ by ten percentage points or more, and quantization can differ too. In the cdnping snapshot from 2026-10-17, one DeepSeek model had 36 provider endpoints. Most showed 100% uptime over the past day, and the lowest was about 88%. Latency and throughput were all null this time, so this article compares only uptime and quantization, and explains how to compare the other two once data is available.

#Where this data comes from and what it can tell you

The numbers come from the data behind the cdnping model monitoring page. The source is the public OpenRouter API, and the snapshot date is 2026-10-17. A few things to know before reading the tables:

• cdnping only started collecting on 2026-10-17, so this is a cross-section of day one, not long-term statistics.
• up_30m is uptime over the last 30 minutes and up_1d is uptime over the last day. Both values are provided by OpenRouter; cdnping only records them.
• In the snapshot, latency and throughput are null for all 137 endpoint records. Null means no value was obtained in this round, not zero.
• A null uptime does not mean an outage either. Common causes are a newly listed endpoint or too few requests in the window. For example, all 26 endpoints of a new Kimi (Moonshot AI) model in the snapshot have null uptime.

To avoid naming specific model versions in the article, the models below are referred to as Model A to Model D. You can match the full ids on the /en/models page by endpoint count.

#How much does uptime differ across providers for the same model

We picked 4 models that have multiple providers and complete uptime fields. Prices are OpenRouter's model-level list prices (snapshot values, USD per million tokens, input/output). Actual pricing for an individual provider is as shown on OpenRouter.

#Model A: 36 endpoints, lowest at 88%

Of the 36 endpoints, 22 have up_1d of 100% and 8 are below 99%. The table lists every endpoint below 99%, plus a few for reference:

"—" means null in the snapshot. Three things stand out from this table.

Looking only at 30 minutes can mislead you. Of the 8 endpoints with 1-day uptime below 99%, 7 show 100% over 30 minutes. Only CoreWeave is also below full over the 30-minute window.

Different endpoints of the same provider behave differently. DeepInfra's standard endpoint is at 100% while its flex endpoint is at 96.68%. Fireworks' default endpoint is at 88.82% while its /us endpoint is at 99.10%. Choose at the endpoint level; the provider name alone is not enough.

This day's data does not show "lower precision means less stable". Of the 36 endpoints, 17 are fp8, 3 are fp4, 1 is mxfp4, and 15 are unlabeled. Among the 4 endpoints below 90% for 1 day, there are fp8, fp4 and unlabeled ones.

#Model B: the most varied quantization levels

Four more endpoints, StreamLake, Venice, Novita and Phala, have up_1d of 100 and a null up_30m; they are omitted from the table. Eight of the 13 endpoints have a null 30-minute uptime, which means few requests were routed to them in that period, so the 100% behind them rests on a small sample.

The maker's own endpoint is labeled int4, while some third parties are labeled fp8. A higher labeled precision does not mean the output matches the official endpoint. Rely on your own evaluation.

#Model C and Model D: different entry points from the same company

All 6 endpoints for Model C are served by Google itself. They differ in entry point (AI Studio or Vertex), region and service tier (flex, priority). On this day, the default AI Studio endpoint was actually the lowest.

Model D's 8 endpoints (Anthropic, Amazon Bedrock, Google Vertex global/us/europe, Azure global/us, and Claude Platform on AWS) all show 100 for both up_30m and up_1d, and none is labeled with a quantization. Closed-source models are hosted by the original vendor or by cloud providers, so differences between endpoints are mainly region, compliance and quota, not the weights themselves.

#How to read these numbers

Uptime is the success rate from OpenRouter's point of view: how many of the requests OpenRouter sent to that provider succeeded. How smoothly you can reach OpenRouter from your own network is a separate leg of the path and has to be tested separately.

A 1-day figure below 90% does not necessarily mean instability all day. If failures were concentrated in one window, two or three hours of trouble is enough to pull the 1-day uptime down to around 88%. Telling a concentrated outage from persistent flakiness requires a longer history, which cdnping can only answer after collecting several weeks of data.

The quantization field only describes the deployment. fp8, fp4, int4 and mxfp4 are weight precisions reported by the provider, and unknown means it was not labeled. Lower precision generally saves GPU memory and raises throughput, but whether it affects your task can only be found by testing. If you suspect a model has gotten "dumber", the /en/models page includes links to third-party evaluation projects; cdnping does not republish their data.

The same list price does not mean the same cost. The tables show model-level list prices; under one model id, different endpoints may differ in pricing, cache support and maximum output length. For batch jobs, also count retries on failure: for an endpoint with 88% 1-day uptime, however low the unit price, the extra tokens and waiting time from retries are also a cost.

Wait until the /en/models page has latency and throughput values before comparing them. At that point, look at time to first token and tokens per second separately: interactive completions care more about the former, batch generation more about the latter.

#How to pick a provider for your project

#Step 1: pull all endpoints for a model

OpenRouter provides a public endpoint-listing API; field names follow the official OpenRouter documentation. Replace author/model-name below with the model id you found on the /en/models page:

MODEL="author/model-name"
curl -s "https://openrouter.ai/api/v1/models/${MODEL}/endpoints" \
  | jq '.data.endpoints[] | {provider: .provider_name, tag: .tag, quant: .quantization, up_30m: .uptime_last_30m, ctx: .context_length}'

Once you have the output, cross-check it against the cdnping /en/models page to confirm you are looking at the same set of endpoints for the same model id.

#Step 2: filter with a checklist

#Step 3: state your provider preferences in the request

OpenRouter lets you specify provider order, quantization range and whether fallbacks are allowed in the provider field of the request body. Here is an example:

{
  "model": "author/model-name",
  "messages": [{"role": "user", "content": "ping"}],
  "provider": {
    "order": ["deepseek", "deepinfra"],
    "quantizations": ["fp8"],
    "allow_fallbacks": true
  }
}

The provider names are only examples; valid values are as given in the official OpenRouter documentation. We recommend keeping allow_fallbacks on. In the data above, a single endpoint dropping below 90% within a day is not rare, so keeping a few backup endpoints is safer than betting on one.

#Step 4: test your own side of the path

The uptime figures above all cover the leg from OpenRouter to the provider. For the leg from your network to OpenRouter, use the cdnping online speed test page to measure OpenRouter's first-connection time (including DNS and the TLS handshake) and round-trip time. When something looks wrong, first check /en/status/openrouter and /en/down/openrouter to see whether the problem is on the platform side.

If you suspect your local network, a proxy or DNS, use the IP and environment check to see your exit IP, mainland China split-routing status (whether traffic to China-based sites goes direct or through the proxy), DNS leaks and WebRTC leaks. For background, see split tunneling explained and DNS and WebRTC leaks. The check page can generate a watermarked result image, and you can choose to hide your IP before generating it, which makes it easy to paste into a ticket or group chat for joint troubleshooting. When using any overseas AI service, comply with the relevant terms of service and local regulations.

#Don't want to maintain provider order yourself

You can also hand it to an aggregation gateway. AGI Plan is the team behind cdnping; the two are run by the same team. AGI Plan schedules requests by capability group and publishes hourly, per-capability-group counts of successful and failed requests at https://agiplan.dev/api/status/requests?month=YYYY-MM, with no login required. The cdnping /en/status/agiplan page mirrors it. Its uptime is calculated from real requests, and only 5xx responses count as platform failures, which is a different basis from the OpenRouter endpoint uptime above, so the two cannot be compared directly. For plans and pricing, see agiplan.dev/pricing.

#What to look at next

• Bookmark /en/models and check back in a week on the Model A endpoints that were below 99%, to judge whether it was a one-off outage or persistent instability. Endpoints being listed or delisted, price changes and quantization changes are recorded automatically on the /en/models page.
• Subscribe to the weekly stability report, generated automatically every Monday.
• For data sources and collection methods, see Methodology. For where API latency comes from when calling AI APIs from China, see this explainer.