Official resale, mixed routing, reverse-engineered: a three-way split of upstream sources and how to identify them
Why the upstream source comes first
A relay site is a proxy layer: it has no models of its own, only quota. So its two core attributes, the stability floor and the price floor, are decided entirely by where that quota comes from.
The same 0.5 rate is a thin margin for an official-resale site and a huge one for a reverse site. The same occasional timeout is upstream jitter for the former and possibly a risk-control sweep of the account pool for the latter. Price and failure only mean something once you know the source.
The three sources in technical detail
Official resale
Forwarding with genuine official API keys. Technically there is no conversion; requests pass through unchanged.
- Request path: your client -> relay site -> official API
- Headers and response bodies are essentially unchanged, and
/v1/modelsreturns the real list - Everything the official platform offers is supported: the Batch API, cache billing, structured output, function calling, multimodal input
- Ceiling: official rate limits and official outages pass straight through
Mixed routing
A multi-source quota pool plus programmatic routing, with weights usually combining cost, balance and recent success rate. Among open-source implementations metapi is the archetypal relay site for relay sites.
- Request path: your client -> relay site, where routing is decided -> some upstream in the pool, possibly another relay site
- Path length is not fixed: two requests for the same model may take completely different routes
- The most visible symptom is high variance: latency and quality differ noticeably between time windows
- What matters is its circuit-breaking policy: a good implementation removes a channel once its failure rate passes a threshold, while a poor one keeps retrying
Reverse subscription
Turning web subscription accounts such as Claude Pro or Max and ChatGPT Plus or Pro into an API. Technically it depends on reverse-engineering the web protocol and holding sessions open; sub2api is the representative open-source project.
- Request path: your client -> relay site -> account pool, choosing one -> upstream web interface
- It does not offer the full official API: no Batch, no cache_control, no stable
/v1/models - Session stickiness is the key design: a long conversation must land on one account or the context breaks
- The largest uncertainty comes from upstream rule changes, where a single risk-control adjustment can invalidate the whole pool
Four observable signs
You do not need to ask the operator. These four are enough:
1. Price band
| Claimed source | Plausible rate | Clearly abnormal |
|---|---|---|
| Official resale | 30% to 70% of official | Below 30% while claiming pure official |
| Mixed routing | Unbounded, but with reported swings | Permanently pinned at an extreme low |
| Reverse subscription | 5% to 20% of official | Claiming Batch or caching support |
2. Interface completeness, the hardest test
Test in order: does GET /v1/models return a real list, does it accept a standard system prompt without rewriting it, does it support response_format={"type":"json_object"}, does it support cache_control.
Anything that passes the last three is almost certainly not a reverse subscription, because a subscription account has no such capability and a reverse layer cannot invent it.
3. Precision of model naming
- Official resale: the version is stated, as in claude-sonnet-4-6 or gpt-5.1
- Mixed: usually the family name, as in claude-sonnet
- Reverse: the family name, and often combinations that do not exist officially
Call a model name that does not exist and read the error text. Official-resale errors come from the official platform and are neatly structured, while reverse-site errors usually come from their own middle layer.
4. Behaviour under concurrency
Fire ten to twenty concurrent requests at one model. With official resale the ceiling is set by the quota you bought. Reverse sites hit the capacity of the account pool, which usually shows up as a wave of 429s as soon as concurrency rises, and the 429 body is formatted differently from the official one.
The three-step method
Step one: run the interface completeness test, about five minutes. /v1/models, json_object, cache_control. Pass everything and you are looking at official resale or high-quality mixed routing; fail and it points to reverse or low-quality mixed.
Step two: check price against capability, about two minutes. A quote below 30% of official that nevertheless claims Batch and caching support has at least one false claim, so rule it out.
Step three: a small concurrency load test, about ten minutes. Top up the minimum, then run twenty concurrent requests three times. Watch for inconsistently formatted 429s and for wild latency variance.
Once all three are done the category is usually obvious. The whole process takes under twenty minutes and costs a few tens of yuan, which is worth it compared with the cost of one bad experience.
A common misconception
Reverse does not automatically mean bad. For personal, non-critical, low-frequency use, reverse subscriptions are unbeatable value, and many reverse sites put real care into session stickiness and failover.
The real problem is not building critical production paths on a reverse site's stability, and not topping up a large amount just because it is cheap. Its failures tend to be wholesale and sudden rather than gradual.
Was this useful? If you have run into something the article does not cover, tell us and we will verify it and update the text.
Related articles
Video generation behind a relay: three API shapes, four billing traps, one acceptance checklist
MCP through a relay: what works, what never will, and how to test it in ten minutes
A relay selection decision tree: working back from your scenario to a site
Logging and reconciliation: attributing token spend to the project level
Migrating suppliers gradually: replacing an API site without interrupting service
Build your own probe: twenty lines of script to monitor your API suppliers
Read on: a few of the services we list
This article does not point at a specific model family, so here are a few of the highest-scoring services we list, in case you want to read on. They are ordered by score and uptime and are not a recommendation.
See the full list in the directory, or browse by model family.