Simon Willison Exposes the Conflict Behind Cheap LLM Relay Access

Simon Willison has spotlighted a relay market where discounted LLM access can depend on pooled credentials, exposed bots, and payment fraud. His July 26 post points readers to an investigation by software engineer Matt Lenhard. That investigation describes a commercial supply chain serving developers, startups, and other buyers, primarily through Chinese-language communities.

The conflict is not simply between official APIs and cheaper competitors. It is between legitimate gateway technology and a resale market whose operators may conceal where their computing capacity comes from. Buyers see one compatible endpoint and convenient billing. They cannot easily verify whether the upstream access was purchased legitimately, harvested from another application, or obtained through fraudulent accounts.

That uncertainty pressures three groups at once. Model providers absorb unauthorized usage and chargebacks. Application developers face the risk that exposed endpoints will become relay inventory. Buyers send prompts, source code, and business data through intermediaries whose identities and data practices may be unclear.

Simon Willison Put a Hidden Relay Economy in View

The important change is visibility: a scattered abuse problem now looks like an organized market with specialized suppliers, infrastructure, and customers.

Willison did not conduct the underlying field investigation. His relay warning amplified Lenhard’s findings and connected them to a practical problem facing application developers. An exposed LLM feature no longer attracts only opportunistic abuse. It can supply a downstream business designed to monetize unauthorized access.

Lenhard published his investigation on June 28 after examining a Chinese-language forum where operators discussed relay terminology and methods. He says his interest began while working on an AI gateway that faced repeated free-credit and support-bot abuse. Conversations with other companies convinced him that the pattern extended beyond one service.

The report’s principal forum source ran from March 5 through June 23. According to Lenhard, the discussion attracted about 35,000 views and 190 replies. Those figures show interest within one community, although they do not establish the total size of the wider market.

A relay, sometimes called a transfer station, presents customers with an API endpoint that resembles a major model provider’s interface. Customers change an application’s base URL and submit a relay-issued credential. The relay then forwards each request to an upstream account or another intermediary.

This design hides considerable complexity. A customer sees a familiar model name, usage balance, and request format. Behind that interface, the operator can rotate credentials, route around rate limits, retry failed calls, or map one requested model to another.

Lenhard describes four broad layers. Card and account merchants source payment instruments or registered accounts. Account pools combine credentials and manage their limits. Consumer-facing relays package that capacity into a convenient service. Developers and commercial users buy the resulting access.

These roles can overlap. One operator may control both the account pool and the storefront. Another relay may purchase capacity from a separate pool without knowing every credential’s origin. That separation makes responsibility harder to trace when a provider detects abuse.

The market also appears to have consumer infrastructure beyond individual sellers. Lenhard reports price-comparison sites, affiliate programs, customer-support groups, and specialized gateway products. He says the ten busiest relays tracked by his team received 3.6 million combined monthly visits.

That traffic estimate comes from Lenhard’s research and should be treated as an attributed measurement. It does not show how many visitors became paying customers. It also cannot distinguish legitimate access from access ultimately supplied through fraud.

Still, the surrounding infrastructure matters. Comparison sites and affiliate programs reduce the effort required to find a relay. Standard software lowers the effort required to operate one. Account pools reduce the damage caused when any single upstream credential stops working.

This is why Willison’s intervention deserves attention. He reframed the relay market as an application-security problem, not merely a dispute over model pricing or geographic availability. Any product exposing costly inference can become an involuntary supplier.

The strongest lesson is also the simplest. An LLM endpoint does not need to reveal its provider key to create risk. If outsiders can send unmetered requests through it, the endpoint itself effectively becomes a reusable credential.

Cheap Tokens Create Pressure Across the AI Supply Chain

Relay demand turns every weak spending control, open chatbot, and poorly protected application into potential inventory.

The most immediate pressure falls on model providers and the companies paying their bills. Free trials create a customer-acquisition channel, but automated registrations can convert those credits into resale capacity. Chargebacks can shift already-consumed inference costs back to providers or merchants.

Stolen cards create a more direct form of loss. The account may remain active long enough for a relay to consume its available capacity. By the time the cardholder or issuer disputes the transactions, the model output has already been delivered downstream.

Prepaid and virtual cards complicate risk decisions without proving misconduct by themselves. Many legitimate customers use both products. Providers therefore need to combine payment signals with account age, request behavior, device information, and network patterns.

Application companies face a different problem. A public support assistant, writing feature, or document-analysis endpoint may forward requests using a company-controlled account. If that endpoint lacks authentication or strict limits, an attacker can wrap it in another service.

The attacker does not need to extract the underlying key. Instead, the attacker reproduces the application’s request format and sends unrelated prompts through its backend. The application becomes a proxy while its owner receives the bill.

Willison says this possibility makes him more cautious about publishing his own LLM-backed applications. He wants provider-side controls that stop an application when spending reaches a developer-defined threshold. Alerts are helpful, but an alert arriving after a burst does not prevent the loss.

This concern grows as AI agents increase request volume and concurrency. An interactive chatbot may send one request after a user action. A coding agent can make repeated calls, attach extensive context, and continue working with limited supervision.

Concurrency can also defeat a basic balance check. Several requests may begin while an account remains below its limit. If the system records their cost only after completion, the combined usage can pass the intended ceiling.

A safer design reserves budget for every in-flight request. It also applies limits by account, credential, endpoint, and time window. These controls reduce the damage from both relay abuse and denial-of-wallet attacks.

Denial of wallet describes requests intended to consume another party’s paid API allowance. Unlike resale, the attacker may have no downstream customer. The technical weakness remains similar because the target accepts costly work without adequate authorization or limits.

The pressure then moves toward smaller application teams. Large model providers can maintain payment-risk systems, fraud teams, and extensive behavioral telemetry. A startup adding one AI support feature may lack all three.

Developers need to treat each public AI function as a metered financial interface. Authentication alone is insufficient when attackers can create many accounts. Per-user limits alone are insufficient when requests share a single organizational budget.

Input restrictions can help, but they need server-side enforcement. A browser interface that accepts only support questions may still call a backend capable of processing arbitrary text. Attackers can bypass the interface and invoke the underlying request directly.

Teams should also separate experimental credentials from production accounts. A leaked test route should not expose an organization’s full spending capacity. Narrow permissions, model restrictions, and independent budgets reduce the consequences of a missed control.

This work creates friction for legitimate users. Strict identity checks can block customers who lack supported documents or payment methods. Aggressive network filters can punish travelers, shared offices, and privacy-conscious users.

That tradeoff helps explain persistent relay demand. Some buyers want lower operating costs. Others want models unavailable through local official channels. Some seek an OpenAI-compatible endpoint that works with existing developer tools.

Those needs do not make every buyer complicit in upstream fraud. However, an unusually cheap service with unclear ownership transfers significant risk to the customer. Convenience can conceal unreliable access, substituted models, or unprotected data.

One API Endpoint Can Hide Hundreds of Credentials

The relay mechanism works because standard gateway features can separate the customer experience from the source of every upstream request.

Lenhard says most relays he examined used one-api or new-api. Both are open-source gateways that can place several model providers behind a single compatible interface. They are legitimate products with common internal and enterprise uses.

The gateway software supports multiple providers, token management, channel groups, model mapping, retry behavior, and load balancing. A company can use those functions to centralize credentials while giving employees narrower access tokens.

Its documentation also tells users to follow provider terms and applicable laws. The software is therefore not evidence of fraud. The relevant question is how an operator obtains the upstream accounts placed inside its channels.

New API extends the same general architecture. The project describes itself as a gateway for aggregation, organizational authentication, usage analysis, and private deployment. Its gateway fork adds payment, accounting, permission, and routing features useful to authorized service operators.

New API also states that upstream keys and accounts must be lawfully obtained. It warns public service and resale operators to meet authorization, licensing, logging, identity, payment, and regulatory obligations. These notices distinguish the software’s intended uses from abusive deployments.

A relay operator begins by configuring channels. Each channel points toward a model provider, application service, or another pool. The gateway assigns credentials to those channels and chooses one when a customer submits a request.

Routing turns unreliable credentials into a more stable product. When one account hits a rate limit or gets suspended, the system can attempt another channel. Weighted routing can favor sources that appear cheaper or more reliable.

The gateway then records usage against the customer’s relay balance. This accounting layer does not reveal what the upstream provider charged. It only reflects the operator’s own rules, multipliers, and model mappings.

That separation creates the central information gap. A customer requesting a named frontier model cannot independently see which upstream account handled the call. The customer may also struggle to confirm that the requested model produced the response.

Model mapping is useful in legitimate deployments. An enterprise can move traffic between compatible systems or provide a stable internal model name. A dishonest operator can use the same feature to substitute a cheaper model while preserving a premium label.

Simple output testing does not fully solve this problem. Closely related models can answer common prompts similarly. Providers can update models without changing every public label. Relay operators can also route only selected requests to the promised model.

The proxy sees the complete request because it must forward that request upstream. For coding tools, the payload may include repository files, architectural notes, debugging logs, and system instructions. For business applications, it may contain customer records or internal documents.

A legitimate enterprise gateway operates under the organization’s control and security policies. An unknown relay creates another data processor outside that boundary. Buyers need to trust its retention, access, encryption, incident response, and deletion claims.

The relay may also forward requests across several providers. Failover improves availability, but it expands the number of systems that might receive the prompt. Customers cannot evaluate that exposure without accurate routing and data-handling disclosures.

This distinction matters for open-source policy debates. Blaming one-api or new-api would confuse capability with conduct. Web servers, payment systems, and load balancers also support lawful businesses and abusive operations.

The better response focuses on credential provenance, authorization, and observable behavior. Providers can detect related accounts, unusual request patterns, payment anomalies, and rapid consumption after registration. Application owners can restrict what their own endpoints accept.

Open-source maintainers can support defensive administration without trying to police every deployment. Secure defaults, prominent setup warnings, audit logs, spend controls, and clear model-routing records make legitimate operation safer. They do not eliminate determined misuse.

The software’s neutrality is precisely what makes the story important. Relay operators do not require specialized underground infrastructure. They can assemble storefronts using the same gateway patterns that enterprises use for governance and cost control.

The Discount Can Conceal Fraud, Substitution, and Data Exposure

A relay customer is not only buying uncertain capacity; the customer is trusting an intermediary with model identity, uptime, and every submitted prompt.

Lenhard identifies several reported sources of relay inventory. They include mass-created trial accounts, chargeback activity, stolen payment cards, prepaid accounts, and open application endpoints. The mix likely varies across operators and time.

His investigation does not independently prove that every tracked relay uses those methods. Nor does the presence of a discount establish fraud. Authorized resellers, regional providers, and businesses with negotiated capacity can offer legitimate savings.

The scale of some reported discounts nevertheless creates a provenance question. Sustainable service requires someone to pay for computing resources, accept lower margins, or obtain capacity through a special agreement. Buyers should ask which explanation applies.

A credible intermediary should identify its legal entity and provide clear service terms. It should explain which providers supply the models and whether resale is authorized. It should document prompt retention, subprocessors, incident reporting, and account termination.

Buyers should also demand reliable model verification. A display label inside a relay dashboard is not enough. Output quality can fall if the operator substitutes a smaller model, routes overloaded channels, or changes providers without notice.

Model substitution creates more than a performance issue. Teams may evaluate an application using one model and unknowingly deploy with another. Safety behavior, context handling, tool use, and structured output can then change without a code update.

Availability carries similar uncertainty. Credential pools can hide failures for a while because traffic moves to surviving accounts. However, coordinated provider enforcement can disable many related accounts at once.

A relay can disappear with its customer balances and operational history. Buyers may have limited contractual remedies, especially across jurisdictions. That makes the apparent savings difficult to compare with the cost of interruption or migration.

Privacy presents the deepest concern. Every prompt passes through infrastructure controlled by the relay or its upstream pool. Encryption protects traffic in transit, but the proxy must access the request content to forward or transform it.

Developers using coding agents may expose more than isolated snippets. Agent sessions can include complete files, dependency information, internal URLs, database structures, and authentication logic. Even harmless debugging requests can reveal how a system is organized.

A 2026 academic credential leakage study illustrates the broader weakness around LLM-connected applications. Researchers examined 444 iOS apps and found exploitable credentials in 282 of them.

The researchers identified three leakage patterns. JWT-based token exposure accounted for 48 percent, unauthenticated backend proxies for 33 percent, and plaintext API keys for 19 percent. Those categories show that an attacker can obtain capacity without finding a conventional provider key.

After responsible disclosure, the researchers rechecked the vulnerable applications three months later. Only 28 percent had fixed the reported issue, while 72 percent remained exploitable. Persistent backend and token-design problems slowed remediation.

That study does not prove that the relay operators in Lenhard’s report exploited those specific apps. It does establish a substantial pool of technically exploitable LLM capacity. Unauthenticated proxies are particularly relevant because they can be invoked without exposing a raw key.

Buyers also face legal and contractual uncertainty. A customer may not know that its requests violate an upstream provider’s terms. Yet an interruption can still affect the customer, regardless of who originally breached the agreement.

Geographic restrictions complicate the picture. Some users turn to relays because direct model access is unavailable in their region. Relays convert that unmet demand into a working endpoint, but they do not remove export, contractual, or regulatory constraints.

Model distillation adds another disputed dimension. Lenhard cites forum participants who claimed that some commercial buyers use relayed outputs to train domestic models. Those comments were translated from an operator community and were not independently verified.

Distillation itself is a broad technical practice. A smaller model learns patterns from another system’s outputs or related training signals. Whether a particular use is permitted depends on access terms, data rights, and the exact method.

The most defensible conclusion is narrower than the most dramatic allegation. A relay creates an opaque control point between users and model providers. That opacity enables several risks even when the customer never intended to participate in fraud.

The Main Fight Is Legitimate Access Versus Hidden Provenance

The relay market’s defining conflict is not open source versus closed source; it is convenient access versus verifiable authorization.

Official APIs give customers a direct contractual relationship with a model provider. That relationship does not remove every privacy or reliability concern. It does establish clearer responsibility for billing, model access, security documentation, and support.

A relay inserts at least one additional party. Account merchants and pools can add more. Each layer can improve availability or local usability, but each layer makes provenance and accountability harder to inspect.

This opponent structure explains why price alone is a poor comparison. An official endpoint and an opaque relay may return syntactically similar responses. They do not offer the same chain of custody for credentials, prompts, model identity, or customer funds.

Authorized gateways occupy a legitimate middle ground. A company may centralize approved accounts to enforce budgets and observe usage. A regional provider may resell capacity under a documented agreement. An enterprise platform may route among models selected by its customer.

The differentiator is evidence. Authorized operators can disclose their upstream relationships, contractual role, security controls, and data practices. Customers can evaluate those claims through agreements, audit reports, documentation, and support channels.

Opaque operators ask buyers to infer legitimacy from uptime or community reputation. Neither signal proves authorization. A large credential pool can maintain availability even when individual accounts are repeatedly banned.

Community reviews can identify obvious scams, but reviewers cannot observe every upstream request. A relay may operate honestly during testing and change its sourcing later. It may also combine authorized capacity with questionable fallback channels.

Providers therefore face a difficult enforcement choice. Aggressive account controls can raise the cost of abuse. The same controls can exclude legitimate developers, particularly those using shared networks, international payment methods, or automated workflows.

Identity verification creates another migration effect. When direct accounts become harder to create, attackers can seek exposed application endpoints or established accounts. Lenhard predicts that stronger provider verification will push abuse toward the application layer.

That prediction should not be treated as guaranteed. Better controls can reduce overall abuse when providers share signals and improve spending limits. Attackers still move when one route becomes less profitable, so displacement remains a serious possibility.

Application owners need defenses that assume their endpoint will be tested. They should authenticate requests, enforce narrow schemas, limit concurrency, reserve in-flight spending, and reject prompts unrelated to the intended task.

Behavioral monitoring should examine account age, request timing, model selection, network signals, and abrupt changes in volume. No single indicator is decisive. Combined signals can separate ordinary use from automated extraction or resale traffic.

Teams should maintain emergency controls outside the affected application. A compromised service should not need to remain online before administrators can stop spending. Provider-level locks and independent budget controls offer a final boundary.

Organizations also need searchable operational records. Engineers investigating suspicious usage must connect deployment changes, alerts, invoices, and endpoint logs quickly. A structured engineering knowledge base can shorten that investigation without replacing security telemetry.

Buyers have a parallel responsibility. They should inventory which applications use relay endpoints and what data those applications transmit. Secrets, proprietary code, personal data, and customer documents should not cross an unverified proxy.

They should also design for exit. A compatible endpoint makes initial adoption easy, but model behavior and authentication details can still differ. Testing a direct provider or authorized alternative reduces dependency on one intermediary.

The goal is not to eliminate gateways. Gateways solve real problems involving authentication, budgets, routing, and observability. The goal is to make provenance and authorization visible enough that buyers can distinguish infrastructure from arbitrage built on abuse.

Three Signals Will Show Whether the Market Keeps Growing

The next phase will be decided by enforceable spending controls, migration toward application endpoints, and clearer proof of model provenance.

The first signal is whether major model providers introduce strict, immediate spending locks. A useful lock must stop new requests when a defined budget is exhausted. It should also reserve capacity for requests already running.

Willison specifically argues for keys that stop working at a developer-selected threshold. That feature would reduce the worst consequences of an exposed application. It would also constrain denial-of-wallet attacks and accidental agent loops.

Alerts alone will not satisfy this test. Providers need hard limits at useful scopes, including project, key, model, and time window. Customers should be able to configure them without building a separate billing-control system.

If strict locks become standard, the case for preventable losses will weaken. Relay operators could still exploit free accounts or stolen credentials, but each account would offer less usable capacity. Pools would need more inventory and greater operational effort.

The second signal is a rise in attacks against application-layer endpoints. Providers are increasing identity, payment, and behavioral controls around direct accounts. Attackers will test whether support bots, mobile backends, and public AI features remain easier targets.

Researchers can measure this shift through disclosures, honeypots, credential telemetry, and abuse reports. Application companies may also observe irrelevant prompts, unusual concurrency, continuous traffic, or requests arriving immediately after registration.

A clear increase would support Lenhard’s migration warning. Stable or declining application abuse would weaken it, especially if providers also report fewer fraudulent accounts. Public data will remain incomplete because many victims avoid disclosing losses.

The third signal is whether buyers demand verifiable routing and authorization. Relay directories currently compete heavily on access and reliability. The market could change if enterprise customers insist on signed provider relationships, model attestations, and auditable data policies.

Model provenance tools do not need to expose every secret credential. They could provide signed routing records, stable model identifiers, or customer-visible audit trails. Independent assessments could verify that an operator follows its declared routing policy.

If those practices spread, legitimate aggregators will become easier to distinguish from opaque relays. If buyers continue choosing endpoints without provenance checks, low-friction resellers will retain their information advantage.

Developers should act before those market signals become clear. Review every public LLM endpoint, including support tools and mobile backends. Apply hard concurrency limits and independent spending controls wherever the provider allows them.

Enterprise buyers should trace each AI request path from the user interface to the final model provider. If one intermediary cannot explain its role, treat that uncertainty as a security finding.

Simon Willison’s warning turns a remote gray-market story into a direct engineering question. Can your application stop abuse before its credentials, prompts, or budget become someone else’s inventory?