Why caps belong on the user, not the workspace
Workspace-level caps protect your wallet but punish good users when a teammate goes rogue. Per-user caps contain the blast radius, make abuse visible, and turn the cap itself into a self-service upgrade lever.
The shape of a healthy cap system
- Default cap set at 3-5× median monthly user spend.
- Live usage bar in the user's profile and the ⌘K footer.
- Hard stop at cap with an inline "raise to $X" upgrade link.
- Workspace admins see all caps and can override per user.
- Cap changes audit-logged like billing changes.
Why this drives revenue
- Power users self-identify and upgrade — no sales motion needed.
- Admins sleep at night, expand seats faster.
- Finance gets predictable max-spend per cohort.
Operating principle
A cap that's invisible is a surprise. A cap that's visible is an upgrade prompt.
FAQ
- Why per-user caps instead of per-workspace?
- Workspace caps protect you from an unbounded bill but don't protect honest users from a noisy teammate. Per-user caps make abuse self-contained and turn caps into a self-service upgrade lever.
- What's a sensible default cap?
- Set it at 3-5× your median user's monthly spend. High enough that 95% of users never see it; low enough that one runaway agent doesn't drain the workspace.
- How do I let users raise their own cap?
- Expose the cap in the billing UI as a slider tied to a Stripe meter limit. Raising it is a one-click upgrade; lowering it is immediate. Self-service caps drive 20-30% of expansion revenue in usage-based products.
- What happens when a user hits the cap?
- Hard stop on AI calls with a friendly inline message and a 'raise my limit' link. Never silently degrade — users notice and lose trust.