---
title: "How to Choose an LLM API: 3 Access Paths and a 6-Factor Checklist"
description: "How to choose an LLM API: compare official, cloud-hosted and gateway access across six factors, with test commands, public data sources and a decision flow."
url: https://cdnping.org/en/blog/llm-api-selection-checklist
language: en
published: 2026-10-24
category: "Developer tools"
tags: ["LLM API","API selection","uptime","latency testing","API gateway"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# How to Choose an LLM API: 3 Access Paths and a 6-Factor Checklist

To choose an LLM API, don't start with model leaderboards. Start with the access path: go direct to the vendor, use a cloud platform's hosted service, or use an aggregation gateway. Once the path is set, check six factors one by one: uptime and transparency, latency, billing, data policy, payment and settlement, and integration cost. Every item should be verifiable with public data or a command you run yourself, not with a score someone else hands you.

This article doesn't name a winner. Many "best provider" posts don't publish their methodology, so their conclusions can't be reproduced. Each cell below describes how to judge, and any numbers come only from cdnping and public endpoints, with the window stated. For the basic concepts behind the three paths, see [Official API, cloud-hosted, or gateway: how to choose an access method](/en/blog/official-api-vs-cloud-vs-gateway). This article focuses on how to verify.

## What are the three access paths?

- **Direct to the vendor**: you register and pay the model vendor, and requests go straight to its domain, for example `api.openai.com`, `api.anthropic.com` or `api.deepseek.com`.
- **Cloud-hosted**: you call the model through a cloud platform's account and billing. The same model may have several hosts and several regions. In the OpenRouter public data that the cdnping [model monitor](/en/models) reads, one model often lists both the vendor itself and several cloud platforms as inference providers.
- **Aggregation gateway**: one endpoint and one balance, with multiple upstreams behind it. Switching models only means changing a parameter. The cost is an extra hop between you and the model, so you need to check the gateway's uptime methodology, billing and data policy as well.

Developers in China have to pick among all three in practice, while the English-language selection guides you usually find mostly compare a few cloud platforms and don't address this choice.

## The selection matrix: how to judge each cell

Each cell says where to look and what to look for, so you can tick items off as you go.

| Factor | Direct to vendor | Cloud-hosted | Aggregation gateway |
|---|---|---|---|
| Uptime and transparency | Check the vendor's status page for incident history and how components are split | Check the cloud platform's status page and the service health page for your region | Check whether it publishes uptime computed from real requests, and whether the methodology is stated |
| Latency | Measure first connect and round trip to the vendor's domain | Measure latency to the entry point of your chosen region | Measure latency to the gateway entry point, then add the gateway-to-upstream leg |
| Billing | Vendor price page, per token; note that input and output are priced separately | Cloud price page; may differ from the vendor's price, and may include committed-use discounts | Subscription quota or pay-as-you-go; work out how the metering unit converts to tokens |
| Data policy | Vendor's API data usage terms and retention period | Cloud platform's data processing agreement and regional data residency | Whether data is stored, used for training or resold, and whether there is a written statement |
| Payment and settlement | Overseas vendors usually require a payment method that works outside China | Goes through the cloud account system; you can usually sign an enterprise contract and get invoices | Check currency, payment methods and whether invoices are available |
| Integration cost | Each vendor has its own SDK and API format | Authentication is mostly the cloud platform's own signing scheme | Whether it is compatible with the OpenAI / Anthropic API format, and whether your existing tools work by changing only the base URL |

A few notes:

1. Transparency matters more than any single percentage. A "99.9%" is not comparable unless it says whether the denominator is probe requests or real requests, and which errors count as platform failures. To define your own methodology and write a script, see [Measuring AI API uptime yourself: metrics, scripts and methodology](/en/blog/measure-ai-api-uptime-yourself).
2. Comparing only the price per million tokens will give you the wrong answer. The gap between input and output prices, cache-hit prices, long-context surcharges and metering-unit conversion all change the result. See [How to compare LLM API prices](/en/blog/llm-api-pricing-how-to-compare).
3. Read the data policy in the original text. Focus on whether data is retained, for how long, and whether it is used for training. For the method, see [Can your code and conversations be seen when you use a third-party AI API?](/en/blog/ai-api-data-privacy-policy)

## How do you measure latency in a way that counts?

Latency is the easiest metric to misread, because it depends heavily on where you measure from. Start with a set of cdnping edge probe data.

Source: cdnping [API status](/en/status), probing each official API entry point from a Cloudflare Denver (DEN) node. Window: 2026-10-17 UTC 08:40 to 10:05, 242 probe records in total. cdnping only began collecting on 2026-10-17, so this is a very short sample and does not represent long-term performance.

| API entry point | p50 (ms) | p95 (ms) | Uptime in window |
|---|---|---|---|
| api.anthropic.com | 73 | 84 | 100% |
| generativelanguage.googleapis.com | 69 | 89 | 100% |
| api.openai.com | 96 | 194 | 100% |
| openrouter.ai | 54 | 83 | 100% |
| api.deepseek.com | 353 | 414 | 100% |
| dashscope.aliyuncs.com | 615 | 1152 | 100% |
| api.moonshot.cn | 375 | 1125 | 94.4% |

This table mostly reflects where the probe sits. From a US node, overseas vendor entry points take about a hundred milliseconds and entry points of platforms in China take a few hundred. From a network inside China the result may be exactly the reverse. So it can't answer "which one should I pick". It only shows that you should measure latency from your own network and from where your servers run.

### Hands-on: measure your own latency in three steps

1. Open the cdnping [online speed test](/en/). It runs in the browser and measures "first connect" (including DNS and the TLS handshake) and "round trip" (the median of 3 requests over a reused connection) for 15 AI API entry points. Run it once on the network where you write code, and once in the data center where you deploy.
2. On the server, use curl to break out the time of each phase, replacing the hostnames with your candidate entry points:

   ```bash
   for host in api.openai.com api.anthropic.com api.deepseek.com; do
     curl -o /dev/null -s -w "$host dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n" \
       "https://$host/"
   done
   ```

   This requests the root path. The status code returned doesn't matter, because what you are looking at is connection setup and time to first byte. Run each entry point 10 or more times and take the median, since a single result means little.
3. To compare real generation speed, you also need time to first token (TTFT), which requires a streaming request with an API key. For what first connect, gateway round trip and TTFT each tell you, see [AI API latency breakdown: connection setup, gateway round trip and time to first token](/en/blog/api-latency-connect-rtt-ttft).

For aggregation gateways and cloud-hosted models: what you measure is the leg from you to the entry point. The leg from the entry point to the upstream model can't be measured directly, and you can only observe it indirectly through TTFT.

## Where do you verify uptime?

Each of the three paths is verified differently:

- **Direct to the vendor**: check the vendor's status page. cdnping syncs incidents from some vendors' status pages. According to sync records since 2026-09-17, the OpenAI status page has 4 major and 19 minor incidents, and Anthropic has 6 major and 1 minor. These numbers only show how many incidents the vendor published. Each vendor grades incident severity by its own standard, so they can't be ranked directly against each other. For how to read incident levels and components, see [How to read the OpenAI and Claude status pages](/en/blog/how-to-read-ai-status-pages).
- **Cloud-hosted**: uptime for the same model can differ across hosts. The [model monitor](/en/models) shows 30-minute and 1-day uptime for each inference provider, along with quantization precision (fp8, fp4 and so on). For differences between providers, see [Same model, different OpenRouter provider: how much can uptime differ?](/en/blog/same-model-different-providers-uptime) For why quantization differences deserve attention, see [Did the model get dumber, or did the provider change?](/en/blog/llm-quantization-fp8-fp4-providers)
- **Aggregation gateway**: ask for data you can check. Take AGI Plan as an example (AGI Plan is a commercial partner of cdnping). It publishes hourly success and failure counts per capability group at `https://agiplan.dev/api/status/requests?month=YYYY-MM`, with no login required. The methodology is "successes / (successes + failures caused by the platform itself)", and only 5xx responses count as platform failures. cdnping's [AGI Plan status page](/en/status/agiplan) mirrors it. In the 30-day data up to 2026-10-17, uptime across capability groups ranged from about 81.7% to 98.0%, with the high-speed lightweight group the lowest. You can pull it down and check it yourself:

```bash
curl -s "https://agiplan.dev/api/status/requests?month=2026-10&format=json" | head -c 600
```

You can ask any gateway the same three questions: what is the denominator, which errors count as the platform's, and can the raw data be downloaded. If it can't answer, its uptime figure can't be used for comparison.

## What should you watch for on payment, compliance and regional restrictions?

- Official APIs from overseas vendors usually require a payment method that works outside China, and some services restrict certain regions. Such restrictions are governed by the vendor's official policy. Follow the terms of service and local regulations, and don't try to get around them.
- Teams that need contracts and invoices should look first at cloud-hosted options or channels that can issue invoices. For specific payment and invoicing questions, see [How developers in China pay for AI APIs](/en/blog/pay-for-ai-api-in-china).
- With an aggregation gateway, confirm its relationship with the upstream vendors. For example, AGI Plan (a commercial partner of cdnping) states on its site that it is not an officially authorized channel, with monthly subscriptions settled in RMB. When choosing this kind of service, judge "is it officially authorized" separately from "is that acceptable for my business".

## How do you decide by scenario?

Answer the questions below in order and stop at the first "yes", then go back to the matrix and verify item by item.

### Scenario 1: personal coding tools (Claude Code, Codex, Cursor and so on)

1. Do you use only one vendor's models, and can you use the official payment methods? If yes, go direct to the vendor.
2. Do you need to switch between several vendors' models, or want to pay in RMB? If yes, use an aggregation gateway, but first check the uptime methodology and data policy as described above, then use the online speed test to see the latency from your network to the entry point.
3. To change the endpoint address, see [Custom API endpoints for Claude Code, Codex and OpenCode](/en/blog/configure-custom-api-endpoint-claude-code-codex).

### Scenario 2: internal team tools

1. Does the company require contracts, invoices or a data processing agreement? If yes, prefer cloud-hosted.
2. Is the internal tool latency-sensitive (for example, completion)? If yes, measure entry-point latency in your deployment data center and use p95, not the average, as the threshold.
3. Is usage high and task difficulty varied? Consider routing tasks to models of different tiers, and work out costs from your real input-to-output ratio. See [How to do multi-model routing to save cost](/en/blog/multi-model-routing-save-cost).

### Scenario 3: customer-facing products

1. Prepare at least two access paths, one primary and one backup. Being able to fail over to the backup when the primary has problems is more reliable than betting on a single source.
2. Give each path its own monitoring: your own real-request success rate, plus external probes (for example, the open data at `/api/status` provided by cdnping [API status](/en/status), licensed CC BY 4.0).
3. Prices and models change. Subscribe to the RSS feed for [site updates](/en/changes) to track changes to official changelogs and price pages. For the method, see [How to find out right away when an LLM API price changes](/en/blog/track-llm-price-and-model-changes).

## A printable checklist

After you pick candidates, tick the items off one by one. If any item can't be answered, don't go to production yet:

- [ ] Measured first connect, round trip and TTFT from your own network and your deployment data center, taking the median of 10 or more runs each
- [ ] Know the denominator and failure definition of the uptime figure, and can get raw data or status page history
- [ ] Calculated monthly cost using your own input-to-output ratio and cache hit rate, rather than comparing only unit prices
- [ ] Read the data policy in the original text: whether data is retained, for how long, and whether it is used for training
- [ ] Payment method, currency and invoices meet finance requirements
- [ ] Existing tools and SDKs work by changing configuration only, with no need to rewrite the call layer
- [ ] Have a backup path and a way to switch, and have rehearsed the switch once
- [ ] Subscribed to notifications for price and model changes