---
title: "Is a Claude API Relay Safe? 4 Risks and How to Self-Check"
description: "A Claude API relay sees your keys and prompts. Learn how relays work and run self-checks for data exposure, uptime, model swaps and billing, within the ToS."
url: https://cdnping.org/en/blog/is-claude-api-relay-safe
language: en
published: 2026-10-18
category: "Developer tools"
tags: ["Claude API","API relay","data security","uptime","billing audit"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# Is a Claude API Relay Safe? 4 Risks and How to Self-Check

Whether a Claude API relay is usable depends on the specific provider, so there is no blanket answer. Your keys, prompts and code all pass through it, and from the outside it is hard to tell whether it swaps models, what its uptime really is, or how it counts usage. So instead of asking "is it reliable?", work through the checks below: send only non-sensitive content, verify uptime against public data, and verify the model and billing with fixed requests. Anything you cannot check, treat as a fail.

A note on context: a "relay" (中转, sometimes called a "proxy station" or "gateway") is a third-party service that resells or forwards access to model APIs. It is common among developers in China, where direct access to Anthropic's API is restricted.

## What a relay actually does

In a normal call, the client connects straight to the official endpoint, `api.anthropic.com`. With a relay, the client connects to the relay's address. The relay receives the request, forwards it to some upstream using credentials it holds itself, and returns the response to you, either unchanged or rewritten.

The "upstream" is not necessarily Anthropic's official API. The same Claude model can be served by several inference providers. Take the cdnping [model monitor](/en/models) snapshot from October 17, 2026: the two Claude models tracked on OpenRouter list 8 and 10 provider entries respectively, including Anthropic itself plus different regions of Amazon Bedrock, Google Vertex and Azure. Which one a relay uses, and whether it switches between them, is generally invisible from the client. For how much uptime can differ between providers, see [Same model, different OpenRouter provider: how much can uptime differ](/en/blog/same-model-different-providers-uptime).

This extra hop brings four kinds of risk:

| Risk | Where it happens | What you can observe |
|---|---|---|
| Keys and content pass through a third party | The relay server sees plaintext requests | Almost nothing; you can only read their data policy |
| Opaque uptime | Upstream outages, the relay's own outages, stacked rate limits | Error codes, timeouts, whether public stats exist |
| Model swapped or downgraded | The relay substitutes a cheaper model or a quantized version | Response fields, behavioral differences, token counts |
| Unclear billing | Unit conversion, cached tokens, whether retries are charged | Invoice details compared against the response `usage` |

The sections below cover how to check each one.

## Will my keys and code be seen?

Yes. HTTPS only protects the leg between you and the relay server. At the relay the request is decrypted, because it has to read the request to forward it. Assume the relay operator can see everything you send.

This matters even more with coding tools such as Claude Code, which send the files they read, command output and error logs as context. If a `.env` file in your repo, a test database connection string or customer data gets read into the context, it goes through the relay too.

Things you can do:

1. Never hand the official API key to a relay. A relay only needs a key it issued itself; rule out any service that asks for your official key.
2. Set a spending cap on the relay key, and use a separate key per project or per machine, so a leak can be traced and revoked on its own.
3. Keep sensitive repositories off relays. For customer data, unreleased business information or contractually restricted code, use a channel your organization has approved.
4. Read the written data policy: whether request bodies are stored, for how long, and whether they are used for training or resold. If it is not written down, assume it is retained.
5. Rotate keys regularly: when someone leaves, when you change laptops, and before a repository goes public.

Setup only involves two values, the endpoint URL and the key. For the exact syntax, see [Configuring a custom API endpoint for Claude Code, Codex and OpenCode](/en/blog/configure-custom-api-endpoint-claude-code-codex).

## How do I judge uptime, and whose fault is an error?

A relay's uptime cannot be higher than its upstream's, unless it can fail over between several upstreams. The official service has outages too: in the data cdnping syncs from the Anthropic status page, there have been 8 Claude-related incidents since September 17, 2026, 6 of them marked major. If the relay's upstream happens to be the one that is down, the relay fails with it. The difference is only whether it tells you honestly.

### First, check whether they publish data

The trustworthy approach is to publish raw success and failure counts from real requests, by the hour or by the day, and to state what counts as a failure. A lone "99.9%" with no raw counts and no definition has very little reference value.

Here is what public data looks like. AGI Plan is a commercial partner of cdnping. [AGI Plan](https://agiplan.dev) publishes hourly success and failure counts per capability group at `https://agiplan.dev/api/status/requests?month=YYYY-MM`, with no login required, and only 5xx responses count as platform failures. As of October 17, 2026, its frontier reasoning group showed about 94.4% uptime over the previous 30 days (roughly 34,000 requests). On October 16, between about 14:00 and 16:00 Beijing time (UTC+8), the combined failures across all groups were 722 and 877 in the two hours respectively. The cdnping [AGI Plan status page](/en/status/agiplan) mirrors this data. Data like this shows you the bad periods, which is more useful than a single percentage. AGI Plan also states that it is not an officially authorized channel. When choosing a relay, treat "publishes raw data" and "states it is not officially authorized" as two baseline requirements.

### Locating an error in three steps

1. Open [Claude API status](/en/status/anthropic) and [Is Claude down?](/en/down/claude). cdnping probes the official endpoint from Cloudflare's edge every 5 minutes and syncs the official status page. If the official service is reporting an outage, switching relays will not help.
2. If the official service is fine, use the cdnping [speed test](/en/) to see your first-connect and round-trip times to Claude's official endpoint and several other APIs, to rule out your local network. For the order of checks, see [Troubleshooting Claude Code connection timeouts and errors](/en/blog/claude-code-connection-troubleshooting).
3. If both look normal, the problem is most likely the relay itself. Note the time, error code and request ID, and compare them with the provider's public status data.

To learn how to read incident severity levels on status pages, see [How to read the OpenAI and Claude status pages](/en/blog/how-to-read-ai-status-pages).

## How do I tell whether it swapped the model?

From the client there is no way to prove with 100% certainty which model or provider is behind a response. Asking the model "who are you?" is meaningless: its self-description can be overwritten by a system prompt, or simply be wrong. What you can do is collect several pieces of cross-checking evidence.

### Build a baseline with a fixed request

Prepare a fixed set of prompts with `temperature` set to 0, and send them to both the official API (if you have access) and the relay, or send them to the relay again every few days. Here is an example you can run after changing the address:

```bash
# Replace BASE and KEY with the values your relay gave you; set MODEL to the model name in their docs
BASE="https://your-relay.example.com"
KEY="sk-xxxx"
MODEL="your-model-name"

curl -s "$BASE/v1/messages" \
  -H "x-api-key: $KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "{
    \"model\": \"$MODEL\",
    \"max_tokens\": 200,
    \"temperature\": 0,
    \"messages\": [{\"role\": \"user\", \"content\": \"Repeat the following sentence word for word, adding nothing: cdnping relay check 0417\"}]
  }" | python3 -m json.tool
```

Look at these items in the response:

| Field | What to look for |
|---|---|
| `model` | Whether it matches what you requested; watch for a rewritten or empty value |
| `id` | Message IDs from Anthropic's native API start with `msg_`; a completely different format means a format conversion happened in between |
| `usage.input_tokens` | For the same input the count should be consistent every time; a large gap from the official count means a different tokenizer, and possibly a different model behind it |
| `stop_reason` | Whether it uses values from Anthropic's API, such as `end_turn` and `max_tokens` |

### Then look at capability differences

A smaller model or a low-precision quantized version tends to show up first in these places: finding specified content in a long context, multi-step tool calls, strict JSON output, and harder coding problems. Build a fixed test set from a few problems in your own work, run it weekly, and record the pass count. When it drops suddenly, combine that with the inference-provider and fp8/fp4 quantization differences described in [Did the model get dumber, or did the provider change?](/en/blog/llm-quantization-fp8-fp4-providers). Official model launches, retirements and price changes can be checked in the cdnping [model monitor](/en/models) and [official site changes](/en/changes).

## What to check in billing

Relays commonly bill per token, per request, or in a custom unit. Whichever it is, you should be able to reconcile the invoice with the `usage` in the responses.

Checklist:

- Are the conversion units clearly stated? If a custom unit is used, you should be able to work out "1 unit = how many tokens of which model", and whether input and output are counted separately.
- How are cached tokens charged? Anthropic's `usage` contains `cache_creation_input_tokens` and `cache_read_input_tokens`. Check whether the relay bills these two separately or treats everything as ordinary input.
- Are failed requests charged? Check whether 5xx responses, timeouts and client-side aborts are billed.
- Retries and automatic failover: when the relay retries internally or switches to another upstream, is it charged once or once per attempt?
- Can you export a per-request invoice? With only a total and no per-request records, you cannot reconcile anything.

A simple way to reconcile: send the fixed request above 10 times in a row, add up the `usage` from the responses, and compare it with what the relay's dashboard deducted for those 10 requests. If the gap goes beyond the stated conversion rules, ask them to explain.

## What to watch for on compliance

Anthropic's API is only available in its [published supported regions](https://www.anthropic.com/supported-countries), and use must comply with Anthropic's terms of service. A relay does not change those constraints and cannot take on compliance responsibility for you. Also check local regulations and your organization's rules on sending data outside. This article only discusses how to assess risk and does not cover any way of bypassing regional restrictions or platform risk controls. Services that split and resell personal subscription accounts, or ask you to help evade detection, are themselves a source of risk and should be ruled out immediately.

## A printable self-check table

| Check | What a pass looks like | How to check |
|---|---|---|
| Identity stated | Clearly says whether it is an officially authorized channel | Read the homepage and terms page |
| Data policy | Written statement on storage, retention period, and whether data is used for training or resold | Read the privacy policy |
| Key management | Supports multiple keys, spending caps, and revoking at any time | Try it once in the dashboard |
| Uptime data | Publishes raw success/failure counts and the definition used | Open their status API or page |
| Fault isolation | Can be told apart from official status | Compare with [Claude API status](/en/status/anthropic) |
| Model consistency | `model`, `id` and `usage` are stable and plausible | Run the curl baseline above |
| Auditable billing | Per-request detail that matches `usage` | Reconcile 10 fixed requests |
| Price change notices | Announcements for price or conversion rule changes | Check announcements or the changelog |

For a more complete selection checklist, see [How to choose an AI API relay: 8 checks on uptime, billing and data policy](/en/blog/api-relay-how-to-evaluate). On latency, a relay adds one extra hop and therefore one extra round trip; for how to measure it, see [AI API latency breakdown](/en/blog/api-latency-connect-rtt-ttft).

## About the data in this article

- Official endpoint probes: cdnping probes from Cloudflare edge nodes every 5 minutes. In the October 17, 2026 snapshot, the Claude API endpoint probe was normal. The probe points are on overseas edges, so the latency figures do not represent the experience from within China, and this article does not cite them.
- Incidents: from the Anthropic official status page synced by cdnping, for the window 2026-09-17 to 2026-10-17.
- Model providers: cdnping model monitor, sourced from the public OpenRouter API, 2026-10-17 snapshot.
- AGI Plan request stats: agiplan.dev public API, last 30 days as of 2026-10-17.

cdnping only started collecting data on October 17, 2026, so the history is short, and the numbers above describe only conditions at that time. For the methodology, see [Methodology](/en/methodology).