The Discount API Sellers Are Reselling Somebody's Compromised Account. Probably Not Yours, Yet

If someone offers you frontier model access at ninety per cent off list, the discount is not a volume deal. There is no volume deal that size, and the arithmetic below shows why. What there is instead is a resale market in API access that providers do not authorise, and the terms you have already agreed to put the consequences of that market on the account holder, not on the platform. Two things to do this week: never route production through an undisclosed reseller, and audit your own keys, because your organisation is a supply source for that market whether you know it or not.

The market, and what part of it is checkable

A report published this week describes an ecosystem of "relays": OpenAI-compatible gateways that proxy requests to major models at steep discounts, drawing on pooled accounts sourced upstream. It describes free-trial farming, chargeback abuse and prepaid-card exploitation as the supply mechanisms, and names open-source gateway software as the plumbing. It is one account with no stated methodology, so treat its specific figures as reporting rather than measurement. The parts you can check yourself are the ones that matter anyway, and they are all in the providers' own documents.

Why the discount cannot be a margin

Our arithmetic, and it is short. A legitimate reseller buys at some price and sells above it. The cheapest honest structure in this market is a disclosed aggregator: OpenRouter states that it passes through "the pricing of the underlying providers without any markup" and takes its fee on credit purchases instead, 5.5% with an $0.80 minimum on standard payment methods, 5% on crypto. Bring your own key and the first million requests a month are free, then 5% of what the same model and provider would cost on the platform.

So the floor for an honest intermediary is roughly list price plus five per cent. Suppose a relay sells at ten per cent of list. To fund that, every dollar of tokens delivered has to be bought for ten cents. No provider sells at a ninety per cent discount, and no reseller can absorb the difference at scale. The gap has to be filled by credit that was never paid for: trial credit farmed at volume, credit bought with cards that were later reversed, or credit belonging to an account that is not the seller's. That is not a moral argument, it is an accounting one. A discount deeper than the honest intermediary's fee has to be financed by an unpaid bill somewhere, and the account that eventually eats it is a real company.

Five questions that separate an aggregator from a relay

1. Does it publish a fee model that reconciles with provider list prices? A disclosed aggregator can show you the arithmetic, because its margin is a fee on top. A relay's price is the whole pitch and the source is never named.
2. Will it accept your own key? Bring-your-own-key means the provider bills you directly and the intermediary is only routing. If the answer is no, you cannot be the account of record for anything.
3. Does it state a logging policy you could hold it to? OpenRouter publishes zero logging of prompts and completions by default, with a 1% usage discount if you opt in to logging. That is a specific, checkable commitment. "We do not log" in a Telegram message is not.
4. Is there an entity to sue? A company name, a jurisdiction, terms with a governing law clause. Crypto-only prepayment with no refund path is the tell.
5. What happens when the upstream account is cut off? Ask directly. If the honest answer would be "your service stops with no notice", you have found the actual product risk.

The reason not to use a relay is not mainly ethical. It is that your prompts, and whatever customer data sits in them, are travelling through an intermediary with no accountable identity, which is the same exposure we mapped in where your code actually goes with AI coding tools, minus every contractual protection. If you want a genuinely lower bill, the legitimate lever is the one we priced in the open-weight cost map: pick a cheaper model, not a cheaper seller.

The clause that decides who pays

Anthropic's commercial terms are explicit on all three points that matter here. Section D.4: a customer "may not...resell the Services except as expressly approved by Anthropic." Section D.5: "Customer is responsible for all activity under its account", with an obligation to notify promptly if the account "has been compromised, or is subject to a denial of service or similar malicious attack." Section I.3.a lets Anthropic suspend for risk to the service or breach of those sections, and states that Anthropic has "no liability for any damage...that Customer may incur because of a Service Suspension."

Read those together. If a key of yours leaks and ends up in a relay pool, the traffic is your activity, the bill is your bill, and a suspension triggered by it carries no compensation. That is the asymmetry worth designing around.

The key audit, in about thirty minutes

On Anthropic, the Admin API gives you the inventory. List every key with its status and workspace, and read the expires_at field on each: the documentation notes it is null for keys created without an expiration, which is what most keys are.

curl "https://api.anthropic.com/v1/organizations/api_keys?limit=100&status=active" \
  --header "anthropic-version: 2023-06-01" \
  --header "x-api-key: $ANTHROPIC_ADMIN_KEY"

Then work the list:

• Any key with a null expires_at and no owner you can name today gets set to inactive. The Admin API supports flipping status; it cannot create keys, which are Console-only by design.
• Check your leavers against the documented gap: the FAQ states that keys "persist in their current state as they are scoped to the organization, not to individual users" when a member is removed. Removing someone from the org does not revoke the key they generated. Add key revocation to your offboarding checklist as a separate line.
• Split by workspace so a leaked key from a prototype cannot bill your production budget, and review the five organisation roles: only developer and above can manage keys.

On OpenAI, the equivalent controls are in the production guide: keep keys in environment variables or a secret manager rather than in code, run separate staging and production projects with their own rate and spend limits, and set both a spend alert and a hard monthly spend limit, which the documentation says will "stop affected API traffic when tracked spend reaches the limit". Per-key usage tracking is available for keys created after 20 December 2023, so a key older than that is one you cannot attribute traffic to. Rotate it for that reason alone.

A hard spend cap is the single highest-value setting here, and it is the same logic as issuing one virtual card per vendor: the control that matters is not detecting the abuse, it is bounding what the abuse can cost before you notice.

One limitation to state plainly. None of this stops a determined attacker who has your repository. It stops the ordinary case, which is a key in a committed .env file, a key in a client-side bundle, or a key belonging to a contractor who finished in March. Those are the keys filling the pools, and they are the ones you can close this afternoon.