Research-backed calculator guide
AI SaaS Free-Tier Limits: Cap the Subsidy Before It Becomes COGS
A provider-neutral method for setting AI SaaS free-tier usage limits from model cost, activation, conversion, and gross-margin payback.
Quick answer
AI SaaS free-tier AI usage limits should be set from the maximum subsidy you can afford per activated free account, not from a round number such as “100 messages.” Convert each user action into a billable unit, price the expected model and tool calls, and then compare three cases: median usage, a high-usage percentile, and the free user’s expected conversion value. A practical cap is the lowest limit that lets a new user experience the product’s core value while keeping expected free-tier cost below the acquisition and payback budget.
For a first model, use this sequence:
- Define the free user’s included job, such as 20 text generations or 10 document analyses per month.
- Estimate cost per job from input tokens, output tokens, retrieval, tool calls, and retries.
- Multiply cost per job by the expected free usage distribution, not just the average.
- Add a conversion credit only if there is evidence that free usage creates paid customers. Treat that credit as an estimate, not revenue already earned.
- Set a soft warning, a hard cap, and an upgrade path. Review the cap after observing real usage and gross margin.
The key distinction is operational. Your product limit controls how much subsidy one account receives. A provider’s RPM, TPM, or account quota controls whether your backend can serve traffic. They are related, but they are not the same limit.
Why a free AI tier can become COGS
A conventional SaaS free plan often has a low marginal cost per extra user. An AI feature can behave differently because each user action may trigger inference, embeddings, retrieval, a tool call, an evaluation, or a retry. If those actions are bundled into an unlimited plan, an unusually active account can consume like a small cohort while paying nothing.
That does not mean every free user is unprofitable. It means the unit of risk is the free account’s usage distribution. A free plan can be a rational acquisition channel when the first useful experience increases activation, referral, or paid conversion. It becomes uncontrolled COGS when the product gives away expensive work without measuring whether that work improves one of those outcomes.
The first accounting step is to separate a vendor’s consumer product limits from your own API economics. OpenAI’s ChatGPT Free Tier FAQ says free users can access multiple capabilities, but that tools such as file uploads, image generation, voice, and data analysis have separate usage limits and that available limits can change over time [1]. That is useful evidence for a product-design principle: one global message counter is often a poor proxy for the actual cost of a mixed AI feature set.
For a SaaS product, record a cost event for every action that can spend money. A text reply may contain input and output tokens. A document answer may add extraction, embeddings, vector retrieval, and a longer context. An agent run may call a model several times and invoke search or code execution. “One request” is therefore not necessarily one unit of cost.
Build the limit from a cost-per-job model
Start with a named job rather than a vague message count. For example, call the free-tier unit a “support answer” and define the expected path: 2,000 input tokens, 500 output tokens, one retrieval operation, and a 5% retry rate. The cost formula is:
expected job cost = model input cost + model output cost + retrieval/tool cost + retry allowance
If a job uses 2,000 input tokens and 500 output tokens, express each price in dollars per token rather than mixing dollars per million tokens with raw token counts. OpenAI’s published API pricing displays input, cached-input, and output prices per 1 million tokens, and it lists separate meters for some voice and tool products [2]. The same normalization works across providers even when a provider uses pages, minutes, credits, or calls instead of tokens.
Use three cost views:
- Expected cost: the median or mean job path used for a normal user.
- Tail cost: a p90 or p95 path that includes longer prompts, larger documents, or more retries.
- Maximum exposure: the hard cap multiplied by the most expensive allowed job path.
The expected view helps with plan economics. The tail view helps prevent a few heavy accounts from silently consuming the free-tier budget. The maximum view is a safety bound, not a forecast.
Inputs you should collect
Track free accounts by cohort and calendar month. Useful fields include account age, activated feature, included units, units consumed, input tokens, output tokens, tool calls, retry count, model route, conversion event, and paid-plan start date. If an account uses multiple features, allocate cost by feature instead of assigning all spend to a single “AI” bucket.
Do not use a provider’s public ChatGPT subscription as a direct estimate for your SaaS API bill. The products, entitlements, traffic shape, and billing meters differ. Use official API pricing for the provider route you actually call, then validate it against your invoice. The AI API invoice reconciliation calculator is useful when your modeled units and the provider’s billed units do not line up.
Worked cost example
Assume a US-focused B2B writing assistant offers a free plan. The product wants enough usage for a new account to complete a meaningful first task, but it does not want to promise unlimited generation.
The illustrative assumptions below are estimates for planning, not a vendor quote. They use a blended model route priced at $0.20 per 1 million input tokens and $1.00 per 1 million output tokens. The prices are deliberately labeled as assumptions; replace them with your dated provider rate card and invoice data. Assume each generation uses 2,000 input tokens and 500 output tokens. Add $0.001 for retrieval and $0.0005 for retries.
| Step | Assumption or input | Formula | Output |
|---|---|---|---|
| 1. Input tokens | 2,000 tokens/job at $0.20 per 1M | 2,000 / 1,000,000 × $0.20 | $0.0004 |
| 2. Output tokens | 500 tokens/job at $1.00 per 1M | 500 / 1,000,000 × $1.00 | $0.0005 |
| 3. Retrieval | One retrieval path | Stated estimate | $0.0010 |
| 4. Retry allowance | 5% expected retry cost | Stated estimate | $0.0005 |
| 5. Expected job cost | Sum of rows 1–4 | $0.0004 + $0.0005 + $0.0010 + $0.0005 | $0.0024 |
| 6. Free cap | 40 jobs/account/month | 40 × $0.0024 | $0.096 subsidy/account |
| 7. Tail allowance | 120 jobs at p95 usage | 120 × $0.0024 | $0.288 tail cost/account |
| 8. Free cohort | 10,000 activated accounts | 10,000 × $0.096 | $960 expected monthly subsidy |
The $0.096 figure is not the full cost of serving every registered account. It is the modeled AI subsidy for an activated account using the expected path. If only 35% of signups activate the AI feature, the expected subsidy across 10,000 signups is $336 before support, storage, moderation, payment, and non-AI infrastructure costs. That distinction matters when marketing reports signups but finance reports activated accounts.
Now add conversion. Suppose 2% of the 10,000 activated free accounts convert to a $30 monthly plan, and the plan’s contribution margin before acquisition cost is 70%. The estimated first-month contribution is:
200 paid accounts × $30 × 70% = $4,200
Against the $960 modeled AI subsidy, the ratio is attractive in this scenario. But the result is not proof that the free tier “pays for itself.” It excludes support, infrastructure, sales cost, refunds, taxes, churn, and future months. It also assumes the 2% conversion would not have happened with a smaller free allowance. The correct comparison is incremental conversion: compare a 40-job cohort with a smaller-cap cohort or a control group.
A more conservative payback test sets a subsidy budget per activated free account. If the team can afford $0.15 of expected AI subsidy per activation for acquisition, the 40-job cap passes at $0.096. If p95 usage is 120 jobs and that tail is common rather than exceptional, the cap needs a second control: a warning at 30 jobs, a hard stop at 40, or a lower-cost fallback model after the warning.
Choose the right kind of cap
A good cap is understandable to customers and enforceable by engineering. You can cap jobs, tokens, credits, documents, minutes, or a combination. Pick the meter that best tracks your cost and that a user can predict.
A job cap is easy to explain when each job has a similar cost. It becomes misleading when a short rewrite and a 100-page analysis both count as one job. A token cap tracks model cost more directly but can be difficult for non-technical buyers. A credit cap can normalize multiple features, but the conversion from credits to work must be visible. A feature cap is useful when one action, such as deep research or image generation, is disproportionately expensive.
For mixed workloads, use a base allowance plus feature-specific budgets. For example, include 40 standard generations and 3 document analyses, then apply a lower-cost model or require an upgrade after either budget is exhausted. OpenAI’s free-tier documentation describes separate limits for several tools rather than one universal counter, which supports this product pattern [1]. Mistral’s pricing page also distinguishes free access from higher paid-plan allowances and notes different product capabilities and API charging units [3].
Use three customer-facing states:
- Inform: show usage used and remaining before the account reaches the cap.
- Protect: throttle or downgrade an expensive path while preserving a small useful action.
- Stop: return a clear limit message and an upgrade or reset date.
Do not call a product cap a “rate limit” unless it is actually a throughput restriction. A monthly allowance is a budget policy. A provider RPM or TPM restriction is a capacity policy. Your backend can have enough monthly budget but still fail during a traffic spike if it has insufficient request or token throughput.
Tie the cap to activation and payback
Free usage is valuable only when it changes a measurable business outcome. Define the activation event before choosing the number. It might be a completed workflow, a saved output, an invited teammate, or a second-week return. Then test whether additional free usage improves that event.
A simple experiment can compare 10, 20, and 40 included jobs. Keep onboarding and product quality constant. For each cohort, measure activation rate, time to first value, paid conversion, support contacts, AI subsidy, and 30-day retention. Calculate incremental contribution as:
incremental contribution = incremental paid contribution − incremental free-tier AI cost
If moving from 20 to 40 jobs increases activation but does not increase incremental paid conversion or retention, the extra 20 jobs are a subsidy without demonstrated payback. If the extra jobs increase conversion but push p95 accounts into a loss, keep the higher allowance only with a tail guardrail or a paid overage.
For broader model planning, the AI Agent Cost Calculator | Model Full Monthly Spend can help separate model, tool, and traffic assumptions. If AI usage reduces incidents or review work, compare that benefit separately with the AI observability ROI calculator; do not hide operational savings inside a free-tier conversion assumption.
Review limits without surprising users
Review the cap when any of four inputs changes: provider price, model mix, usage distribution, or conversion behavior. A lower vendor rate does not automatically justify a higher allowance. Cheaper inference can increase consumption, especially when users discover more expensive features. Conversely, a model migration can make a previously safe cap unprofitable.
Date every pricing assumption. OpenAI states that its API prices are per-unit and that API use is billed separately from ChatGPT subscriptions [2]. That is why a SaaS team should store the effective rate, currency, unit, model, and pricing date alongside each cost calculation. If you blend routes, record the traffic share for each route rather than reporting one unexplained average.
Set an alert threshold below the hard cap and inspect the p95 and p99 accounts. If one account consumes an entire cohort budget, investigate abuse, automation, shared credentials, or a legitimate high-value workflow. The response may be authentication, a higher paid tier, bring-your-own-key, an overage charge, or a product-specific cap. It should not be an arbitrary number chosen only because a competitor displays it.
FAQ
What is a reasonable free AI usage limit for a SaaS product?
There is no universal number. Start with a defined job, calculate its expected and tail cost, and choose the smallest allowance that lets a new user reach the activation event. A 40-job cap can be generous for short text generations and inadequate for document analysis. Publish the unit and reset period, then adjust from cohort evidence rather than copying a message count.
Should AI SaaS free tiers use tokens, messages, credits, or feature limits?
Use the meter that balances cost accuracy and customer comprehension. Tokens are closest to model billing but are hard for many users to predict. Messages are easy to understand but hide variable prompt length. Credits can combine models and tools if the exchange rate is documented. Feature-specific caps are best for expensive actions such as deep research, image generation, or large-file analysis.
How do I calculate the cost of one free-tier AI user?
Multiply each included action by its expected cost and sum the result. Include input and output units, retrieval, tools, moderation, and expected retries. Then calculate a tail case using a high usage percentile. Do not divide total monthly AI spend by all signups; use activated accounts and report the activation rate separately.
Should free users be allowed to exceed the AI usage cap?
Only when the extra usage has a deliberate funding path. Options include a paid overage, a lower-cost model, bring-your-own-provider key, a waitlist, or a reset after a defined period. “Unlimited” is a commercial promise, not a technical shortcut. If you cannot estimate the maximum exposure or explain who funds it, do not offer unlimited AI on the free tier.
Is a provider rate limit the same as my product’s free-tier limit?
No. Your free-tier limit controls account entitlement and subsidy. A provider rate limit controls throughput, such as requests or tokens in a time window. A user can be below your monthly allowance and still receive a temporary backend error during a spike. Track entitlement, spend, and throughput as separate fields.
When should an AI SaaS team raise or lower a free-tier cap?
Raise it when incremental usage produces measurable incremental activation, retention, or paid contribution after its full cost and tail risk are included. Lower it when the p95 cohort cost rises, the provider or model price changes, abuse increases, or conversion stays flat as allowance grows. Announce material changes, preserve existing users where practical, and show the reset date and remaining units clearly.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.