Official resale, mixed routing, reverse-engineered: a three-way split of upstream sources and how to identify them

Tutorials Published 2026-09-28 259 views API Compass
Two sites are both relay services, but different upstream sources give them entirely different stability floors and price floors. This article gives a three-step method that needs no questions to the operator.

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/models returns 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 sourcePlausible rateClearly abnormal
Official resale30% to 70% of officialBelow 30% while claiming pure official
Mixed routingUnbounded, but with reported swingsPermanently pinned at an extreme low
Reverse subscription5% to 20% of officialClaiming 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

2026-10-19

MCP through a relay: what works, what never will, and how to test it in ten minutes

2026-10-19

A relay selection decision tree: working back from your scenario to a site

2026-10-07

Logging and reconciliation: attributing token spend to the project level

2026-10-06

Migrating suppliers gradually: replacing an API site without interrupting service

2026-10-06

Build your own probe: twenty lines of script to monitor your API suppliers

2026-10-06

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.