Guides

How to limit AI usage per subscription plan (free, trial and paid)

In short: decide what each plan gets (for example 10 AI messages a day on free, 500 a month on Pro), count every AI call per user on your backend, check the count before each call, and return how much is left so the app can show it. When the allowance is used up, answer with the paywall instead of the AI. The counting is easy. Knowing each user's plan at that moment, and resetting at the right time, is where most home-built versions go wrong.

A limit does two jobs. It caps what a free user can cost you, and it is the moment a free user sees a reason to pay. Both need the same three things: the user's plan, their usage in the current period, and the number left.

1. Choose what to count

If one message in your app makes several model calls (a tool-using agent, a retry, a summary step), count the user-visible action yourself or limit by dollars. Otherwise "20 messages" quietly becomes 6.

2. Choose the period

Pick one clock for resets and say so in the app. A UTC day is the simplest to build and explain ("resets at 00:00 UTC"). A rolling 24 hours feels fairer but means storing every call's time. For monthly limits, a calendar month is simple; the user's billing period is more exact but changes with every upgrade, pause and renewal.

3. Know the user's plan on your backend

The app knows the plan (RevenueCat's SDK returns the active entitlements), but the app can't be trusted to enforce a limit. Your backend needs its own answer:

• RevenueCat: add a webhook and keep the latest state per app user ID: trial or paid, the product, and the expiry date. INITIAL_PURCHASE, RENEWAL, PRODUCT_CHANGE, CANCELLATION and EXPIRATION are the events that change it.
• Stripe: listen for customer.subscription.created, updated and deleted, and map the price to a plan. trialing and active have access; past_due is your call.
• No record means a free user.

Use the same user ID in billing and in your AI tracking. With RevenueCat that means logging users in with your own ID, or sending the anonymous ID to your backend; see the RevenueCat guide.

4. Count and check

The smallest version is one table and two statements:

CREATE TABLE ai_usage (
  user_id text, day date, calls int NOT NULL DEFAULT 0, cost_usd numeric NOT NULL DEFAULT 0,
  PRIMARY KEY (user_id, day)
);

-- before the call
SELECT coalesce(sum(calls), 0) FROM ai_usage WHERE user_id = $1 AND day = current_date;

-- after the call
INSERT INTO ai_usage (user_id, day, calls, cost_usd) VALUES ($1, current_date, 1, $2)
ON CONFLICT (user_id, day) DO UPDATE
  SET calls = ai_usage.calls + 1, cost_usd = ai_usage.cost_usd + excluded.cost_usd;

One row per user per day covers every period: today is one row, this month is a sum over at most 31, and a total is a sum over all of them. No reset job is needed, because a new day is simply a new row.

Then answer the app with enough to draw the right screen:

// allowed
200 { "reply": "…", "remaining": 3, "resetsAt": "2026-11-12T00:00:00Z" }

// used up: the app opens the paywall
402 { "paywall": true, "plan": "free", "resetsAt": "2026-11-12T00:00:00Z" }

Show the remaining number before the user runs out ("3 left today"), not only at zero. People upgrade more readily when the limit was visible all along than when it appears as an error.

5. The cases that break home-built limits

• A renewal that arrives late. If you treat a subscription as ended the second its period ends, a paying user drops to the free limits until the renewal event arrives. Allow some hours of grace.
• Cancelled is not expired. A user who turned off auto-renew has paid until the end of the period and keeps the paid limits until then.
• Trials. A trial user has the paid features but has paid nothing, and some people start trials to use a month of AI in three days. Give trials their own daily limit.
• Anonymous then logged in. RevenueCat merges the two IDs as aliases. If usage was counted under the anonymous ID and the plan sits on the new one, the user gets a fresh allowance or loses their plan. Count all aliases as one person.
• Calls at the same moment. Ten requests sent together all pass a check made before any of them is counted. For a soft limit that is fine. For a hard one, count first and refund on failure, or lock per user.
• Streaming. The cost is known only when the stream ends. Check before, count after.
• Your limiter is down. Decide in advance: allow (a short burst of free usage) or refuse (your app is down too). Most apps should allow, with a small in-process cap as a backstop.
• Upgrades mid-period. Apply the new plan's limits at once and keep the usage already counted. Resetting to zero on upgrade is generous; hiding the old usage on downgrade is a loophole.

6. Or let FiscaLLM do it

FiscaLLM is open source and does the parts above: it receives the RevenueCat or Stripe events, keeps each user's plan, counts AI calls and prices them, and answers one question from your backend.

import { createMeter } from "fiscallm";
const meter = createMeter({ apiKey: process.env.FISCALLM_KEY });

const { allow, plan, limits } = await meter.check(userId);
if (!allow) return respond(402, { paywall: true, plan, resetsAt: limits[0]?.resetsAt });

const reply = await openai.chat.completions.create({ ... });
meter.trackOpenAI(reply, { userId });                     // counted and priced

return { reply, remaining: limits[0]?.remaining };        // "3 left today"

The limits themselves are settings, not code: on the app's Limits page you add rows like free, 10 AI calls a day; trial, 30 a day; pro_yearly, $8 of AI a month. Changing a limit needs no deploy and no app release. The same page lists the users who are at a limit right now, and the rest of the dashboard shows what each plan's AI costs against what it earns, so you can tell whether a limit is too tight or too generous.

Create an app (free, no card), read the reference, or run it yourself.

Questions