How Sub2API works and where its compliance line sits

What problem it solves

The official API bills per token while a web subscription is a flat monthly fee. For heavy use, the equivalent token volume of one Claude Pro subscription can be worth more than ten times the subscription fee at API prices.

That gap is the opening for projects like Sub2API: turning subscription usage into resellable quota.

How it works: three layers

1. Protocol reverse-engineering

The web subscription has no public API, so the web request protocol has to be reverse-engineered first: how the login state is maintained, how a conversation is submitted, how streaming responses are parsed. This layer is pure reverse engineering and breaks whenever the upstream front end is redesigned.

2. The account pool

A single subscription account has rate and concurrency limits, so several accounts are pooled. The core design of the pool is scheduling:

• Round-robin: even distribution, simple, but it breaks context in long conversations
• Sticky sessions: one conversation stays pinned to one account so context remains continuous, which is the precondition for agent work and long conversations

The selling point of implementations like sub2api is intelligent scheduling with session stickiness, plus removing an account automatically when it is rate limited and returning it to the pool once it recovers.

3. Interface wrapping

A standard protocol is exposed downstream, either OpenAI-compatible or Anthropic-compatible, so that changing base_url is enough. Token-level billing is layered on top so usage can be resold.

When it fails wholesale

This is the point to settle before using it: the failure mode is wholesale, not gradual.

1. Upstream front-end redesign: the reverse-engineered protocol breaks, the whole pool is unusable, and recovery time depends on how quickly the maintainer responds.
2. Risk-control changes: bulk bans can empty an account pool overnight.
3. Terms enforcement: the upstream explicitly forbids programmatic access to subscription accounts. The risk is not a possibility but a matter of when.

Compare the failure modes:

• An official-resale site failing usually means an individual channel is down and you can switch.
• A reverse site failing usually means the whole site is down with no backup.

The three boundaries

Boundary one: terms compliance

Upstream terms of service generally forbid automated access and reselling or sharing accounts. Using these services begins with recognising that this is not a technical grey area, it is a clear breach of terms.

How the risk is distributed:

• For the provider: accounts banned and liability pursued under the terms.
• For the user: service stops without notice, and recovering prepaid balance has no basis, because the upstream does not recognise the underlying transaction.
• For companies: if a business path depends on it, one wave of bans is one business interruption, and it is hard to explain internally why this option was chosen.

Boundary two: missing capability

A subscription account does not have these official API capabilities:

• The Batch API
• Prompt cache billing through cache_control
• A stable /v1/models
• Committed concurrency and TPM/RPM quotas
• Guaranteed structured output

In other words, any architecture that depends on the above cannot be built on a reverse site. This is not a question of quality but of whether the capability exists at all.

Boundary three: prepayment risk

A reverse site's price advantage rests on very low marginal cost, which also means it has no stable cash flow behind it. Add the possibility of wholesale failure and the risk of a large prepayment is markedly higher than with official resale.

The sensible pattern is to top up weekly or monthly in small amounts and treat it as a consumable rather than long-term infrastructure.

So who is it for

Honestly, it has a clear fit:

• Personal learning and experimentation, to explore the capability limits of Claude or GPT cheaply
• Non-critical prototyping, to validate an idea quickly without infrastructure cost
• Low-frequency personal tasks that do not need concurrency, such as writing assistance, code questions and everyday Q&A

The unsuitable cases are equally clear:

• Critical production paths, at any concurrency, because availability is not guaranteed
• Any batch work that needs Batch, caching or structured output
• Situations where you must commit to an SLA for a client or colleague
• Procurement processes that require vendor qualifications and compliance review

How to tell whether a site is reverse

Three signs:

1. It does not return a real /v1/models, or the list contains model names that do not match the official ones
2. The error text does not look official: official errors are structured and carry type and code fields, while reverse sites often return custom text
3. The price is below 20% of official and Batch and caching are unsupported, so both price and capability point to a subscription pool

When we list a site we mark its underlying engine and verification status on the detail page. If a site is marked as account-pool based, file it under trial rather than production.