Research-backed calculator guide

How Much AI Usage Should a SaaS Plan Include? A Margin-Safe Allowance Method

Learn how to set an AI SaaS included usage allowance from model cost, target margin, customer usage percentiles, and a clear overage policy.

Why an allowance should be a calculated policy

An included allowance is a promise about cost exposure. “Unlimited” hides the promise, but does not remove it. If one customer sends ten times as many requests as another, a flat plan transfers that difference to your gross margin. AI products also have more cost variation than a simple request counter suggests: a short classification call and a long agent run may both look like one action in the interface while consuming very different tokens, tools, or compute.

A good allowance therefore has three layers:

1. A customer-facing unit. Use requests, tasks, credits, minutes, pages, or another unit that maps to value.
2. An internal cost map. Record model, input tokens, cached tokens, output tokens, tools, retries, and infrastructure for each event.
3. A commercial boundary. Decide what happens at 80%, 100%, and 100% plus usage: alert, throttle, hard stop, upgrade, or paid overage.

Do not begin with the average user alone. Averages can be pulled upward by a small group of power users and can hide an unprofitable tail. Export at least one full billing period of paid-user events, group them by account, and calculate both the distribution of usage and the distribution of cost. If your product is new, use a clearly labeled estimate from a pilot cohort and plan a review after enough real usage has accumulated.

For an implementation overview, the AI SaaS unit economics guide can hold the broader feature-level COGS model, while this page focuses on the included-usage decision inside one plan.

The margin-safe allowance method

1. Define the billable unit

A credit should represent a repeatable amount of value. “One AI response” is easy to explain, but it can be too broad if responses vary substantially. A better internal definition might be “one standard response up to 2,000 input tokens and 500 output tokens,” with heavier workflows charged more credits. You can still display “900 credits” to customers while retaining a cost-aware ledger behind the scenes.

Write down what happens when a request fails. If a provider timeout causes a retry, decide whether the customer sees one action while your ledger records the extra provider attempt. If a tool call adds cost, decide whether the tool is included in the same credit or consumes a separate unit. These are product-policy decisions, but they change the unit cost used in the allowance formula.

2. Calculate cost per unit

For a token request, use:

request cost = normal input tokens × input rate + cached input tokens × cached-input rate + output tokens × output rate + tool and infrastructure cost

Divide token quantities by 1,000,000 when rates are quoted per million tokens. Use the actual provider rate card for the model and date being modeled. OpenAI’s current pricing page, for example, labels prices as dollars per one million tokens and separately lists input, output, and cached-input prices.^[1] If your system can route requests across models, use a weighted mix instead of choosing the cheapest model by default:

weighted unit cost = sum(model share × model-specific unit cost)

Add an explicit retry or variance factor. A 1.2 factor means your expected cost is multiplied by 1.2; it is an assumption for uncertainty, not a vendor quote. Keep it visible so finance and engineering can replace it with observed retry and tool costs later.

3. Set the cost budget for the plan

Start with the plan price P and target gross margin G. The maximum variable cost at that margin is:

maximum variable cost = P × (1 − G)

Subtract variable costs that are not in the model-token estimate. Depending on your accounting policy, this may include payment fees, per-task infrastructure, storage, support usage, or third-party tool calls. Do not subtract fixed payroll twice. The result is the AI and usage budget available for included consumption.

Then apply a safety factor S, such as 0.80. The factor preserves headroom for usage spikes, provider price changes, estimation error, and customers who hit the cap earlier than your median. A safety factor is not a claim about what every AI company needs. It is a controllable risk preference that should be reviewed against observed margins.

included-cost budget = (P × (1 − G) − other variable cost reserve) × S

If the subtraction produces zero or a negative number, the plan cannot support included usage at the chosen price and margin. Raise the price, lower the target margin, reduce the cost of the workflow, or make the feature metered from the first unit.

4. Compare the ceiling with customer usage

Calculate each paid account’s monthly units, then choose a coverage percentile. P50 covers half of accounts; P70 covers 70% of accounts. The right percentile depends on the promise you want to make and the shape of your usage distribution. A lower percentile with transparent overage can be healthier than a high allowance that silently subsidizes heavy users.

The final allowance is the lower of the percentile-based allowance and the margin-supported ceiling. If P70 is 1,200 requests but the margin ceiling is 900, include 900 and explain the next step. If the margin ceiling is 1,500 and P70 is 1,200, include 1,200, then monitor the tail. This makes the plan generous relative to observed customers without letting a single percentile decision override unit economics.

Worked cost example

Assume the following for a professional plan:

• Monthly price: $49.00
• Target gross margin: 70%
• Other variable-cost reserve: $2.00 per customer per month
• Safety factor: 80% of the remaining budget
• Model: a token-priced model with $2.00 per 1 million input tokens, $10.00 per 1 million output tokens, and $0.10 per 1 million cached input tokens as recorded on the checked pricing page.^[1]
• Standard request: 2,000 input tokens, of which 200 are cached, plus 500 output tokens
• Retry, tool, and variance factor: 1.20

The vendor rates above were observed on 2026-11-02. They are inputs to this estimate, not a quote or a promise that the rate will remain unchanged; re-check the provider page before publishing a price.

The standard request’s expected provider cost is:

• 1,800 normal input tokens × $2.00 / 1,000,000 = $0.003600
• 200 cached input tokens × $0.10 / 1,000,000 = $0.000020
• 500 output tokens × $10.00 / 1,000,000 = $0.005000
• Expected provider cost per request = $0.008620
• Fully loaded estimate after a 1.20 uncertainty factor = $0.010344

The plan’s maximum variable-cost budget at 70% gross margin is $49 × 30% = $14.70. After the $2.00 reserve, $12.70 remains for this AI workload. Applying the 80% safety factor gives $12.70 × 0.80 = $10.16. Dividing by the fully loaded request estimate gives $10.16 ÷ $0.010344 = 982.2, so round down to 980 requests as the mathematical ceiling. A cautious launch policy might round to 900 included credits to leave additional room for rounding and a small amount of unmodeled usage.

Suppose the measured P70 paid-user usage is 650 standard requests per month. The plan can include 650 credits if customer experience is the priority; it does not need to spend the whole margin ceiling. Suppose P70 is 1,200 requests. The 900-credit launch allowance is safer. The remaining 300 requests should trigger an upgrade path, a top-up, or an overage price that is at least high enough to preserve the intended contribution after provider and payment costs.

This example is deliberately narrow. It excludes fixed engineering salaries, acquisition cost, taxes, refunds, and annual-contract accounting. It also assumes every request fits the stated token shape. If your product has multiple workflows, calculate a separate cost for each and assign different credit weights rather than pretending that all requests are interchangeable.

Choose the edge policy before launch

An allowance is incomplete until the customer reaches its edge. A hybrid plan can provide predictable base revenue and bill excess usage, while a prepaid plan can stop or restrict usage when the quota is exhausted. Chargebee documents these as distinct patterns: hybrid pricing combines included usage with overages, purely prepaid pricing stops or alerts at the limit, and pay-as-you-go bills every unit.^[4]

For a paid self-serve tier, a practical policy is:

• At 80%, show an in-product notice and email the account owner.
• At 95%, explain the exact remaining balance and the price or effect of the next step.
• At 100%, either pause the expensive workflow, switch to a cheaper model, require a top-up, or apply a pre-disclosed overage rate.
• For enterprise, allow a negotiated commit or cap, but keep the same event-level ledger.

Do not promise that an alert fires at the exact moment a customer crosses a threshold. Stripe notes that usage events can be processed asynchronously and that actual usage or invoiced amounts can be slightly higher than a configured threshold.^[2] Its usage-alert documentation also describes alerts for notifying users, deprovisioning access, and triggering an upsell workflow.^[3] That is why the product should show current usage, the last-updated time, and a small operational buffer rather than presenting the threshold as a perfectly instantaneous stop.

Meter what you need to reconcile margin

Record each billable event with an account or subscription ID, timestamp, product action, model, normal input tokens, cached input tokens, output tokens, tool calls, retry status, credit debit, and an idempotency key. Keep the event history, not only the current balance. Stripe’s usage documentation describes recording usage throughout the billing period and warns that meter processing is asynchronous.^[2] Chargebee’s example similarly uses unique event IDs, timestamps, subscription references, and an aggregation rule for usage events.^[4]

This ledger serves three jobs. It settles invoices. It explains a customer’s remaining allowance. It lets you compare planned unit cost with actual cost by plan, feature, model, and account. If a plan looks profitable in aggregate but the top five percent of users consume most of the expensive workflow, the ledger gives you evidence for a tier change instead of a guess.

For a full monthly estimate that includes model, tools, and infrastructure, use the AI Agent Cost Calculator. If your provider invoice and internal meter diverge, the AI API invoice reconciliation calculator gives the finance team a separate reconciliation workflow. Model selection also matters; compare rates and token categories with the model pricing comparison before changing the unit-cost assumptions.

Review the allowance on a schedule

Review the allowance after the first meaningful cohort, after a material model change, and whenever the 95th-percentile account cost moves sharply. A monthly review is useful during launch; a quarterly review may be enough once usage is stable. Track at least:

• included-unit redemption rate by plan;
• cost per included unit and cost per active account;
• P50, P70, P90, and P95 usage by paid account;
• percentage of accounts reaching 80%, 95%, and 100%;
• overage acceptance, upgrade rate, and support contacts;
• retries, tool calls, cached-token share, and provider-price changes.

If most accounts never approach the allowance, the plan may be overprovisioned or the feature may not be valuable enough to drive use. If many accounts hit the cap and complain, first check whether the meter is understandable and whether power users belong in a higher tier. Do not simply raise the allowance until you have checked the cost distribution. Conversely, do not lower it solely because one expensive month looks unusual; investigate seasonality, abuse, failed retries, and data-quality errors first.

Frequently asked questions

How many AI credits should an AI SaaS plan include?

Include the lower of a measured paid-user coverage target and a margin-supported ceiling. Start with a clear unit, calculate its fully loaded cost, reserve headroom, and use a P60–P70 coverage point as an initial policy assumption. Recalculate after observing real account-level usage. There is no responsible universal number of credits because model, prompt size, workflow, price, and customer mix differ.

Should included usage be based on tokens or requests?

Use the unit customers can understand, but keep tokens in the internal cost ledger. Requests are simple when the workload is consistent. Credits or weighted tasks are better when one workflow is much more expensive than another. A token-only allowance can be precise for technical buyers but confusing for general users. OpenAI and Anthropic both distinguish token categories and cache treatment in their pricing documentation, which is why a request counter should not erase those internal differences.^{[1] [5]}

Is a hard cap or overage better for an AI SaaS plan?

A hard cap gives the clearest cost control and is often appropriate for free tiers or highly variable workflows. Overage gives paid customers continuity, but it requires a clear rate, alerts, and a way to prevent bill shock. A hybrid plan can combine a fixed subscription, included usage, and paid overage. The choice depends on how much spending control customers need and whether your system can meter and reconcile events reliably.^[4]

How do I price overage usage?

Start with the same unit-cost map used for the included allowance. Add payment, support, and expected failure or refund costs, then apply the contribution target you want for incremental usage. Do not price overage below the effective cost of the base allowance unless that discount is intentional and funded elsewhere. State whether overage is billed immediately, on the next invoice, or through prepaid top-ups.

What should happen when a customer reaches 80% of the allowance?

Show the balance, explain what one unit represents, and send an alert to the account owner. At 95%, make the next action visible. At 100%, follow the policy disclosed in the plan: stop, throttle, switch model, upgrade, or bill overage. Usage alerts are operational aids, not proof that enforcement is instantaneous; event processing can have latency.^[3]

How often should an AI SaaS allowance be changed?

Change it when evidence changes, not on a fixed promise to customers. Revisit after launch data, major prompt or model changes, a provider price update, a new tool integration, or a sustained shift in P90/P95 usage. Keep existing customer terms stable when possible and version the internal cost map so you can explain why a new tier or overage rate differs.