The Spending area in AI setup governs AI cost across the whole workspace — every user, agent, and model — rather than for a single agent.
Overview
Spending has three views: Usage (what's been spent), Limits (the budgets and caps you set), and Alerts (notifications before a limit trips). This is broader than an individual agent's Spending tab, which caps one agent; use this to manage the organization's total AI budget.
The Usage View
Usage gives "AI spend rollups for the selected range" (defaulting to This Month). It shows spend against your cap with a projection, a daily/weekly spend chart with a forecast and budget pace, and breakdowns by Models, Agents, Automations, and Users, plus top movers and spikes. You can Compare against the prior period or year over year. The Automations breakdown has its own picker to filter down to specific automations instead of free-text search.
Each breakdown row also carries a small status dot comparing its spend in the selected range against whichever limit currently governs it — an override if one applies, otherwise that scope's default, prorated to the number of days in the range: dashed if no limit applies, green while comfortably under it, amber once you're approaching it, and red once you're over.
Setting Spending Limits
Limits lets you "Govern AI spend across users, AI agents, and models. Stack daily, weekly, and monthly caps in USD or tokens." You can set:
Cap type | What it does |
|---|---|
Org Cap | A hard ceiling for all AI spend, stacking daily, weekly, and monthly caps (and an optional per-query cap that limits any single request). |
Per-scope defaults | Default caps that apply per User, AI Agent, or Model. |
Team caps | Group caps applied to every member; a team cap acts as a floor that raises the user default, and a user in multiple teams gets the best cap. |
Overrides | Pinned caps on one specific entity that beat the default and team caps. An override can also target a single Automation, capping that automation's combined spend across all its runs — automations can't yet carry a workspace-wide default cap, only these per-automation exceptions. |
Caps resolve in priority order — "Default supplies the baseline; Team raises it for members; Override pins it for one entity; Org cap bounds them all." A cap can be hard (blocks) or soft (warns — pair it with alerts). Stacking caps gives you both a hard organizational limit and fair distribution across people.
How Limits Are Enforced at Request Time
Every limit-governed model call goes through a pre-flight check before the model is invoked:
The platform estimates the request — input tokens are approximated from the message length (roughly 1.3 tokens per word) and costed at the model's rates, and the resolved per-query caps can clamp the call's maximum output tokens.
It resolves the effective cap for each scope using the cascade above — override pins, team floor raises the user default (a user in multiple teams gets the highest team cap), and everything is clamped by the org cap. Each resolved cap keeps the hard/soft enforcement of the rule that won.
The estimate is reserved against fast running counters for every scope-and-period combination (daily, weekly, monthly × user, agent, model, overall), and each counter's current usage plus the reservation is checked against its limit.
Hard breach → the call is blocked and the reservation is rolled back; soft breach → the call proceeds with a warning. When several caps trip at once, one message is chosen by priority: org hard limit first, then other hard limits, then org soft, then other soft.
After the call completes, the actual tokens and cost reconcile the reservation, so counters reflect real usage rather than estimates.
Per-query caps check the single request itself — max input tokens, max output tokens, and max query cost (both the input portion and the projected total) — each hard or soft in its own right.
What a Blocked or Capped Request Looks Like
When a hard limit trips mid-conversation, the request stops and the user gets an explanatory alert message published into the chat (it's shown once per session rather than on every subsequent message). Soft limits don't interrupt the exchange — they surface as warnings and are the ones to pair with alert rules. Exceptions you grant (per user, team, model, agent, or tier) carry a reason field, so there's a record of why an entity is allowed to exceed the default.
How Spending Alerts Work
Alerts "Route spend notifications before a limit trips." Use New alert rule to define one, choosing a trigger, then set how you're notified (email, an in-app notification to chosen users or teams, or a custom action such as Slack, Teams, a webhook, or a ticket), a severity (warn or critical), and how often it's evaluated. These rules let you act on a budget problem before it becomes an overrun.
Trigger types, starting values, and guidance
Trigger | Asks for | Starts at |
|---|---|---|
Current % of cap | Which limit to watch, period to watch, and the firing percentage. | 80% — "Typical: 70% warn, 90% critical." |
Projected overrun | Which limit to forecast against, period to forecast, and the percentage of the cap the forecast must reach. | 100% |
Spend over rolling window | Measurement unit (USD or tokens), an amount, a rolling window, and an optional scope (overall org, team, agent, automation, user, or model) with optional entities. | 500 over 1 hour — "Typical: $500 / 1h catches runaway agents; $5,000 / 24h flags unusual daily burn." |
Burn rate | Which limit to watch, period to project against, and days until the cap would be depleted at the current pace. | 7 days — "Typical: 7 days warn, 3 days critical." On a weekly watch period, days must be 1–5. |
Anomaly detection | Measurement unit, a baseline window, a sensitivity in standard deviations, and an optional scope/entities. This is the only trigger that can also be scoped to an agent session. | 14-day baseline, 3σ — "Typical: 3σ over a 14-day baseline. 2σ catches gentler drifts but fires more often." |
Note: If you set the Burn rate watch period to weekly, the days must be 1–5 — otherwise you're told "For a weekly watch period, enter fewer than 6 days (1–5)."
New rules start active, with a warn severity and an evaluation interval of 5 minutes. As you configure a trigger the platform writes a plain-English description of the rule for you (for example, "Warn: Alert when rolling cost exceeds 5000 in 24 hours per agent."), so the list reads clearly without you having to write one.