Costs and spending limits

Three pages cover the money: Usage shows instance time, Costs shows the model spend breakdown, Spending Limits enforces the budget. Estimates and actuals price from the live model catalog.

Usage

Organization Settings > Usage tracks per-user instance awake time over 24 hour, 7 day, or 30 day windows: totals with period-over-period deltas, a 7x24 punch-card heatmap of when instances are awake, and live awake-now presence. A segmented control switches the lens between Hours, Cost (awake time priced at the org compute rate), and Value (usage attributed to swarms, flows, and chat with server-computed ratios). Sleeping instances are deallocated and accrue nothing.

The Usage admin page: per-user instance awake time, the 7x24 heatmap, and the Hours / Cost / Value lens control
↳Awake time is the meter: who is on, when, and what that time is worth, in one heatmap.
The Costs admin page: 30-day total with month-end projection, API calls, tokens, cache rate, and per-provider spend bars
↳Metered in the open: the month-end projection, the cache rate, and who is actually spending it, by provider.

Costs

Organization Settings > Costs tracks API cost by user, project, model, and flow. Pick a time range from 1 hour to 90 days or all time, filter by project or user, and review the trend, the provider breakdown, the cost matrix, the largest individual requests, a month-end forecast built from month-to-date spend, and suggested cost optimizations. Tables export to CSV, and a banner surfaces projects that are over or approaching budget.

How pricing works

Costs and swarm estimates price per million tokens from the live model catalog; a static table backs any model the catalog has not priced, so an unpriced row never zeroes an estimate. Self-hosted models are the deliberate exception: they price at zero because the org runs the hardware, and that zero is kept rather than falling through to an API-rate default. Swarm cost estimates combine catalog pricing with per-role token profiles (an architect, a backend dev, and a code reviewer consume differently).

Spending Limits

Organization Settings > Spending Limits sets the caps. Enable the cap, choose a daily or monthly period, and set an org-wide cap plus a default per-user cap. You can add finer caps per project, per model, and per flow, and set per-department budgets for the departments defined on the Departments page.

The Spending Limits admin page with the org cap, warning thresholds, and department budgets
↳The budget with teeth: caps, thresholds, and per-department budgets in one place.

Alerts, requests, and enforcement

Usage bars turn to warning at 80 percent and exceeded at 100 percent of a cap. The alerts feed records every warning and block with the user, usage, and cap at the time. Members who hit a limit can file a cap increase request (org cap, per-user cap, project cap, or model cap); requests land here as pending for an admin to approve or deny.

Cap changes are recorded in the audit trail as spending cap change events, so budget history is reviewable alongside everything else.