AI assistant usage limits: plans, roles and allowances

An in-app AI assistant costs money every time someone uses it, unlike most features in a SaaS product. Without AI assistant usage limits, one enthusiastic team can run up a bill that no plan price covers. This post walks through how I set up access and limits for the AI Assistant in Recond, a multi-tenant vehicle reconditioning platform with a Flutter app and a website: which plan gets it, how daily caps per role and a company allowance fit together, where to enforce them, and how to explain them to users without promising the wrong thing.

Decide which plan gets the assistant

In Recond, the AI Assistant is part of the Enterprise plan. That one decision does a lot of the work of AI feature pricing in a SaaS. As I see it, the plan that carries the assistant is the one whose price can absorb a cost that grows with usage, and the customers on it are the ones most likely to have the volume of records where an assistant earns its keep.

When I'm deciding this for a product, I ask three questions:

• Does the cost scale with use? If every message is a paid model call, the feature belongs on a plan priced for that.
• Who gets the most value? An assistant that searches and creates records matters most to companies with many records and many users.
• What does a lower plan see? Gating the feature is different from hiding it. More on that below.

Putting the assistant on one plan also keeps the first version simple. One plan to meter, one set of customers to watch, and room to widen access once real usage tells you what it costs.

AI assistant usage limits per role and per company

Recond has two kinds of limits, and both are optional settings:

• Daily caps per role. Each role can have its own daily cap. People in different roles use the assistant very differently, and a cap per role reflects that.
• A company allowance. The company as a whole has an allowance that renews on the 1st of the month.

Having both is what makes it work for a multi-tenant product. The company allowance protects the business: whatever happens inside a tenant, its total is bounded. The per-role caps protect the tenant from itself: one heavy user cannot burn through the whole company's allowance by the 5th of the month and leave everyone else locked out. Stripe's engineering blog covers the same idea at the API level in scaling your API with rate limiters, where a spike from one user should never take the service down for everyone else.

Because both are optional, a company can run with neither, either one, or both. That flexibility has a cost in the copy, which I cover below.

Enforce LLM usage caps on the server

Every limit lives on the server, in the same request that calls the model. A check in the app is fine for showing a warning, and it is no protection: anyone can call your API directly, and an old app version will not know about a limit you added last week.

The order of operations I'd use for each assistant request:

1. Work out the user's company and role from the session, never from the request body.
2. Load the company's settings: whether each limit is set, and its value.
3. Count usage for this user today and for the company this month.
4. If either limit is reached, refuse before calling the model.
5. Otherwise call the model and record the usage.

The counting can be one query. A sketch of how I'd meter it in Postgres, with illustrative table names:

SELECT
  count(*) FILTER (
    WHERE u.user_id = $2 AND u.created_at >= date_trunc('day', now())
  ) AS user_today,
  count(*) FILTER (
    WHERE u.created_at >= date_trunc('month', now())
  ) AS company_this_month
FROM ai_usage u
WHERE u.company_id = $1
  AND u.created_at >= date_trunc('month', now());

date_trunc('month', now()) is the 1st of the current month, so the company allowance renews without any reset job. Decide which time zone "today" and "the 1st" mean for a tenant, and set it on purpose, because a cap that resets at midnight UTC looks random to a team on the other side of the world.

When a limit is hit, the API should say so clearly. An HTTP 429 Too Many Requests with a body that says which limit was reached and when it renews gives the app enough to show a useful message. Counting messages is the simplest AI usage quota; counting tokens tracks cost more closely, and I go into that side in controlling LLM API costs in Node.js.

Show usage before people hit the limit

In Recond, usage is shown under an "AI usage" label. People should be able to find how much they have used without hitting a wall first.

My defaults for what to show near a limit:

• Show the number early. Usage visible from the start, so a limit never comes as a surprise.
• Warn before the end. A short note when someone is close to their daily cap or the company is close to its allowance.
• Say when it renews. "Resets tomorrow" or "renews on the 1st" turns a refusal into a wait.
• Name the right person. Most users cannot change the company allowance. Tell them who can.

A limit message is part of the assistant's UX, alongside streamed replies, status lines and confirm cards. I wrote about those patterns in UX patterns for AI features.

Write help copy that stays true for every tenant

Since both limits are optional, some companies have limits and some do not. Help text that says "your usage is limited to" would be false for a company with no caps set. So Recond's help copy says limits "may" apply, which is true for every tenant.

It is a small word, and getting it wrong means a support ticket from a customer who reads one thing and sees another.

Recond also has a Help Center topic for the assistant. It explains what the assistant does, that it is part of Enterprise, who can use it, and the limits. That topic is not gated: Free, Growth and Pro users see it too. For them it works as an upsell surface, a plain description of what they would get on Enterprise. The marketing website's Help Centre mirrors the same topic, so a prospect reading the site and a customer reading the app see the same explanation.

This is the "gating is different from hiding" point from earlier. Hide the feature entirely and lower-plan users never learn it exists. Gate it and explain it, and the help page does sales work for free. The wider question of fitting AI into a product that already has plans and tenants is in adding AI features to an existing SaaS.

How should a SaaS limit AI assistant usage?

Put the assistant on a plan whose price can carry its cost, then add two limits: a cap per user or role, and a total allowance per company that renews on a fixed date. Enforce both on the server before calling the model, return a clear error that says which limit was hit and when it renews, and show usage in the app before anyone reaches the end.

Where I'd start

Pick the plan first, then add a company allowance, since that is the limit that bounds your cost. Add per-role caps once you see how different roles use it. Enforce on the server, show usage early, and write help copy that is true whether or not a tenant has set limits. If you are adding an assistant to your own product, this is the kind of work I take on through my services.