---
title: "How to Choose an API Relay: 8 Checks on Uptime, Billing and Data"
description: "Choosing an API relay? Verify, don't trust: 8 checks on uptime method, billing units, data policy, API format, postmortems and latency, with curl examples."
url: https://cdnping.org/en/blog/api-relay-how-to-evaluate
language: en
published: 2026-10-18
category: "Developer tools"
tags: ["API relay","LLM API","uptime","billing","data policy","developer tools"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# How to Choose an API Relay: 8 Checks on Uptime, Billing and Data

When you evaluate an API relay, start with whether you can check what it tells you yourself. Does the uptime figure come with public raw data and a stated calculation method? Can the bill be matched against the tokens of each request? Is the data handling written down? With a service you can verify, you at least know where the problem is when something breaks. With one you can only "trust", all you can do is wait.

Below are 8 checks, each with a way to verify it. They are worth running before you top up or subscribe.

## What does an API relay actually do, and why evaluate it separately?

A relay (also called an API gateway or aggregation gateway) adds a layer between you and the model provider: your request goes to its endpoint first, and it forwards the request upstream. The upside is that switching models means changing only one endpoint URL, and billing and payment may be more convenient. The cost is one more component that can fail, bill you, and see the content of your requests.

So there are three things to evaluate: how stable this layer is, how it charges, and how it treats your data. The quality and outages of the upstream model are a separate matter and should be assessed separately.

## The 8-check list (you can follow it as is)

| # | Check | What good looks like | How to verify |
|---|---|---|---|
| 1 | Public uptime and method | Raw counts available to download, with numerator and denominator stated | Pull the data and compute it yourself |
| 2 | Billing unit and invoice | Unit has a conversion formula, and single requests can be reconciled | Send a fixed request, compare usage with the charge |
| 3 | Data retention policy | States whether data is stored, used for training, or resold | Find the written terms and keep a screenshot |
| 4 | API format | States which format it is compatible with; streaming and tool calls work | Run it once with the tools you actually use |
| 5 | Refunds and invoices | Terms are on the page, not "contact support" | Read the page, not the chat history |
| 6 | Incident postmortems | After an outage: time, scope and cause are explained | Find the record of the most recent outage |
| 7 | Egress and latency | Stable endpoint latency, acceptable time to first token | Measure connection and TTFT on your own network |
| 8 | Authorization claims | Honest about its relationship with the model vendor | Check whether the site claims to be "officially authorized" |

Each one in detail below.

### 1. How is the uptime number calculated?

The statement "99.9% available" cannot be verified by itself. Ask three questions:

- What is measured: scheduled probes (pinging the endpoint every few minutes) or real user requests? Probes only tell you whether the endpoint is reachable. Real requests reflect the failures you would actually hit.
- What counts as a failure: do 4xx responses (wrong key, insufficient balance) count? Whose fault is an upstream timeout? With different definitions, the same period can produce very different numbers.
- Can you get the raw data: with only a percentage, you can only trust it. With hourly success and failure counts, you can recompute it yourself.

Here is AGI Plan as an example of what "verifiable" looks like. First, the relationship: AGI Plan is a commercial partner of cdnping. We use it as the example because its data is public and we can quote it in full, not as a recommendation.

Its uptime endpoint requires no login:

```bash
# Returns CSV by default; add format=json for JSON
curl -s "https://agiplan.dev/api/status/requests?month=2026-10&format=json"
```

It returns hourly success and failure counts per capability group. The stated method is: uptime = successes / (successes + failures caused by the platform itself), and only 5xx counts as a platform failure. The cdnping [AGI Plan status page](/en/status/agiplan) mirrors the same data.

In the snapshot we took from this endpoint on 2026-10-17 (window: 2026-10-15 19:00 to 2026-10-17 18:00, Beijing time, 48 hourly buckets):

- Over the 48 hours there were 13,963 successes and 2,177 failures, which works out to about 86.5% under the method above.
- Failures were concentrated in two hours on October 16, 14:00 and 15:00: in those two hours there were 1,119 successes and 1,599 failures, for single-hour uptime of about 47.9% and 34.2%.
- 30-day uptime by capability group: domestic (China-hosted models) about 98.0%, balanced about 95.0%, frontier about 94.4%, fast about 81.7%.

These numbers are not pretty. But once the data is public, the bad periods are right there: you can see which hours and which capability group the failures cluster in, and decide whether your usage can tolerate that. With a single percentage and no raw counts, you cannot make that judgment.

You can use the same method on any relay: get the raw data, sum it yourself, look at the worst few hours, then look at the differences between groups.

### 2. Can the billing unit be matched to requests?

Relays often use custom units (points, credits, CU and so on). Confirm two things: whether there is a public conversion formula between the unit and tokens, and whether the charge for a single request can be looked up in detail.

For example, AGI Plan states that 1 CU = 1,000 output tokens of the baseline model, and that pay-as-you-go top-up is 1 CNY = 500 CU. With a formula, you can convert the bill back to tokens and compare it with the model vendor's official prices.

To verify, send a small request with fixed input and output, note the `usage` field in the response, then check in the dashboard how much was charged for it.

```bash
export BASE="https://relay.example.com"   # Example URL, replace with the service you are evaluating
export KEY="sk-..."

curl -s "$BASE/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<模型名>","max_tokens":50,
       "messages":[{"role":"user","content":"只回答数字：1+1="}]}' \
  | python3 -m json.tool | grep -A4 usage
```

(The `<模型名>` placeholder means "model name", and the prompt means "Answer with the number only: 1+1=".)

Send the same request 5 times in a row; the charges should be essentially identical. If the dashboard only shows balance changes and no per-request detail, reconciling at the end of the month will be hard. You also need to learn promptly when a model's price or the conversion ratio changes; see [Three ways to track LLM API price changes](/en/blog/track-llm-price-and-model-changes).

### 3. Will your request content be stored?

Requests often contain code, documents, even keys. What you are looking for is written terms that answer at least three questions: is the request body written to disk, and for how long; is it used for training; is it resold or shared with third parties.

A policy that fits in one sentence is easier to check. For example, AGI Plan states: "request bodies are not written to disk by default; content is not used for training and not resold". After you find the terms, take a screenshot and note the date, so you have something to compare against if they change later.

However the terms are written, do not put production keys or users' private data in prompts. This applies to official APIs as well.

### 4. Which API formats are supported, and can your tools use them directly?

The two common ones today are the OpenAI format and the Anthropic format. For example, Claude Code uses the Anthropic format and Codex uses the OpenAI format. If a relay supports only one, some of your tools cannot connect.

Don't verify with a single plain chat. Cover at least these three:

1. Streaming: add `"stream": true` and check that output comes back in chunks rather than all at once at the end.
2. Tool calls: run a task in your actual agent tool that needs to read a file or execute a command.
3. Long context: feed in a long file and see whether it gets truncated or errors out.

For how to change the endpoint in each tool, see [Custom endpoint setup for Claude Code, Codex and OpenCode](/en/blog/configure-custom-api-endpoint-claude-code-codex).

### 5. Where are refunds and invoices written?

Check just one thing here: are the terms on a public page? "Contact support if there is a problem" does not count as written. Teams that need to expense the cost should confirm that the invoice type and how it is issued are explained on the page.

Promises in a chat history are hard to rely on; written terms can at least be archived with a screenshot. If the terms are marked as a draft or "coming soon", treat them as not yet existing.

### 6. Has it had outages, and is there a postmortem?

Every service has outages. According to the incident records cdnping syncs from official status pages (snapshot as of 2026-10-17), since 2026-09-17 OpenAI has recorded 25 incidents (4 of them major) and Claude has recorded 8 (6 of them major). A relay's uptime ceiling is bounded by its upstreams, and that is a fact; what you want to see is whether it explains clearly when something goes wrong.

To verify, go through its announcements, status page or changelog, find the most recent outage, and check whether it states the start and end times, which models or groups were affected, whether the cause was upstream or its own, and what changed afterward.

Back to the example in check 1: the public counts tell you that those two hours on the afternoon of October 16 had many failures, but the counts themselves do not give a cause. So read checks 1 and 6 together: the first tells you what happened, the second tells you why and whether it will happen again. For how to read incident severity on status pages, see [How to read the OpenAI and Claude status pages](/en/blog/how-to-read-ai-status-pages); a roundup of recent upstream outages is in [AI service incidents, September to October 2026](/en/blog/ai-service-incidents-sep-oct-2026).

### 7. Is the latency acceptable from where you are?

A relay's latency has two parts: your network to its endpoint, plus its forwarding and inference to the upstream. Numbers measured by others only represent their networks, so measure in your own environment.

Step one: open the cdnping [online speed test](/en) and look at "first connect" (including DNS and the TLS handshake) and "round trip" (the median of 3 requests after the connection is reused) for each API endpoint in your browser.

Step two: use curl to break out the time for each phase:

```bash
curl -s -o /dev/null "$BASE/v1/models" \
  -H "Authorization: Bearer $KEY" \
  -w "DNS %{time_namelookup}s | TCP %{time_connect}s | TLS %{time_appconnect}s | 首字节 %{time_starttransfer}s | 总计 %{time_total}s\n"
```

(In the output, 首字节 is time to first byte and 总计 is total time.)

Run it a few times at different times of day. `/v1/models` does not involve inference, so it mostly reflects the gateway itself; what really affects the experience is the time to first token (TTFT) of a streaming request. To tell the three kinds of latency apart, see [AI API latency breakdown: connect, round trip and TTFT](/en/blog/api-latency-connect-rtt-ttft).

Also, the same model name may be served by different inference providers at different quantization precisions behind the scenes, so output quality and speed can differ. You can check each provider's uptime and quantization labels on the cdnping [model monitor](/en/models); for background, see [Inference providers and fp8/fp4 quantization](/en/blog/llm-quantization-fp8-fp4-providers). For how much the uptime of the same model differs between OpenRouter providers, see [Same model, different OpenRouter provider: how much can uptime differ?](/en/blog/same-model-different-providers-uptime).

### 8. Does it claim to be "officially authorized"?

Verify with the model vendor's official channels rather than relying on what the relay says about itself. A service that is honest about its identity is somewhat more trustworthy. For example, AGI Plan states clearly on its site that it is not an officially authorized channel.

Also, some models are not offered in some regions. Regional availability a relay lists (for example "overseas only") is subject to its official page; please follow the model vendor's terms of service and local regulations when using it.

## How to decide after the checks

Fill the results of the 8 checks into the table above and prioritize in this order:

1. If either check 3 or 8 is unclear, rule it out. Data policy and identity disclosure are the baseline.
2. Checks 1 and 2 decide whether you can use it long term. A service whose uptime cannot be recomputed and whose bill cannot be reconciled is fine for a small trial, but not for your workflow.
3. Checks 4 and 7 decide whether it is pleasant to use. They depend heavily on your tools and network, so you can only test them yourself.
4. Checks 5 and 6 decide where you stand when things go wrong. The clearer the terms and postmortems, the lower the communication cost after a problem.

Start small or pay-as-you-go, run your real tasks for a week, and each day pull the public uptime data (if there is any) and compare it with your own error logs. If the two sides match, then consider a long-term subscription.