Free tier abuse on an AI or API product is a supply chain. Someone runs a script against your signup form, each account collects the credits you hand out, and those credits are consumed through a proxy that sells inference at a few percent of your list price. You see thousands of signups that never convert. The other side sees inventory.
This post covers the operation behind that traffic, what it earns per account, what each account costs you, and why the usual fixes are shaped for a different attacker. The short version: stop trying to keep scripts out of the signup form, and start deciding how much a brand-new account is allowed to burn before it has proven anything.
The credit farming operation
Okta's threat intelligence team traced one campaign against an AI video service: more than 105,000 automated signup attempts over three years from 251 IP addresses. The output was accounts. The write-up found those accounts advertised on underground forums for $40 in Tether apiece, and one seller pitched a freshly created account as better than a hacked one, because a hacked account was more likely to be shut down.
Downstream of the account farms sits the relay. Vectoral's write-up of the relay market describes it as a service that proxies traffic to U.S. models, often at a deep discount. The operator runs an open-source gateway, one-api or new-api, in front of a pool of dozens or hundreds of upstream accounts. Each request pulls a key from the pool, forwards it, returns the response, and deducts quota. When an account gets flagged, the gateway fails over to the next one. The same report lists the ways those accounts get funded: free-trial abuse with automated account creation, chargebacks after the usage period, stolen cards, and prepaid cards capped at a set limit.
The prices tell you what the pool is worth. One relay in that report offered $3,333 of official Anthropic credit for 425 RMB, under $60, and the cheapest tracked provider was discounting 97.8% off list. A separate survey of token brokers found storefronts, Telegram channels, and Reddit threads reselling credits at 30% to 80% off, with one broker claiming $100,000 a day of spending capacity.
Some of that inventory is real subscribers reselling what they paid for. In the Hacker News thread on the relay market, Aurornis argued the scale and discounts are impossible without mass automated fraud: they're doing chargeback fraud or using stolen credit cards. In the thread on the resale economy, RALaBarge summed up the supply side as standard botnet rings: accounts taken over, or carding rings loading stolen numbers to add credits.
The free-tier farm is the cheapest of these because nobody has to steal anything. Your signup form gives the credits away.
The unit economics on both sides
Work the farmer's ledger first, because it explains everything they do.
A CAPTCHA solve is a line item. 2Captcha publishes reCAPTCHA v2 at $1.00 to $2.99 per 1,000 solves and Cloudflare Turnstile at $1.45 per 1,000. A phone number that receives one verification code rents for a few cents on activation marketplaces. Disposable email is free. Residential proxy bandwidth is the largest cost, and it is amortized across thousands of accounts. Call it a few cents per account, all in, for a form with CAPTCHA, email verification, and SMS.
Against that, the payout. If you give a new account $5 of credit, and the relay sells at 5% to 15% of official per-token price, which is the range Okta observed at one relay branded "Poison Claude", each account grosses $0.25 to $0.75. That is still ten times the cost of making it. If your onboarding bonus looks like AWS's, where Okta documented $100 on signup plus another $100 for account activity, the account is worth $10 to $30 resold and $40 sold whole. At those numbers the farmer does not care what your signup form asks for. Every hurdle you add is a purchase order.
Now your ledger. Every credit a farmed account spends is inference you bought at full price, or GPU time you paid for yourself, and the person who used it will never be a customer. A farmed account converts at exactly zero, consumes the full allotment on day one, and adds a row to your growth chart that later has to be explained to an investor.
The farmer's marginal account costs cents and earns dollars. Your marginal free account costs you whatever you priced the credits at, and you priced them assuming a human who might pay.
Why signup-time defenses fail against scripts
Most advice for free tier abuse is a list of things to add to the signup form. CAPTCHA, email verification, phone verification, require a card. Each one is a fine defense against a person making a second account by hand. None of them is a defense against a script, because a script does not solve them. It buys them.
CAPTCHA is a price, and the price is above. Email verification checks that the address receives mail, which a disposable inbox does. Blocking known disposable domains catches the lazy operators and misses anyone who registered their own domain with a catch-all, which costs less than the CAPTCHA budget. Phone verification is the SMS line item.
Requiring a card is the one people are surest about, and it is the one I would push back on hardest. Privacy.com's free plan issues 12 new virtual cards a month, each with its own number and its own card fingerprint at your processor. Prepaid cards from a supermarket rack give you a new BIN and no chargeback risk for the buyer. Stripe's own rules documentation uses :card_funding: = 'prepaid' as its worked example of a review rule that is "too broad and results in too many reviews", and suggests narrowing it with :is_disposable_email:. That is the right instinct at the wrong layer. The farmer has a virtual card, a clean email, and a fresh proxy for every account. At the moment of signup, each account looks new because it is new.
Meanwhile the card requirement costs you the people you wanted. An indie developer who wants to try your API on a Saturday and hits a card form goes somewhere else. Your funnel loses real trials to stop an attacker who has a drawer of cards.
All four checks ask a question the account can answer at signup time. Scripts are good at answering questions. What they cannot do is share a device across a thousand accounts without leaving a trace, or spend credits without touching the one endpoint that costs you money.
Rate the cluster, not the signup
The mistake in the request-level view is treating each signup as an independent event. A farm is one operation with a thousand names. The useful question is how many accounts this operation has already opened here, and what they did.
That requires linking accounts across identity keys stronger than an email address. The device fingerprint from the browser that filled the form. The card fingerprint the processor hands back, which Stripe documents as a unique identifier for a given card number in a Stripe account. The phone number if you collect one. The payer wallet if you take agent payments. Any two accounts sharing one of these keys are the same operation until proven otherwise, and once one account in the group is confirmed abusive, the whole group is.
IP does not belong on that list. Carrier-grade NAT, university networks, and corporate VPN egress put thousands of honest people behind one address, and residential proxies put one farmer behind thousands. Count per IP as a soft signal and never let IP alone link two accounts.
With the graph in place, the numbers you want are counts per node. Signups per device this week. Accounts per card fingerprint. Credits burned per cluster in the first hour after creation. A real developer creates one account, pokes at the docs, and makes a few dozen calls. A farmed account makes zero dashboard visits and drains its allotment in a straight line. The 401st account from a device that has already made 400 is not a hard call. Neither is the 3rd account from a device that has made 2, once you know the first 2 were burned to zero and never returned.
This is the thing I built Portreeve for. One call at signup, trial_start, or checkout_attempt scores the event against a cluster with memory, linked across hashed device, card fingerprint, payer wallet, and phone, and returns allow, review, or block with reason codes in under 100 ms. It fails open by default, so an outage degrades to allow rather than breaking your signup form, and review never blocks anyone: the account proceeds and you get a signed webhook later if the cluster gets convicted.
Whatever you use, a new account inherits the reputation of everything it is linked to.
Gate the expensive endpoint, not the door
Once you are scoring clusters, the next question is where to enforce. The instinct is the signup form, because that is where the attack is visible. Resist it.
Blocking at signup gives the attacker a clean signal. They see a rejection, tweak the script, and try again with a fresh device profile, while you sit with a false positive rate you cannot measure because the rejected users never became anything. Letting the account exist and metering what it can burn inverts that. The farmer's script succeeds at every step, the account appears in their pool, and then the first inference call from an untrusted cluster returns a tiny quota. From the outside it looks like a working account with a broken free tier. It is expensive for them to debug and free for you to watch.
Put the verdict on the endpoint that costs money. For an inference API that is the completion route. For a data product it is the export. For a build tool it is the CI minutes. Let signup succeed for everyone. Then, per cluster:
- Unknown cluster, no history. A small, slow-refilling allowance. Enough to see the product work, not enough to resell. Most real prospects never notice.
- Cluster with a converted account or a real usage baseline. Full allotment.
- Cluster with a confirmed-abuse account. Zero. The account can log in, read the docs, and get a decline on the expensive call.
The verdict handling guide covers the three outcomes. The piece specific to farming is that the same review that is harmless at signup becomes the metering signal at the expensive endpoint. You can afford to flag aggressively there because a flagged real user gets a slightly smaller first-day allowance, not a rejection.
Two things make the device link stick. First, the browser fingerprint has to be collected at signup and in the dashboard, not only on the API path, because the API path is where the script lives and the browser is where a human would be. The device fingerprinting guide walks through the snippet and the short-lived device token. Second, feedback closes the loop: when you confirm a cluster was a farm, report it, so the next account that shares any key with it starts with that history.
Card testing follows the same logic in reverse: the attacker wants your checkout to answer a question about someone else's card, and the defense is to rate the device that is asking. If your free tier converts through Stripe, the card testing post covers the probe shapes from the same operators.
Agents pay too
A growing slice of API traffic is an agent hitting an endpoint, getting a 402, and paying per request. The x402 protocol formalizes that: the server answers with payment terms, the client signs a stablecoin transfer authorization, and retries with the signed payload in a PAYMENT-SIGNATURE header. No account, no email, no card.
In the relay thread, miohtama suggested that prepaid stablecoin purchases would solve the problem, no chargebacks. It solves the chargeback half. It does nothing for the farming half, because an agent that has learned your endpoint gives away a free first call, or a free tier keyed on a fresh wallet, can mint wallets as fast as a script can mint emails.
The fix is the same ledger with a different key. The payer wallet is an identity key exactly like a card fingerprint: hashed, linked, counted. Two accounts paying from one wallet are one operation. A wallet that funded a convicted cluster is blocked on sight, and a fresh wallet with no history gets the same small allowance as a fresh device. If you sell over x402, the middleware that validates the payment is the place to ask for a verdict, with the wallet as identity and the payment amount attached, before you do the work.
A sequence for this month
You do not need all of this on day one, and the order matters more than the coverage.
- Instrument. Log signups and first-hour spend per account, with the device fingerprint and, where you have it, the card fingerprint. You should be able to say how many accounts per device you saw last week and what they burned. If the answer is a flat line of one account per device, this post does not apply to you yet.
- Link. Build or buy the graph. Group accounts by device, card, phone, wallet. Look at the biggest clusters by hand. You will find the farm, and also your own QA team and a few families sharing a laptop, which is why the next step is not "block".
- Meter. Move enforcement to the expensive endpoint. Give unknown clusters a small allowance and convicted clusters nothing. Leave signup open. Farms drain and leave; humans come back tomorrow.
- Block. Only now, and only for the high-confidence shape: a new account on a device or card that already belongs to a cluster you have marked abusive. Everything softer stays at review, where it costs the user nothing.
Do the first two steps this week. The evidence they produce tells you whether your free tier problem is a farm, a handful of enthusiasts with too many accounts, or nothing. Fixing the wrong one is how founders end up with a card wall in front of a product nobody can try.
If you want the graph, the counters, and the verdict without building them, Portreeve's free tier covers 1,000 screened events a month with no card required. Create an account and put one call in front of the endpoint that costs you money.