The Cheap AI Model API Test: A Founder Due-Diligence Gate for Token Relays

An investigation into the “token relay” market resurfaced this weekend, documenting services that sell access to well-known AI models at extraordinary discounts by pooling credentials from many sources. The reported sources include legitimate wholesale arrangements, but also consumer subscriptions, free trials, exposed support bots, shared sessions, stolen credentials, and payment abuse. The investigation is evidence that such a market exists; it is not proof that every discounted gateway uses the same methods or that every reseller is unauthorized.

That distinction matters to AI app builders. A compatible endpoint can return a convincing model response while hiding who owns the upstream account, whether the model is authentic, where prompts are stored, which contract governs the data, and what happens when the original provider revokes a credential. A cheap completion is not a verified supply chain.

For nontechnical founders and small product teams, the decision is not “Does the API work?” It is: Can this supplier prove its legal identity, authority to resell, credential path, data path, operating controls, and exit plan well enough for the information and customer promise your product puts through it?

This guide turns the current relay-market story into a founder decision gate. You will get precise terms, a nine-part supplier receipt, blocking rules, a 60-minute verification, a fictional document-assistant scenario, a decision matrix, incident steps, and clear cases where a relay or gateway may still be appropriate. It is not legal advice, a list of accused vendors, or a hands-on audit of any service named in the original investigation.

What the token-relay investigation actually shows

Vectoral’s original relay-market investigation describes an ecosystem of price-comparison sites, affiliate programs, gateway software, pooled credentials, and deeply discounted access to models from major providers. The author says the ten highest-traffic relays tracked by the research received a combined 3.6 million monthly visits. The article’s principal evidence is an operator discussion on V2EX, supplemented by relay directories, product pages, screenshots, and the author’s tracking.

The investigation identifies several possible sources of cheap capacity: formally purchased API supply, consumer plan credentials, free trials, support or coding products with weak metering, compromised accounts, and payment fraud. Those categories have very different legal, security, and reliability meanings. The existence of open-source gateway software does not prove misuse either; gateways can legitimately normalize APIs, route among accounts an organization owns, enforce budgets, and fail over between authorized providers.

Simon Willison’s July 26 analysis brought the research back into wider discussion. He highlights the application-layer risk: public AI endpoints can become inputs to a resale economy, turning one exposed credential or weakly capped feature into a potentially large bill.

Three evidence boundaries are essential:

• Vectoral reports a market and observed patterns; it does not establish the provenance of every token sold by every relay.
• A low price is a risk signal, not proof of theft, fraud, or contract breach.
• A response that looks like the named model does not prove the supplier used that model, used an authorized account, or applied the promised data controls.

The correct product response is therefore neither “all gateways are scams” nor “the endpoint passed a prompt test.” It is a documented intake decision proportionate to the data and business effect involved.

Define the supplier before you compare prices

Teams often call every OpenAI-compatible endpoint a “reseller.” That word hides the most important differences.

An authorized reseller is a named business that can show a current agreement or program authorizing it to resell a provider’s service under defined terms. Authorized resellers are not inherently suspicious. OpenAI’s Services Agreement explicitly recognizes purchases made through a reseller in its definition of an order form. The buyer still needs to know which entity invoices it, which terms apply, and who handles support and data.

A gateway is software or a service that receives your request and forwards it to one or more upstream models. A gateway may use accounts you own, accounts it owns with authorization, or an unknown credential pool. “OpenAI-compatible” describes an interface, not commercial authority.

A relay in this article means an intermediary that sells model access through credentials or accounts not issued directly to the buyer. That may be authorized, unauthorized, or unverified. The label describes the path, not a legal conclusion.

A consumer-session proxy converts access intended for an individual application or subscription into an API-like service. It may depend on browser cookies, login sessions, automation, or shared accounts instead of a provider-issued business API credential.

Credential provenance is the inspectable path from your request to the upstream authorization: credential type, account owner, provider or authorized channel, scope, environment, rotation authority, and evidence that use is permitted. Data path is every entity and system that can receive or retain the prompt, files, metadata, response, logs, and derived data. It is not the same thing as the model name.

These definitions prevent a common purchasing error: comparing the direct provider’s price and a relay’s price as if both offers contain the same identity, contract, privacy terms, observability, support, and continuity.

Why a working endpoint can still be the wrong dependency

A smoke test answers a narrow question: did this endpoint accept a request and return a plausible response? It does not answer six production questions.

Identity. Which registered entity is taking your money and accepting responsibility? A domain, Telegram handle, or payment wallet is not the same as a legal counterparty with a notice address. Authority. What permits that entity to provide the named upstream service? “We have many accounts” is not an authorization chain. OpenAI’s current agreement, for example, prohibits customers from buying, selling, or transferring API keys and from circumventing rate limits or protective measures. That does not decide the status of another provider or every arrangement, but it shows why the credential source changes the risk. Authentication. A provider-issued API key, a limited OAuth grant, a shared browser cookie, and a consumer login session are not interchangeable. The IETF’s OAuth 2.0 Security Best Current Practice focuses on token replay prevention, privilege restriction, client authentication, and safer authorization flows. A supplier that asks for your personal session cookie or an unrestricted credential is moving risk into an identity artifact that may grant far more than model inference. Data handling. Your prompt may pass through the relay’s edge, application logs, queue, abuse filters, observability service, upstream account, and support tooling. A direct provider’s DPA does not automatically extend to an unnamed intermediary. OpenAI’s current data-processing materials specify roles, subprocessors, security measures, deletion, and incident handling for covered customer relationships. If your contract is only with a relay, you need equivalent answers from that relay and clarity about whether the upstream terms apply. Continuity. If upstream accounts are pooled, one revocation can remove capacity without a normal deprecation window. The relay may silently switch models, regions, or providers to preserve availability. Your app can remain “up” while quality, safety, latency, or data location changes. Incident response. Can the supplier tell you which requests used an affected credential, stop the path, delete retained data, preserve logs, and notify you on a defined clock? If not, your team cannot answer customers when something goes wrong.

The issue is not that intermediaries are always bad. It is that every additional intermediary creates another claim that needs evidence.

Use the nine-part model-endpoint intake receipt

Do not accept a sales deck as the record. Complete one receipt for every provider, reseller, gateway, or relay before production data enters it.

NIST’s July 2026 Cybersecurity Supply Chain Risk Management Due Diligence Quick-Start Guide organizes supplier assessment around provenance, resilience, foundational cyber practices, supply-chain tiers, and ownership or control. A three-person startup does not need a federal procurement office, but it can use the same logic: identify the supplier, map who sits behind it, verify essential controls, and plan for failure.

OWASP’s LLM supply-chain guidance likewise warns that unclear terms and data policies, weak provenance, third-party platforms, and outdated components can create security, privacy, licensing, and availability failures. A relay adds an account and identity layer to those existing model-supply risks.

Store the receipt beside the product’s model configuration. Name an owner and review date. Marketing pages change; contracts, upstream programs, hosts, and credential paths change too. “Approved last year” is not evidence of the path today.

Apply five blocking rules before any pilot

Some gaps can be tested during a bounded pilot. Others should stop the evaluation before real prompts are sent.

1. Block personal or shared session credentials

Do not provide a founder’s login cookie, consumer-session token, browser profile, or shared password to a relay. Do not accept a production design that depends on the supplier doing the same on your behalf without documented authorization. Session artifacts can expose account history and functions beyond the model request, and their revocation can interrupt all dependent traffic.

2. Block unknown authority for a named model

The supplier does not have to disclose trade-sensitive pricing. It does need to provide credible evidence that it may deliver the service it sells. Acceptable forms can include a provider marketplace listing, named reseller program, contract representation backed by remedies, or use of a cloud marketplace under that marketplace’s terms. A logo collage is not evidence.

3. Block customer or sensitive data when the data path is incomplete

Until processors, retention, region, support access, deletion, and incident handling are known, use only synthetic inputs. Redaction reduces exposure but does not repair an unknown contract. If your product handles health, financial, employment, children’s, legal, authentication, or confidential business data, require specialized privacy and security review.

4. Block unrestricted credentials and unlimited spend

Anthropic’s API-key guidance says keys should not be shared, should be separated by purpose, monitored, stored as encrypted secrets, and rotated. Google Cloud’s API-key practices recommend service and application restrictions, isolation, monitoring, deletion of unused keys, and rotation. If a gateway uses a key you own, give it the smallest possible scope, a dedicated project, a hard spend ceiling, and a rapid revocation path. Never paste the key into a web form unless the vendor and secret-handling design have passed review.

5. Block unverifiable silent substitution

A multi-provider gateway may legitimately route between models. The product must know when that can happen. Require the actual route or a verifiable route class in logs, define which substitutions are allowed, and treat an undeclared model change as an incident. Compatibility at the JSON field level does not preserve safety behavior, tool use, context limits, latency, or output quality.

These are procurement gates, not accusations. A supplier can resolve a blocker by producing adequate evidence or changing the proposed design.

Run a 60-minute verification with synthetic data

Once the documentation gate passes, verify the operating claims without using customer information. The goal is not to reverse-engineer the supplier. It is to test whether the evidence you need exists in normal use.

Minutes 0–10: freeze the offer. Save the legal entity, pricing page, model name, endpoint host, terms version, privacy notice, support contact, and claimed retention. Record the date. Ask which company will appear on the invoice and card statement. Minutes 10–20: inspect the credential flow. Confirm whether you receive a project-scoped key, connect an account with OAuth, bring your own provider key, or send traffic through a supplier-owned pool. Record who can rotate and revoke each credential. Stop if the flow requires a personal cookie, shared account, browser profile export, disabled certificate validation, or installation from an unverified package. Minutes 20–30: inspect identity and routing. Resolve the documented endpoint, confirm HTTPS uses the expected domain, and send a harmless synthetic request. Capture request ID, response headers, reported model ID, region signal if supplied, latency, usage units, and error format. Do not claim model authenticity from writing style alone. Minutes 30–40: test limits and visibility. Create a small spend or usage ceiling. Verify that usage appears in a dashboard or export, that credentials can be separated by environment, and that a revoked test key stops working. Do not stress the service or bypass controls; use documented limits and a tiny budget. Minutes 40–50: test data rights. Send a unique synthetic marker, then request deletion through the documented process. The supplier may not offer an immediate self-serve result, but it should state what is deleted, from which systems, on what timeline, and what evidence it returns. Minutes 50–60: test support and exit. Ask a concrete incident question: “If an upstream credential is revoked after processing our requests, how will you identify affected request IDs, notify us, and confirm deletion?” Then exercise the fallback configuration with a non-sensitive test.

End with one of four results: pilot, hold for evidence, reject, or direct-provider only. “The prompt worked” is not a result.

A concrete scenario: the document assistant with a 90% discount

Consider a fictional two-person startup building an assistant that summarizes supplier contracts for small businesses. The product is still in private beta. A model relay offers access to the team’s preferred model at 10% of the direct API price and promises OpenAI-compatible integration in five minutes.

The founder first runs a public sample contract through the endpoint. The summary is strong, latency is acceptable, and the JSON schema parses. If the team stops there, the provider passes.

The intake receipt changes the decision. The invoice would come from an individual payment account rather than the company named on the website. The seller will not identify an upstream reseller program. It provides one shared bearer key for development and production. Its privacy page says prompts are “normally not stored” but gives no retention period, subprocessor list, region, deletion path, or incident contact. The model field echoes whatever model name the client sends. Support suggests using a browser cookie if the shared key becomes unstable.

None of those facts proves that the relay stole credentials or misrepresented every request. They do establish that the startup cannot verify authority, credential provenance, model identity, data handling, or recovery. Customer contracts must not enter the path.

The team chooses synthetic pilot rejected; direct-provider only and keeps the relay out of production. It then reduces direct-provider cost through smaller evidence packs, caching, workload routing, and output limits. If a later authorized marketplace offer supplies the same model with a clear contract and data path, the team can evaluate that offer separately.

Now change the scenario. The seller is listed in the model provider’s partner directory, the agreement names both commercial entities, credentials are project-scoped, prompts are covered by a DPA, the route is logged, deletion is documented, and the team can fail over directly. A discount may then reflect committed volume, regional distribution, cloud credits, or bundled infrastructure. The same gateway shape can be acceptable because the evidence is different.

Decide by data sensitivity and business effect

Not every experiment needs enterprise procurement, and not every endpoint deserves production trust. Use the smallest decision that matches the consequence.

Price should enter after the row is satisfied. A 90% discount on an unacceptable path is not savings. It is an unpriced liability. A direct provider can still fail security or reliability requirements, so “buy direct” is not a substitute for evaluation either.

The FTC’s small-business vendor-security guidance gives a useful general rule: put data use, sharing, retention, deletion, security, and changing controls in writing; verify rather than rely only on promises; limit vendor access; and be ready to cut access after a breach. Those steps apply even when no AI-specific law is involved.

Monitor the dependency after approval

Approval is a versioned state, not a permanent label. Watch for evidence that the path changed.

Track the contracting entity, endpoint domain, certificate, documented upstream route, model IDs, pricing, error shapes, latency, usage accounting, data terms, subprocessor list, and status feed. A sudden price collapse, new host, different invoice descriptor, unexplained model behavior, or request to replace a project key with a session artifact should trigger review.

Set three product alarms:

• Economic alarm: observed upstream usage and supplier billing diverge materially, or a promised hard cap does not stop requests.
• Identity alarm: model, provider, endpoint, credential type, or invoice entity changes without the agreed notice.
• Data alarm: retention, region, training use, subprocessors, deletion, or incident terms change.

Keep one non-sensitive canary request whose output has stable, machine-checkable properties. It cannot prove model identity, but it can reveal route changes, schema drift, missing tool behavior, and latency regression. Pair it with contractual and operational evidence.

Review higher-risk suppliers quarterly and after every material change. For a prototype, review before moving from synthetic to internal data and again before customer launch. Record who approved what evidence on which date rather than saying “engineering checked it.”

Respond when the relay path becomes suspect

If you learn that a supplier may use unauthorized, compromised, or misrepresented credentials, do not begin by debating blame in public. Contain the product and preserve facts.

1. Stop new sensitive traffic. Route to a verified fallback, degrade to a non-AI path, or pause the feature. Do not keep sending prompts merely to investigate.
2. Revoke credentials you control. Rotate gateway keys, provider keys, OAuth grants, webhooks, and secrets reachable from the integration. A relay credential and your own upstream credential are separate targets.
3. Preserve evidence. Save contracts, invoices, terms versions, request IDs, timestamps, endpoint hosts, model fields, routing headers, notices, and support messages. Do not retain more customer content than the incident requires.
4. Map exposure. Identify which users, tenants, prompts, files, secrets, and actions passed through the path, and during which window. Separate confirmed facts from possibilities.
5. Contact the supplier and relevant upstream provider. Ask for credential provenance, containment, affected requests, retention, deletion, and notification. Use official security or abuse channels.
6. Assess notification duties. Work with qualified counsel and security specialists when personal, confidential, regulated, or customer-controlled data may be involved.
7. Verify recovery. A new key is not enough. Confirm the old path is disabled, affected data is addressed, fallback behavior works, and the intake receipt is updated.

Do not secretly probe accounts you do not own, buy questionable credentials for testing, or attempt to identify other customers. The product team’s job is to contain its dependency and cooperate through authorized channels.

Where gateways and resellers can still be the right choice

The correct lesson is not “never use an intermediary.” A well-governed gateway can reduce integration work, centralize budgets, normalize observability, enforce policy, support regional routing, and give a small team a credible fallback. An authorized reseller can provide local billing, support, procurement, and committed-volume pricing that a direct self-serve account does not.

Use an intermediary when:

• its legal identity and commercial authority are documented;
• the credential and data paths are inspectable;
• its contract covers the product’s data and intended use;
• model substitution is explicit and bounded;
• per-project keys, limits, logs, deletion, and incident handling are available;
• a direct or alternate route is tested;
• the discount remains plausible after support, infrastructure, and commitment are considered.

Avoid one when the only advantage is a price that depends on secrecy, shared consumer access, unbounded credentials, geographic circumvention, or an unverifiable model label. Also avoid adding a gateway to a product that does not need multi-provider routing or consolidated controls; every dependency has a review and incident cost.

The due-diligence gate cannot prove that a supplier will never fail. It can make the authority, data path, controls, and exit promises explicit enough to test—and make a “no” decision before customer data pays for the uncertainty.

A 48-hour founder checklist

In the first hour: freeze the offer; identify the legal and invoice entities; classify the supplier as direct provider, authorized reseller, gateway, relay, or unverified; block personal sessions, shared cookies, transferred keys, unknown hosts, and customer data. By hour 4: request the nine receipt fields; compare the proposed credential path with upstream terms; map processors, region, retention, training use, deletion, and incident contacts; decide which missing fields are blockers. By hour 8: run the synthetic 60-minute verification; create a project-scoped key and tiny cap; capture request IDs and actual route evidence; revoke the test credential; exercise the fallback. By hour 24: complete the data-and-business-effect matrix; obtain specialist review where needed; name a supplier owner; record a pilot, hold, reject, or direct-provider only decision with evidence. By hour 48: if approved, release only to the named data class and traffic limit; activate economic, identity, and data alarms; schedule the next review; store the receipt and exit steps beside the model configuration.

One rule should survive every discount: never let API compatibility substitute for supplier identity, credential provenance, a knowable data path, and a tested exit.

References

1. Vectoral, An Inside Look at the Relay Market Powering Token Resellers and Fraud.
2. Simon Willison, An Inside Look at the Relay Market Powering Token Resellers and Fraud.
3. OpenAI, Services Agreement.
4. OpenAI, Data Processing Addendum.
5. Anthropic, API Key Best Practices.
6. Google Cloud, Best Practices for Managing API Keys.
7. IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security.
8. NIST, Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide.
9. OWASP GenAI Security Project, LLM03:2025 Supply Chain.
10. US Federal Trade Commission, Cybersecurity for Small Business: Vendor Security.