The disabled button that was not enforcement
Greying out a button stops the person looking at it and nobody else. An old tab, a background job or a direct call goes straight past. The decision has to happen where the write happens.
The foundation under itCommercial platform
Usage limits
AI spend is capped by the server, at the moment of the write.
Meeting extraction, Ask Growth Kit, content drafting and profile writing each cost money per run. One registry declares how many AI generations our workspace may accept in a billing period, how many active projects we may hold, and how many API requests per minute a key or a session gets. The server reserves usage inside the same transaction as the work, so a retry never burns the allowance twice.
- 3
- kinds of limit: per window, per billing period, at once
- 1
- durable usage record behind every decision
- 0
- limit decisions made in the browser
8 of 22 in The foundation under it
Product example
See it working
This is the same visual component used by the authenticated app, rendered with deterministic sample data.
Scenario
viewport
surface theme
mode
Within limits
The included allowance, the enforced limit and what is left.
Inert sample data · no network access
Preview ready
The problem this solves
Without a shared foundation, every team rebuilds these edge cases, differently.
The allowance spent on a failure
A flaky connection retries a request and a naive counter charges the quota again. The month runs out on generations nobody received. A stable event ID makes the second attempt free.
Nobody can say what the limit is
Limits scattered through ad hoc conditions drift apart until someone asks what we are actually allowed to run this month and there is no confident answer. One registry ends that.
Highlights
Why it matters
Four limits, one file
Active projects, AI generations per billing period, API requests per minute for a key, and per minute for a signed-in session. Each is one typed entry.
A retry does not count twice
Every reservation carries a stable event ID. A repeat returns the original ledger row, and a repeat with a different quantity is refused rather than accepted quietly.
Unknown means no
If the server cannot resolve which plan applies, the decision is denied. Nothing passes on a missing entitlement.
How it works
The mechanism end to end, as implemented in the repository.
- 1
Declare the limit once
Each limit is one typed entry: what it counts, who it applies to, the window it uses, the entitlement it binds to, and what happens when it is reached.
- 2
The server resolves the plan
Subscription state maps to a plan and its entitlements, with a short grace window after a late payment. An explicit organization grant can raise an entitlement.
- 3
Usage is reserved inside the write
The server takes a lock, reads the usage ledger and reserves the amount in the same transaction as the work, so parallel requests settle in order instead of racing.
- 4
Refusals say what they are
A rate limit returns the number of seconds to wait. A period limit says the plan limit was reached. Meeting extraction reads that answer before it starts and skips work the allowance would refuse.
Engineering guarantees
What this does and does not promise
Safety boundary
The meters on screen explain a decision, they never make one. A limit caps how many AI runs we accept, not what any single run costs at the provider, and today every plan leaves AI generations unlimited.
Implementation evidence
The boundary above is code, not a claim. These files carry the contract:
src/registries/quotas.tssrc/server/commercial-access.tsconfig/entitlements.ts
Questions
Frequently asked questions
Used alongside this
These capabilities share contracts and boundaries with this one.
What usage limits rests on
The docs describe the same contracts this page demonstrates.