Set and interpret spend caps
Per-user spend caps are for Business and Enterprise organization instances. Individual plan users have a personal balance instead — see Individual billing and usage.
There are two limits on AI spend, and they work differently.
Your organization limit comes from your contract — trial, pilot, or subscription — not from a setting in the app. It covers the included usage for the current billing period. Admins see it on Admin → Usage as "Organization included usage", with the period dates and the next reset.
Per-user limits are the ones you configure. They cap what a single member can spend, either over the whole contract or over a weekly or monthly window that you choose. The most restrictive limit wins: a member can never exceed their per-user limit, and the organization can never exceed its contract allocation.
Turn on per-user limits
- Open Admin → Members.
- Switch on Spend limits, set a default per-user limit, and choose how often it resets.
- Override the limit for specific people from their row in the members table, where current spend and limit status are also shown.
Every member shares one reset cadence — the amounts can differ per person, the window cannot. Choose Every month or Every week and each member's cap refills at the start of that window in UTC, with unused budget not carrying over; weeks begin on Monday. Choose Never and the cap covers the whole contract, so a member who exhausts it stays blocked until the contract renews. The members table headers name the active window, so "Org usage this month" and "Monthly cap" tell you which period you are reading. Change the cadence any time from the pencil beside the default.
What happens as a limit is approached
- 75% of a per-user limit: the member sees a warning in the composer, with further warnings at 90% and 95%.
- 80% of the organization contract limit: admins see a banner. Admins are also warned when the contract is within three days of expiring, or when a period has no allocation.
- 100%: new AI work is blocked. The member sees a block message; system-initiated work such as document parsing is not attributed to a user and is not affected by per-user limits.
- In-flight runs continue. The limit is checked before work starts, not during, so a run already underway finishes rather than producing partial results. Actual spend can land slightly above the limit when a large run was in progress.
Requesting more headroom
Members who are approaching or over their limit open Settings → Usage and use Request increase. They can edit or withdraw a pending request while it is open; their limit does not change until an admin acts.
Requests land in Admin → Requests, where admins can approve or deny them individually or approve all pending spend-increase requests at once. Approving raises that member's limit to the requested amount.
If you need a hard stop mid-run, cancel it from the run's page; spend stops accruing within a few seconds.
Practical tips
- Set per-user limits that match the work — someone running drawing reviews needs more headroom than an occasional user.
- A weekly or monthly reset caps the damage from one runaway week without an admin having to intervene, and it costs less attention than approving increases against a contract-long cap. A contract-long cap suits pilots where the total matters more than the pace.
- Use Admin → Analytics → Workflows to check whether one expensive workflow is driving most of the spend before you change limits.
- If several people hit their limit quickly, check whether they are indexing large files or running broad workflows before raising anything.