Most leaders read the token-reseller story, if they read it at all, as someone else's problem - a gray market in another country, buying access they would never touch. North Wayne read it as a mirror. The same machinery that lets strangers resell frontier models at 98 percent off is the machinery pointed at every "try it" box, free tier, and support bot a company ships. Her frame is the useful one: an exposed model is a payments endpoint, and it deserves the defaults you would give one. Here is where to put them. — Muximus
Most teams budget for AI the way they budget for electricity: usage times a rate, forecast the bill, move on. It is a tidy model, and it has one load-bearing assumption hiding inside it - that the only party spending the tokens is the company paying for them. A practitioner teardown that reached the Hacker News front page around July 26 is a good reason to retire that assumption. It documents, in structured detail, an entire industry built on other people spending someone else's tokens.
Before the framework, the evidence, because the framework only lands if the market is real.
The market is real, and it is organized
The report, by Matt Lenhard of Vectoral, maps the Chinese-language "relay" or transfer-station (中转站) economy that resells access to OpenAI, Anthropic, and Google models at steep discounts. A word of caution on the sourcing, because it matters: the piece rests on a long V2EX forum thread started by a man who runs a relay himself. That is an insider's sales pitch as much as a confession, and the loudest numbers in it are boasts. Read it the way you would read a vendor's own case study - useful for structure, suspect on the superlatives.
With that caveat in hand, the structure holds up. One package tracked in the report bought the equivalent of roughly $3,333 in official Anthropic credit for about 425 RMB - call it $60, a discount near 98 percent. That is corroborated inside the forum, where a price-comparison site that tracks the relays puts the effective rate at about ¥0.13 for a dollar of official credit. By Vectoral's own tracking - and that count is one careful observer's, not an audited figure - the cheapest relay ran 97.8 percent below list, and the ten busiest relays it follows pull a combined 3.6 million visits a month.
The supply chain runs four layers deep, and this is the part worth understanding, because it is the part that maps onto ordinary businesses. At the top, card and account merchants sell virtual credit cards built to pass Western billing checks, plus bulk-registered accounts. Beneath them, account pools aggregate hundreds of those accounts, handle failover as accounts get flagged, and expose a single clean API. Relays wrap that pool in a billed, consumer-facing product and compete on price. At the bottom sit the buyers - individual developers, small startups, mid-sized SaaS chasing cheap inference, and, the forum claims, operators distilling frontier models to train domestic ones, described there as a multi-billion-RMB business with top players earning six figures a day. Treat that last one as an unverified boast; it changes nothing about the argument.
Two facts from the teardown do the real work. First, the relays run on ordinary open-source gateways - one-api and new-api, the same neutral tools plenty of legitimate companies self-host to put their own accounts behind one billed door. The software is not the crime. It becomes a relay only when its channels are stocked with stolen, leaked, or pooled keys instead of the operator's own. Second, the discount is manufactured, not negotiated. It is assembled from stolen and virtual cards, bulk free-trial signups, and the exploitation of refund dynamics - ban an abusing account, get the money back, recycle the capital. This is not a bulk deal anyone earned. It is a fraud spread wearing the costume of a price.
The framework: an exposed model is a payments endpoint
Now the frame. That relay economy is the demand side of a market. The supply side - the thing that makes it possible - is every place a model is exposed to people who have not been strongly authenticated. Which means the interesting question for a leader is not "who is buying resold tokens in another country." It is "where does my product hand a stranger the keys to my meter."
The report names the ways that meter gets drained, and each one maps cleanly onto a surface most companies already run: free-trial abuse, where automated signups burn the credits handed out to win conversions; chargebacks and prepaid-card funding, where spend booked as revenue is clawed back or was never real; open-inference proxying, where a support chatbot with loose guardrails quietly becomes a free relay someone else resells; and the one with no financial motive at all, "denial of wallet" - flooding an endpoint with concurrent requests purely to run up the bill. One relay operator in the thread claimed his own service was hit with 20 terabytes of traffic on launch day. Take the number with the same salt as the rest, but the shape is not in dispute: a public model endpoint draws adversarial volume the way a public form draws spam.
The applicability test is a single question, and it is worth answering honestly before the next release ships. Does the product let a user reach a model before the business has verified who they are and capped what they can spend? A "try it" box, a free tier, a support bot, an AI gateway left on generous defaults - each one is a spend endpoint. If the answer is yes, the product is already in the target set. Nobody having found it yet is not a control.
The trade-off nobody prices in
Here is where the electricity metaphor finally breaks, and where most budgets go wrong. Electricity has no adversary. Nobody floods the grid to run up a stranger's bill for sport. An inference endpoint has adversaries, they are organized, and they are cheap to mobilize. The cost of treating a model like a utility is not a rounding error on the invoice - it is an uncapped tail risk sitting on a line item the finance team has modeled as smooth and predictable.
The move is not complicated, and it is not new. Treat an exposed model the way any competent team already treats an endpoint that moves money. No one ships a payment route without rate limits, spend caps, and fraud monitoring; an exposed model moves money on every call and deserves the same reflexes.
Two controls are load-bearing, and they come first, before the fancier detection work: hard spend caps with locks, and per-account concurrency limits with budget reserved for every in-flight request, so a burst of parallel calls cannot outrun the ceiling. Those two convert an unbounded liability into a bounded one. Denial-of-wallet and pooled-account abuse both die against a spend ceiling that cannot be raced.
The rest of the report's playbook is sound, and it stacks in the order abuse travels. Raise the cost of entry - make bulk account creation hard and cap what a fresh account can spend. Watch the money - flag prepaid and virtual cards, mismatched billing, small card-testing charges. Watch behavior - time from signup to first request, the model chosen, account age, proxy and VPN signals. Cluster accounts by shared IPs and device fingerprints to catch one operator wearing many faces. Start new accounts low and let them earn headroom with age and a verified card; add friction when risk rises mid-session; and when someone is caught, throttle quietly rather than hand them a clean error that tells them which signal to fix next time. None of it ends the game - fraud is cat-and-mouse and the report says so plainly - but it moves the economics until attacking costs more than it returns, which is the only durable win on the board.
One disclosure, because it belongs in the open: this is the kind of hardening VarOps builds and sells, so weigh the recommendation with that interest in view. It survives the weighing. The controls above are cheap next to a runaway inference bill and far cheaper at design time than bolted on after the first invoice nobody can explain.
The verdict
Do not budget for AI as if usage were the only variable. Any product that exposes a model to lightly authenticated users has shipped a spend endpoint, and the abuse market on the other side is mature, industrialized, and indifferent to which company it drains. Before the next model surface goes live, install the two load-bearing controls - hard spend caps and per-account concurrency limits with reserved budget - and treat the rest of the fraud playbook as the follow-on, not the afterthought. The party spending those tokens is already organized. The only open question is whether the endpoint facing it was built as if someone would try.
