> Markdown mirror of https://router.one/blog/official-llm-gateway-vs-api-relays for AI assistants and crawlers. Router One is an OpenAI-compatible LLM API gateway.
> Published: 2026-05-24 · Last updated: 2026-07-28 · Author: Router One Team

# LLM Gateway vs API Relay: 5 Ways They Actually Differ

_LLM gateway vs API relay: five dimensions where they actually diverge — legal entity, SLA, observability, pricing transparency, and data boundary._

If you have shopped for LLM API access from inside China in the past two years, you have run into them: small, fast-moving platforms that resell access to overseas models at attractive prices, accept Alipay or USDT, and let you start calling within minutes. They make demos and side projects feel effortless.

The trouble starts when you try to put one of them behind a production workload. Accounts get suspended without notice. Bills change shape mid-cycle. A request fails and there is no one to call. You cannot tell whether the model that just answered was the model you paid for. You cannot tell where your prompt went after the response came back.

This post is not about naming any single platform. It describes the structural pattern of unofficial LLM API relays, and where a production-grade gateway has to be different. The comparison is restrained on purpose — the choice should be obvious once the dimensions are laid out side by side.

If you have already read [Router One vs OpenRouter China](https://router.one/blog/router-one-vs-openrouter-china), this article complements it. That one compares two legitimate gateways. This one is about the gap between any legitimate gateway and the unofficial relay tier underneath.

## What "unofficial relay platform" usually means

The pattern is consistent enough to describe in general terms. You typically see some combination of:

- A pool of upstream provider accounts the platform rotates through, often topped up by intermediaries
- Resale of someone else's API keys, with the markup hidden inside a per-token rate or a flat monthly plan
- No clear legal entity behind the service — payment goes to a personal payment account or a USDT wallet
- No published terms of service, no refund policy, no incident page, no SLA
- A control panel that shows you a balance and a usage counter, but no per-request trace and no breakdown of where each call actually went

None of these are inherently illegal in isolation, and many of these platforms genuinely help individual developers get unblocked. The problem is what happens when you depend on one. Five dimensions matter, and each maps to a specific kind of failure you will eventually see in production.

A note for operators: if you run a relay service yourself and want it to clear the bars below, see [how to build your own API relay service on Router One](https://router.one/llm-api-relay-station).

## Dimension 1: Legal entity and compliance boundary

A production service needs to know who it is paying and who is on the hook when something goes wrong.

A production-grade LLM gateway has a registered company, public terms of service, a published refund policy ([refund policy](https://router.one/refund)), a security boundary statement ([security boundary](https://router.one/security)), and a public facts page ([citeable facts page](https://router.one/trust/facts)). Payments flow through documented rails — card processors and supported stablecoin top-up flows — with checkout terms and fee boundaries visible before payment. You have a counterparty.

An unofficial relay typically does not. Payment goes to an individual wallet, terms are absent or only displayed at signup and never linked, and there is no public entity to invoice, dispute, or escalate against. For an indie developer with a hobby project this is acceptable risk. For a team that will eventually be asked "who are we paying, and what are their obligations to us" by finance or legal, it is not.

## Dimension 2: SLA and remediation

Production workloads do not just need a service to work most of the time. They need a service to take responsibility when it does not.

Router One publishes availability measurement rules on [the SLA measurement rules](https://router.one/sla), a public incident surface at [the public status page](https://router.one/status), and the final outcome of each request in the customer usage trace. Failed upstream attempts behind fallback can be investigated in operational logs by request_id. Annual enterprise contracts can include service credits when contractual availability targets are missed. You can argue with the measurement rules. You can hold us to the contract you signed.

The unofficial relay tier does not generally do this. There is no published availability target, no incident page, and no remediation when the upstream account pool gets banned and the platform goes dark for a day. The economics do not support it: a platform whose margin comes from arbitraging shared accounts cannot afford to refund customers when an account gets suspended.

This is the single most expensive surprise in practice. The platform is cheap on paper, until your agent stops responding at 3am and the answer is a message in a group chat saying "上游被封了，明天处理."

## Dimension 3: Per-request observability

The reason you put a gateway in front of LLM calls in the first place is to know what happened on each call.

Router One emits a per-request trace covering the final model and provider, token counts, latency, status, cost, and API key — the methodology is documented at [routing methodology](https://router.one/routing-methodology). You can answer "why did this request cost what it cost" and "is the p99 latency drift coming from one upstream or all of them". Give each project or agent workload a separate API key, then attribute cost in the per-key view. The customer trace does not show failed attempts or a fallback chain; support uses the request_id to investigate those details in operational logs.

An unofficial relay typically gives you a balance and an aggregate usage counter. The response is a black box. If the model output quality drops, you cannot tell whether the platform silently downgraded the route to a cheaper variant. If costs spike, you cannot tell which calls drove them. You are paying for a number on a dashboard, not for an auditable record.

For demos this does not matter. For anything you have to explain to a manager or a customer, it matters a lot.

## Dimension 4: Pricing transparency

A legitimate gateway charges a posted per-token rate. The rate is on the model marketplace at [the model marketplace](https://router.one/models). FX and channel fees, where they apply, are shown at checkout, not buried. The methodology behind those numbers is on [pricing methodology](https://router.one/pricing-methodology). You can compare them, line by line, against the upstream provider's own published rates.

The unofficial relay tier frequently uses a different structure: bundled monthly plans, opaque multipliers on top of upstream prices, FX rates that show up only at the moment of payment, and auto-renewing subscriptions that are harder to cancel than to start. None of this is fraud — it is just the structure that maximizes the margin a reseller can extract. But it makes capacity planning impossible. You cannot model your unit economics on top of a number that changes shape every month.

## Dimension 5: Data retention and security boundary

The last dimension is the one teams notice last and regret most.

Router One's position is documented in [the security boundary](https://router.one/security) and [data retention](https://router.one/data-retention): we do not retain prompt or completion bodies, we retain only the metadata needed to bill and to operate the service, and the retention windows are public. If you need to argue to your security team that your prompts are not sitting in someone else's database, you have a document to point at.

An unofficial relay typically has no retention statement at all. The data flows through the platform's infrastructure on its way upstream, and you have no contract describing what happens to it. For personal experimentation this is fine. For anything touching customer data, code repositories, or internal documents, it is a problem you cannot delegate to "I trust the operator."

## Side-by-side

| Dimension | Production-grade gateway | Typical unofficial relay |
| --- | --- | --- |
| Legal entity | Registered company, public ToS, refund policy | Individual wallet, no public entity |
| SLA | Published measurement rules, public incident timeline, enterprise credits by contract | None |
| Per-request observability | Final model/provider, tokens, latency, status, cost, and API key | Aggregate balance and usage counter |
| Pricing structure | Posted per-token rates, FX shown at checkout, methodology page | Bundled plans, hidden multipliers, opaque FX |
| Data retention | Published retention windows, no prompt/completion bodies kept | Undisclosed |
| Recourse on failure | Status page, support channel, enterprise credits by contract | Group chat, no remediation |
| Upstream sourcing | Official upstream API channels | Pooled accounts, resold keys |

## A purchasing checklist

Before you put a relay platform behind a production workload, ask the operator to answer these questions in writing. A legitimate gateway answers all eight in under a minute. If your current provider cannot answer most of them, you have your answer about whether they should be running your production traffic.

1. What is the legal entity? Where is it registered? Is there a business license number you can share?
2. Where is the link to your terms of service, refund policy, and acceptable use policy?
3. What is your published uptime target, and what is the remediation when it is missed?
4. Are you calling the upstream model providers through their official API channels, or through a pool of consumer or third-party accounts?
5. Can a single request show me the model that served it, the token counts, the latency, and the cost?
6. Do you retain prompt or completion bodies? For how long? Where are they stored?
7. Is your per-token rate published? Are FX and channel fees displayed at checkout?
8. Do you publish a status page with historical availability?

## FAQ

**What is an unofficial LLM API relay platform?**
It is a resale layer for overseas model access that typically rotates a pool of upstream provider accounts or resells someone else's API keys, takes payment through personal accounts or USDT wallets, and publishes no terms of service, refund policy, SLA, or per-request trace.

**When is it OK to use an unofficial relay, and when is it not?**
For weekend projects, demos, learning, and one-off experiments, the relay tier is often the fastest path to a working integration. The moment a workload starts mattering to your users, your team, your finance department, or your customers' data, the missing entity, SLA, trace, published rate, and retention statement each map to a concrete incident you will eventually have to explain.

**How do I vet an LLM API platform before putting it behind production traffic?**
Ask the operator to answer eight questions in writing: legal entity, links to terms and refund policy, published uptime target and remediation, whether upstream calls go through official API channels, per-request visibility into model, tokens, latency, and cost, prompt and completion retention, published per-token rates with FX shown at checkout, and a status page with historical availability. A legitimate gateway answers all eight in under a minute.

**Does Router One retain prompt or completion bodies?**
No. Router One retains only the metadata needed to bill and operate the service, the retention windows are public, and the position is documented in [the security boundary](https://router.one/security) and [data retention](https://router.one/data-retention).

**What does Router One's per-request trace show?**
Each request records the final model and provider, token counts, latency, status, cost, and API key, as documented at [routing methodology](https://router.one/routing-methodology). The customer trace does not show failed attempts or a fallback chain; support uses the request_id to investigate those details in operational logs.

## When the relay tier is fine, and when it is not

This piece is not arguing that every cheap relay platform is unusable. For weekend projects, demos, learning, and one-off experiments, the unofficial relay tier is often the fastest path to a working integration, and the lack of structure around it is not a real cost.

The argument is narrower: the moment a workload starts mattering to your users, your team, your finance department, or your customers' data, the absence of an entity, an SLA, a trace, a published rate, and a retention statement stops being abstract. Each of those gaps maps to a concrete incident you will eventually have to explain.

If you are ready to put a gateway behind real traffic, see the [Router One vs OpenRouter China](https://router.one/blog/router-one-vs-openrouter-china) comparison for the legitimate-gateway tier, the [product comparison page](https://router.one/openrouter-alternative) for a quick side-by-side, or sign up at [router.one](https://router.one/) to get started.

## See also

- Canonical page: https://router.one/blog/official-llm-gateway-vs-api-relays
- LLM API Gateway and Routing: https://router.one/llm-api-gateway
- All blog posts: https://router.one/blog
- Models and per-model token rates: https://router.one/models (markdown: https://router.one/models.md)
- Pricing: https://router.one/pricing
- API docs (markdown): https://router.one/docs.md
- Company facts: https://router.one/facts/company.md