Free tiers & trial economics for agent products.
A SaaS free tier is bounded by human attention — a free user gets bored and closes the tab. An agent free tier is bounded by nothing, because your product's user is a loop that does not get bored, and the marginal cost of serving it is not the near-zero of a database read. Price the tier against the worst automated user rather than the median human one, meter work instead of time, and accept that the free tier is now a COGS line with a hard ceiling on it.
The thing that used to cap free usage was boredom.
Classic freemium works on an accident of human physiology. A free user of a project tracker can only click so much in an evening; the tail is short because attention is short. Every heuristic the SaaS playbook gives you — generous limits, unlimited seats on the free plan, no credit card required — is downstream of that accident, and agent products break it in a way that is easy to miss until the bill arrives.
- Your user is a scheduler. The moment your product exposes an API, a webhook, or a "run this nightly" toggle, consumption decouples from human presence. One free account can run continuously while its owner sleeps, and nothing about their intent is malicious.
- The tail is not a tail any more. In seat-based SaaS the heaviest free user might be 20× the median. In an agent product with automation available on the free plan, 1,000× is an ordinary Tuesday, and it is one account.
- Marginal cost is real and per-unit. A free row in Postgres costs approximately nothing. A free agent run costs tokens, tool calls, sandbox seconds, and a retrieval query, all of which someone invoices you for at the end of the month.
- Which means the free tier moved into COGS. It used to be a marketing expense with a rounding-error cost. It is now a variable cost line that scales with something you do not control, and it belongs in the same model as the rest of your unit economics.
Do the arithmetic once, with a non-zero cost per free user.
The number that decides everything is how many free users one paying customer funds, and most teams have never computed it because in their previous product it was infinite. Compute it explicitly, at your real prices, before you design anything.
- Start from one run, not one token. An agent task with a few dozen tool calls and a couple of hundred thousand tokens across its turns is not exotic; at frontier output-token prices that is on the order of tens of cents to a dollar. Ten free runs a day is then a meaningful monthly cost for one account that has paid you nothing.
- Divide by conversion, honestly. At a 3% free-to-paid rate, every converted customer is funding roughly thirty-three free accounts. If your gross margin target leaves you, say, twenty dollars a month of headroom per paying customer, the average free account must cost under a dollar a month — and "average" is doing dangerous work in a distribution with a 1,000× tail.
- Price the tier off the cap, not the average. Because the distribution is heavy-tailed, the only number you can actually commit to is the maximum a single free account can consume. Set that first; the average will land wherever it lands.
- Include the costs that are not tokens. Sandbox minutes, egress, vector search, third-party tool calls, and the eval traffic your own quality monitoring runs over free usage. The cost attribution discipline is what makes this line visible at all.
If you cannot state, today, what your single most expensive free account cost you last month, you do not have a free tier — you have an unpriced liability with a signup form in front of it.
Meter the unit your cost actually scales with.
Almost every agent free tier is metered on the wrong axis, and the wrongness is inherited: seats, days, and "projects" are the units of the products these teams built before. None of them correlate with what you pay.
- Time-based trials are the worst fit. "14 days free" prices the one input that costs you nothing and leaves consumption unbounded within the window. A scripted user extracts a year of value in a fortnight.
- Seats are equally decoupled. One seat can drive an unlimited number of agent runs. Seat limits protect a collaboration product; they protect nothing here.
- Meter work, at a unit the user can predict. Tasks, runs, or tool calls are legible to a customer and roughly proportional to your cost. Raw tokens are proportional but illegible — nobody can plan against them, and a limit users cannot anticipate reads as a broken product rather than a quota.
- Cap concurrency and cadence separately from volume. The volume cap bounds the month; a concurrency limit and a minimum interval between scheduled runs bound the afternoon, which is what actually protects you from a runaway loop and from your own provider's rate limits.
- Degrade rather than cut off where you can. Route exhausted free accounts to a smaller model, shorter context, or a queue rather than a hard error. This preserves the demo, costs a fraction, and is the graceful degradation pattern applied to billing instead of incidents.
The abuse case sets the ceiling, and it is not always abuse.
The account that costs you the most is rarely an attacker. It is usually an enthusiastic developer who wired your free tier into a cron job, which is exactly the behaviour your marketing asked for. Design for it as capacity planning rather than as fraud.
- Deliberate arbitrage is a real and separate case. If your free tier fronts a frontier model, you are a free inference proxy, and someone will discover that. Signup friction — verified email, phone, or card-on-file with no charge — costs conversion and is nonetheless the standard answer, because the alternative is funding someone else's product.
- Multi-accounting is the failure mode that eats a well-designed cap. A per-account limit with frictionless signup is a per-signup limit, and signups are free. Whatever identity you can reasonably bind to is the real unit of your quota.
- Retries are your own abuse. A failing free run that retries three times costs four times as much and delivers no demo at all. Retry budgets belong inside the free tier's accounting, per idempotency & retries.
- Put a circuit breaker in the runtime, not in a report. A monthly spend review discovers the problem four weeks late. A hard per-account and global ceiling enforced at request time is the only control that works on something that can move 1,000× in a day — the kill switch argument, applied to spend.
Make the trial qualify, not just acquire.
Once free usage has a real cost, the trial has to earn it back in information as well as conversion. A trial that produces a signup and nothing else is now a purchase you made on the user's behalf.
- Spend the free budget on the moment of proof, not on breadth. Most agent products have one demonstration that converts — the first run that does the thing the user could not do before. Fund that generously and ration everything after it; a free tier that spreads its budget evenly usually funds neither the proof nor the habit.
- Ask for the expensive input up front. Connecting a repository, a mailbox or a data source is both the highest-signal qualification step and the thing that makes the first run worth watching. Users who will not connect anything were never going to convert, and they are cheap to identify before you have spent much on them.
- Treat trial cost as customer acquisition cost, and compare it. If a converted customer cost forty dollars of free inference and your paid ads cost sixty, the free tier is efficient marketing and should probably be more generous. If it cost four hundred, it is a channel you would never have bought deliberately. This is the ROI measurement question pointed at your own funnel.
- Watch the free tier that competes with your paid one. If free usage is sufficient for a real workload, you have priced your own product at zero. The right free allowance ends slightly before the habit does.
Instrument it so the tier can be changed with evidence.
Free-tier limits get set once in a launch meeting and then defended with anecdotes for two years. The instrumentation that prevents that is the same per-tenant cost view you need for paying customers, extended to accounts that generate no revenue.
- Cost per free account, as a distribution. The mean is nearly useless here. Track the p50, p99 and max, and put the max on the same dashboard as revenue — it is the number that moves without warning, and the per-customer economics view is what surfaces it.
- Cost per converted customer, by cohort. Total free spend attributable to users who later paid, versus those who did not. This single ratio decides whether the tier should be widened or narrowed, and almost nobody computes it.
- Tag free traffic at the request level. Tenant, plan, feature and model version on every call, so the free-tier line can be separated from production spend without a reconstruction exercise at month end. Free and paid traffic sharing an untagged pool is the most common reason this analysis never happens — the isolation argument in multi-tenancy for agents.
- Write down the condition that closes the tier. A number, agreed in advance: free spend exceeding some share of gross margin, or a converted-cohort ratio below some threshold, for two consecutive months. Without it the decision arrives as a panic during a cost review, which is how a tier gets cut overnight and takes the top of the funnel with it — the mistake catalogued in scaling back an agent deployment.
Do this today, before any pricing discussion: sort last month's free accounts by cost and look at the top ten. If the most expensive one cost more than a paying customer generates, your cap is missing rather than too high — ship a per-account ceiling this week and set its value from the p99, not from the mean. Then compute free spend attributable to users who converted versus users who did not; that one ratio will tell you more about whether the tier works than any amount of funnel analysis.
Related: pricing & packaging agent products for the paid side of the same decision, where the economics breaks for the other places unit economics invert, and cost & quota UX for showing a limit to a user without making the product feel broken.