Web-Cookie AI API Relays: Why They Break and the ToS Risk You Carry

There is a category of "free AI API" in circulation that deserves to be understood before you route anything through it: the web-cookie relay, also called a shared-session pool. It is free, it is popular, and it carries two structural risks — fragility and terms-of-service exposure — that no amount of goodwill from the operator can remove. Neither risk is a bug that gets fixed in the next release; both are consequences of how the thing is built.

This is not an argument that relays are evil. For some users a fragile free relay is the only on-ramp to the models they want to try, and knowing how to read one is more useful than being told to avoid them. What follows is how the mechanism works, where it fails, whose legal exposure it creates, and the checklist we apply when we encounter one.

What a web-cookie relay actually does

A consumer AI product gives its logged-in human users free usage under their terms. A relay service inserts itself between that consumer tier and API-shaped traffic. It does one of two things:

1. It pools consumer web sessions (cookies) across its API users. One request from you is served by one of the operator's logged-in sessions, drawn from a rotating supply.
2. It automates logins and proxies traffic under a machine identity. Credentials live with the operator; your requests ride behind them.

Either way, the essential economic fact is the same: the relay is not paying the model vendor. It is borrowing the vendor's free consumer tier, at scale, for strangers. The "API" is a thin OpenAI-compatible front over someone else's web session.

That sentence explains almost everything downstream. Because there is no commercial relationship between the relay and the model vendor, there is no contract, no service-level agreement, no support channel, and no notice period. There is only a web session the vendor has not yet decided to invalidate.

How to recognise a relay: six structural tells

Any one of these is a yellow flag; three together is close to conclusive.

1. No named upstream relationship. The documentation says "powered by" consumer products, or mentions cookies, accounts, pools, or shared sessions. A licensed reseller names the providers it has agreements with. A first-party free tier is the provider.
2. Model names that look like a guess. Entries tagged with promo-style bracket markers, or a model list with a "(claimed)" suffix, signals that the operator is describing what it thinks the session can reach rather than enumerating licensed model SKUs. Model catalogues we have cleaned up have contained exactly this kind of artefact.
3. No published per-model pricing. A licensed reseller prices per model because it buys per model. A relay prices per vague "credit," applies a made-up rate card, or does not price at all because the underlying resource is not priced to it either.
4. The free grant is a growth mechanism. A large round-number giveaway, a referral bonus, or "+X for every friend who signs up" is a pool-filling incentive, not a vendor onboarding credit. Vendor credits are usually small, dated, and tied to an identity.
5. Operator anonymity. No company name, no registered address, support only through a chat handle. We record this per entry in our directory, because it directly determines whether there is anyone to hold accountable.
6. Status that flickers. Relays publish no uptime history because they have no control over their input. If the status page is a manually updated message, that is the whole reliability story.

Why relays break — four failure modes

This is not a complaint about quality. It is a description of the architecture.

1. Every upstream change is a breaking change

The consumer app changes its login flow, adds a captcha, rotates a token, tightens a per-session rate limit, or tweaks a UI element the relay scrapes — and the relay stops working, sometimes mid-request. There is no coordination, so there is no deprecation window. The failure lands on you, in production, at whatever hour the upstream deployed.

2. The session pool is finite and contested

N relay users drawing on M shared sessions means your effective rate limit is roughly M divided by N, further divided by whatever else those sessions are doing. That number moves as the operator adds or loses accounts, as upstream friction increases, and as other users hammer the same pool. Throughput on a relay is not a configuration value; it is a competition.

3. Credentials die

Password changes, two-factor prompts, device revocations, and upstream "suspicious activity" locks all kill sessions. The operator has to replenish the pool continuously, and replenishment at that scale is itself a detectable pattern. Every replenishment is a race against a detector.

4. The vendor eventually cuts them off

This is the endgame, not a tail risk. Automated traffic on consumer sessions is exactly the pattern abuse detection is built to find. When it is found, the pool is revoked and the relay dies overnight with no notice — because there was never an agreement that required notice.

The practical consequence: if you have built on a relay, assume any of the four can happen on any given day. The correct architecture is relay as one fallback, never as the primary — which is the design that a free-first router exists to support.

The terms-of-service risk, and whose risk it actually is

This is the part people underweight, because it is split between two parties who would both rather not discuss it. Start by reading the actual clauses. OpenAI's consumer terms state that you may not "share your account credentials or make your account available to anyone else" and that you are responsible for all activity on the account (OpenAI Terms of Use↗). The same company's business terms for API customers are equally direct: customers must not "share Account access credentials or individual login credentials between multiple users" (OpenAI Services Agreement↗). Google's terms of service similarly restrict access by means other than the interfaces it provides (Google Terms of Service↗).

Those clauses are not unusual. They are the industry norm, and they prohibit precisely the two things a relay does — credential sharing and automated access. Now split the exposure:

The operator is the primary violator. It runs the pool at scale. It holds the credentials. It is the party whose conduct the vendor's terms are aimed at, and it is the party that can be pursued.

But your traffic is in the middle of it. The requests flowing through that borrowed session are identifiable: an IP, a request pattern, prompt content, and a timing signature that belongs to your application, riding on a session that is not yours to lend. In the worst case the vendor does not merely kill the relay: it flags the associated sessions and traffic, which can take out the underlying consumer accounts and whatever identities sit behind them. You did not agree to that exposure, and you cannot negotiate it away, because you are not the vendor's customer.

And there is no recourse path. No contract with the model vendor. Your "agreement" with the operator is a landing page. When it breaks, or when your data is mishandled, there is no support queue, no service-level commitment, and no liability cap — only a dead URL and a closed chat handle.

The data-handling angle

Prompts and completions transit the relay operator's infrastructure. Their data policy, if one exists, governs what is logged, retained, and possibly reused. A relay that logs every prompt is not a hypothetical: we have read terms on a free inference service stating exactly that, and relay documentation tends to be far thinner than that. The honest summary is narrow and simple:

• Throwaway experiments on non-sensitive data: a calculable risk.
• Anything you would be sorry to see logged, retained, or traced: not a risk worth pricing, because you cannot price it.

If a relay sits in a pipeline that carries customer data, internal source code, unreleased product plans, or personal information, the data-protection question is not "is the relay trustworthy" but "can I describe this transfer to the people who own that data." In our experience there is no satisfactory answer.

Relay versus first-party versus licensed reseller

Dimension	Web-cookie relay	First-party free tier	Licensed reseller
Who pays the vendor	Nobody directly	You, in attention and lock-in	The reseller
Published per-model pricing	Rarely	Yes, on the provider's page	Yes
Service-level agreement	None	Provider's own terms	Usually contractual
Rate limit documented	Rarely; pool-dependent	Yes	Yes
Failure mode	Pool revoked or blocked upstream	Quota exhausted until reset	Rate limit or billing
Data policy	Opaque or absent	Provider's privacy policy	Contract terms
Recourse if it fails	None	Support channel	Contractual
Best use	Non-sensitive fallback only	Steady free traffic	Volume with accountability

A pre-flight checklist before routing anything through a relay

1. Classify the payload. Public, non-sensitive, disposable? Continue. Anything else? Stop here.
2. Find the operator. A legal entity, an address, a status page with history. If none exists, your only recourse is none.
3. Read the data policy. Specifically: what is logged, for how long, and who else sees it. If there is no policy, treat logging as unlimited.
4. Check the model list for guesses. Bracket tags or "(claimed)" suffixes mean the operator is inferring capability from a session it does not control.
5. Test the failure path before you depend on it. Kill the relay mid-run in staging and confirm your application degrades to another provider instead of losing the task.
6. Never let it be the only route. If your router cannot complete a request without the relay, the relay's next outage is your next outage.
7. Re-check it periodically. Relays die quietly. A URL that worked last month is not evidence that it works today.

How the directory treats relays

We do not exclude relays, because the informed choice belongs to the user. But we label them plainly, state the terms-of-service position in the entry instead of pretending it away, never recommend one as a primary route, and track their fragility with status probes so the listing tells you when one has already died. A dead domain we have found is a data point; a plausible landing page with no status history is not.

How we verified this

The terms-of-service clauses quoted in this article were read from the providers' own policy pages, linked inline, on 2026-09-17. The failure modes are structural properties of the mechanism, not measured incident statistics, and we have deliberately avoided quoting uptime numbers, user counts, or specific operators by name — we describe the pattern rather than accuse a particular service. The directory's per-entry risk rationale is based on the same reading of public documentation, and it is dated so you can tell how stale the reading is.

FAQ

Is a relay illegal to use? The clearer problem is contractual rather than criminal: it conflicts with the upstream provider's terms, which typically prohibit credential sharing and automated access. That is a breach of an agreement between the parties, not a criminal matter, and the practical fallout is loss of access rather than prosecution.

Does using an API-compatible front end hide my identity from the vendor? No. The vendor sees the requests arriving through sessions it knows, with timing and volume patterns that are not human. Compatible request formats do not make the traffic look like the consumer usage the free tier was designed for.

What is the cheapest legitimate alternative? A first-party free tier plus prompt caching. Providers publish real free allocations, and caching makes repeated context nearly free on some of them — see the DeepSeek cache-hit arithmetic for the worked numbers. It is meaningfully cheaper than paying for the same tokens, and it comes with an actual support path.

Can a relay ever be part of a production architecture? As a last-resort route behind a router, with no sensitive payloads and no expectation of continuity, yes. As a primary route or as the sole provider for a feature people depend on, no — you would be accepting an outage you cannot predict and cannot escalate.

How do I tell whether a free API is a relay or a real free tier? Look for the provider's own domain on the pricing and rate-limit pages, a named legal entity, and model names that match the upstream provider's own catalogue. A first-party free tier is documented by the company that makes the model; a relay is documented by a company that is borrowing it.