Cost Governance
Cap AI spend per model family, per team, or per user, and reduce the token usage behind that spend. Budget rules are enforced at request time against a rolling time window; optimization techniques reduce the tokens each request consumes in the first place.
Overview
The Cost → Budgets page has four tabs — Overview, Rules, Limits, and Alerts. Overview summarizes spend for the selected month: total spend against your global limit, projected month-end spend at the current burn rate, rules approaching their limit, and a feed of every request a budget rule denied, warned on, or audited.
Default model pricing
Every dollar figure on the Budgets and Cost Intelligence pages is computed from a per-model cost table — prompt and completion price per 1M tokens, plus cache-read (and, where applicable, cache-creation) rates for models that support prompt/context caching. AIControls ships default pricing out of the box for common Anthropic, OpenAI, Google Gemini/Vertex, and Fireworks AI models. Fireworks models are keyed by their full namespaced ID (accounts/fireworks/models/<name>), matching what the provider serves.
A model that isn't in this table still has its real token usage tracked, but with $0 estimated cost, and it's left out of cost dashboards entirely rather than shown as a zero — this shows up most often right after a new model release, before its pricing has been added. To add or correct pricing for any model, go to Settings → Model Costs and set its prompt/completion price per 1M tokens (and cache pricing fields, if applicable).
Rules
Rules define spend caps. Each rule matches a scope (organization, team, or individual) and a model glob, and caps spend within a rolling time window:
| Field | Description |
|---|---|
| Scope | Global (all identities), Team (a named group), or User (a specific identity) — plus Agent and Token scopes, configurable via the API |
| Target | The team name or user email when scope is Team or User; * for Global |
| Model match | Glob pattern — e.g. claude-opus*, gpt-4o, or * for all models. First-match within each scope. |
| Limit | Maximum spend in USD for the window |
| Window | Rolling window: 1h, 24h, 7d, or 30d |
| When limit is reached | See enforcement modes below |
| Warn at | Percentage of the limit at which every request is recorded as a warning while spend stays under the hard limit — this repeats on each request above the threshold, not just the first (no per-window dedupe yet). Default: 80%. A budget_warning notification at this threshold is not yet wired for per-model rules. |
Enforcement modes
| Mode | What happens when the limit is hit |
|---|---|
| Deny | Requests are blocked until the window resets. The caller receives a clear error with the reset time. |
| Audit | Requests are allowed, but would-have-blocked amounts are tracked so you can preview a rule's impact. Promotes to Deny in one click. |
| Warn | Requests are allowed and recorded as a warning. Useful for awareness without blocking. |
| Require approval | Requests are held for a manager to approve or deny in the Approvals queue. |
Rules are AND-enforced: a request must pass the first matching rule in every applicable scope (global, team, user, agent, token). If multiple rules match a request, all of them apply.
The Effective budget inspector on the Rules tab answers "what would happen to the next request" — type any identity and model to see which rules bind, the remaining headroom, and the resulting decision.
For step-by-step instructions on creating a rule, see Set a Budget.
Limits
Independent of rolling-window rules, a default session cap sets the maximum spend (USD) for any single session. When a session hits the cap, further requests are blocked until the session ends or an admin resets it. Individual sessions can override the default via their PAT settings.
Alerts
Alerts notify without blocking:
- Budget warning thresholds — each percentage threshold (e.g. 75, 90) fires a
budget_warningnotification at most once per window per rule, delivered to the affected developer, administrators, and any configured Slack or Teams channel. - Session spend alert — a USD threshold that fires an in-app notification the first time a session's spend crosses it. Separate from the session cap — it only notifies.
For conditional enforcement near a budget threshold — for example, requiring a ticket ID once spend exceeds 80% — use a CEL policy with object.modelBudget.team.pctUsed.
Context Optimization Preview
AIControls intercepts every tool response before it reaches the LLM and applies techniques that reduce token usage at the source:
| Technique | What it does |
|---|---|
| Noise filtering | Strips ANSI escape codes, progress bars, and terminal noise from shell tool responses before they are forwarded to the LLM. |
| Response deduplication | Suppresses exact duplicate tool responses within a session using a content-hash cache — repeated results are replaced with a short reference instead of the full text. |
| Brevity injection | Appends a conciseness directive to requests. Three modes: Off, Auto (applied when context pressure is detected), Always. A custom prompt can override the built-in instruction. |
A custom brevity prompt can override the built-in instruction (default: "Be concise. Omit preamble and trailing summaries. Prefer code over prose.").
Brevity injection is the highest-leverage technique for most teams — the Context Savings dashboard in the demo shows it accounting for 12M+ tokens eliminated from 29,000 events with a single setting.
For configuration steps, see Optimize Cost. For how compression — the fourth technique — reduces tool-response size and keeps originals retrievable, see Context Optimization.
Compression Preview
Compression reduces the size of tool responses before they enter the LLM context window, independent of the context optimization techniques above. It applies both to MCP tool responses and, optionally, to built-in tool results (Bash, Read, Grep, and similar) embedded in your LLM requests. See Context Optimization for how compression modes, rule precedence, context-pressure escalation, and lossless retrieval work.
| Setting | Description |
|---|---|
| Default mode | Compression level applied to all tool responses. ML (model-based) achieves ~90–95% size reduction by summarizing content semantically. Additional modes may be available depending on your workspace configuration. |
| Code-aware (AST) compression | When enabled, source code responses are compressed using an AST-aware pass that strips function bodies and retains signatures, imports, and structure. Higher quality than generic ML compression for code. Requires the Compression Service to be reachable from your workspace. |
| Threshold | Minimum response size in bytes before compression is attempted. Responses smaller than this value are returned unmodified. Default: 4096 bytes. |
Compression is a preview feature. Results vary by tool and content type — monitor the Context Savings dashboard after enabling to confirm the savings.
For configuration steps for both features, see Optimize Cost.
Context Savings dashboard
Cost → Context Savings shows what the active optimization techniques are actually saving: the token reduction rate across sessions, estimated cost saved, a breakdown of savings by technique, and the sessions that benefit most. Use it to verify a newly enabled technique is working and to find workflows where further tuning would pay off.