A cap that refuses the call
Most AI cost tooling tells you what you spent after you spent it. GitRevio meters spend per user and per organisation, and enforces the cap at call time — once month-to-date spend reaches the ceiling, the call is refused rather than logged.
Spend resets naturally at the calendar month, because it is summed by month rather than tracked in a counter someone has to reset.
Where the cap binds
One gate decides whether an AI call is allowed, and three surfaces call it. The scope each surface enforces differs, so it is worth being precise:
AI chat
Per-user and per-org
A chat turn is checked against your own cap and your organisation's.
Skill runs
Per-org
A skill execution is checked against the organisation's cap.
Skill AI calls
Per-org
AI calls made from inside a skill are checked against the organisation's cap.
Per-user caps therefore bind on chat. Skill execution and the AI calls inside skills are governed by the organisation cap.
How a cap is resolved
-
A cap you set
A USD-per-month ceiling for that scope.
-
A cap set to none
Unlimited for that scope — an explicit choice, not an absence.
-
No cap set
Falls back to the built-in defaults: $200/month for the organisation, $50/month per user.
-
An approved temporary override
Raises the effective cap for that calendar month only.
Absolute ceiling
Above the configurable caps sits an absolute organisation ceiling. If the budget state cannot be resolved — a database problem, say — spend is rechecked against that ceiling and the call is blocked if it is at or over.
The default is to fail closed to a bound rather than fail open. An operator can raise it, or disable it deliberately.
When someone needs more
A blocked user is told which scope blocked them and what the cap was, and can request more budget. The request goes to a customer admin, who approves it temporarily — raising the cap for the current month — or permanently, or denies it.
| Method | Endpoint | What it does |
|---|---|---|
| GET | /api/v1/me/ai-spend | Your own meter: month-to-date spend against your cap, the org context, and whether you are currently blocked. |
| GET | /api/v1/admin/ai-spend | Org dashboard: the org meter, a per-user breakdown, and the most expensive conversations. |
| PUT | /api/v1/admin/ai-budget/limits | Set or adjust a permanent cap, at org scope or for one user. |
| POST | /api/v1/me/ai-budget/override-request | Ask for more budget. Routed to a customer admin. |
| GET | /api/v1/admin/ai-budget/override-requests | List requests, pending first. |
| POST | /api/v1/admin/ai-budget/override-requests/{id}/resolve | Approve — temporarily or permanently — or deny. |
Tenant isolation
Every query is scoped by the authenticated customer, never by a customer identifier supplied in the path or body. A write that names a target user validates that the user belongs to the authenticated customer first, so an admin cannot set a cap or resolve a request for someone in another tenant.