Token Relay Stations: The Architecture, Market, and Trust Crisis of the AI API Resale Ecosystem

On top of the large-model APIs, a gray-market yet thriving layer of infrastructure has quietly grown up: the Token relay station (API Relay Station). It sits between your app and upstream providers like OpenAI, Anthropic, and Google, aggregating multiple APIs into a single unified entry point while also handling billing, quotas, and the problem of "no direct connection from inside China." It sounds like nothing more than an ordinary gateway — but once a 2026 security paper revealed that "nearly half of the tested endpoints were silently swapping models," this invisible piece of middleware became worth taking apart in earnest.

This article walks the ecosystem all the way from its business logic and technical architecture down to its most fatal problem: trust. As a study of a technical ecosystem, it neither recommends nor endorses any commercial resale service — quite the opposite: the further you read, the clearer it becomes why you should treat them with caution.

1. What it actually is

A Token relay station is an intermediate gateway deployed between the user's app and the upstream AI provider. At its core it does four things:

• Aggregate: unify multiple upstreams (OpenAI, Claude, Gemini, DeepSeek, various domestic Chinese models, and so on) behind a single endpoint;
• Translate: normalize the request/response formats of different vendors into an OpenAI-compatible protocol;
• Manage: API keys, usage quotas, billing, and user permissions;
• Bypass: solve the problem that some regions cannot directly access overseas APIs.

The business logic is simple: operators buy API credits in bulk from official sources or channels, then resell them to downstream users through a self-built platform at a markup or at cost, pocketing the spread and service fees. The technical bar is low and the demand is real, so the whole space has quickly filled up with open-source projects and commercial sites.

2. The open-source projects in the ecosystem

The "de facto standard" in this space comes from two Chinese open-source projects; nearly every commercial relay station is built on them or on a fork of them.

Around these two cores, a batch of special-purpose tools has emerged: schemes that turn a personal subscription (Claude, OpenAI, etc.) into an API and "carpool" to split the cost; a "relay station for relay stations" that aggregates several relay-station accounts back into a single key and does smart routing; and browser extensions that manage balances and daily check-ins across multiple sites. On the front-end side, lightweight chat UIs pointed straight at a relay endpoint are common.

Internationally, mature gateways with similar positioning include LiteLLM (the most widely adopted worldwide, 100+ providers), Portkey Gateway (200+ routes plus AI guardrails), and the performance-obsessed Bifrost. Their biggest difference from the Chinese ecosystem is that they emphasize observability, guardrails, and enterprise-grade compliance rather than "resale arbitrage."

3. Technical architecture

Abstractly, a relay station is just a reverse proxy with business logic bolted on:

[User app] --> [Relay station] --> [Upstream providers]
                  |                           |-- OpenAI / Azure OpenAI
                  |-- Auth & token check      |-- Anthropic Claude
                  |-- Rate limiting           |-- Google Gemini
                  |-- Key pooling & rotation  |-- DeepSeek / domestic models
                  |-- Load balancing & failover
                  |-- Usage tracking & billing
                  |-- Request/response format conversion
                  |-- Caching (optional Redis) / model mapping

A few key components are worth understanding on their own:

• Channel system: every upstream API key is a "channel," with configurable priority and weight;
• Key pooling and rotation: multiple keys from the same provider form a pool, and requests are distributed automatically. There are usually three rotation strategies — balanced mode (good for keys rate-limited per minute), sequential mode (use one up, then move to the next; good for daily/weekly quotas), and priority mode;
• Format conversion: transparent conversion among the three protocols — OpenAI, Claude Messages, and Gemini — so the downstream side only has to face a single interface;
• Streaming relay: proxying SSE (Server-Sent Events) streaming responses;
• Automatic failover: when a channel errors out, automatically switch to another channel or key.

4. Deployment and setup

Because the open-source projects are so well packaged, the deployment bar is pushed very low. The most common starting point is a single Docker command:

docker run --name one-api -d --restart always \
  -p 3000:3000 -e TZ=Asia/Shanghai \
  -v /path/to/data:/data \
  justsong/one-api

In production, people usually switch to a MySQL/PostgreSQL + Redis Compose setup; some use Cloudflare Workers as a zero-cost lightweight proxy, or a one-click install via the BaoTa (宝塔) panel aimed at non-technical users. The setup flow is much the same everywhere: deploy → log into the admin panel and immediately change the default password → configure upstream channels (enter the key, pick the type, set the Base URL and priority) → create downstream tokens (quota, expiry, model restrictions, IP allowlist) → put an Nginx reverse proxy plus HTTPS in front → smoke test.

There is one easily overlooked detail that is critical to the streaming experience: the reverse proxy must turn off buffering, otherwise SSE streaming output will stall.

location / {
    proxy_pass http://localhost:3000;
    proxy_set_header Host $host;
    proxy_buffering off;   # SSE streaming requires buffering off
}

5. Market and monetization

The resale model shapes the commercial form of this space. From what's visible on the open market, the common monetization methods fall into a few rough categories: prepaid credit/points systems (deducted by usage — the mainstream), bulk redemption codes, tiered-quota subscriptions, a straight per-token markup (profiting on exchange rates and price spreads), and group-based differential pricing that assigns different rate multipliers to different user groups. Payments mostly run through Alipay, WeChat, Stripe, or cryptocurrency.

Price differences are exactly what expose the tiers of channel quality. Roughly speaking, the quotes on the market can be split into three tiers:

In other words, a price well below the official rate is usually not "operator charity" but a discount on quality or legality. And that leads naturally to the sharpest question in the whole ecosystem.

6. The most fatal problem: model fraud

In 2026, a CISPA paper, Real Money, Fake Models: Deceptive Model Claims in Shadow APIs, systematically audited these "shadow APIs," and its conclusions are rather glaring:

The paper also notes that most of the audited shadow APIs are built on the open-source projects mentioned above, and the vast majority lack a legal entity, business registration, or ICP filing. In other words, the technology of this infrastructure layer is transparent, while the business entities behind it are often invisible.

7. Security and legal risks

Model fraud is only the tip of the iceberg. Handing your requests to an unconstrained middleman inherently entails several kinds of structural risk:

• The middleman sees plaintext: in principle the operator can see all your prompts and responses. This is especially dangerous for scenarios that use command-execution tools (such as various AI coding agents);
• Key and data exposure: upstream API keys are stored on the relay server, and once the database is breached, your usage and content leak along with them;
• No SLA, no accountable entity: most operators are individuals, offering no service guarantee and little legal recourse;
• Compliance gray zone: operating an internet service without filing, potentially running afoul of data-sovereignty regulations, violating upstream terms of service (reverse-engineered channels most of all), a lack of consumer protection for downstream users, plus the tax and fraud risks that come with collecting payments through personal accounts.

8. If you must use one, how to protect yourself

Setting the operator's perspective aside, from the user's angle alone, there are a few low-cost ways to tell channels apart that can markedly reduce the odds of being served a "reskinned, swapped-out model":

• Test Function Calling: reverse-engineered channels usually don't support it, so one test tells you;
• Check the Response ID format: official OpenAI response IDs begin with chatcmpl-, so an abnormal format is worth suspecting;
• Compare output quality side by side: run the same batch of prompts against the official API one by one; a swapped model often gives itself away on complex tasks;
• Keep some common sense about price: a quote far below the official rate is most likely reverse-engineered or already model-swapped;
• Insist on HTTPS, enable IP allowlisting, and rotate keys regularly, narrowing the controllable attack surface as much as possible.

For the operator side, prioritizing reliable official forwarding, using low-cost channels only as a fallback, combined with channel-availability health checks, auto-disabling failed channels, and Redis-based rate limiting and alerting, is the basic discipline for taking something from "it runs" to "it can be trusted."

Conclusion

The Token relay station is a textbook case of "mature technology, absent governance": open-source projects let anyone stand up a multi-model gateway in a few minutes, and it is precisely this low bar that has spawned a gray market where the prices are tempting but trust is thin. Its value is beyond doubt — aggregation, failover, and unified formats are all real needs; but when the middleman can both see all your data and quietly swap out the model you paid for, the word "cheap" deserves to be weighed again. Understanding its architecture is about staying a bit more clear-eyed when you choose: on the chain of AI infrastructure, what you trust is not just the model, but every hop in between.