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 fixed calendar window (hourly, daily, weekly, or monthly); 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, and is priced with a conservative fallback rate rather than $0 — this shows up most often right after a new model release, before its pricing has been added, and keeps budget rules and spend limits from being silently bypassed by an unpriced model in the meantime. The fallback rate is intentionally on the high side (matching AIControls' priciest known frontier-model tier, including cache rates), so it errs toward stopping spend too early rather than letting it run unchecked — expect it to overstate the true cost until real pricing is added. This applies to budget enforcement and to the Budgets/Cost Intelligence totals, which are both derived from the same per-request cost recorded at request time; a handful of separate, independently-computed views (e.g. per-developer cost from Observer telemetry) still look up the cost table directly and can undercount an unpriced model until it's 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); once added, tracked cost reflects the real rate immediately.
Models served through a cloud provider
Amazon Bedrock and Google Vertex address the same models under their own IDs — Bedrock uses an inference-profile ID such as us.anthropic.claude-sonnet-4-5-20251001-v1:0. Cost is attributed against the canonical model name (claude-sonnet-4-5), not the provider-specific ID, so:
- You price each model once. There's no need for a separate cost-table entry per region or per inference profile.
- Bedrock and Vertex traffic rolls up together with direct-provider traffic for the same model on the Cost Intelligence pages, rather than appearing as extra rows.
- Prompt caching is applied to Bedrock and Vertex the same way as to the direct provider, so cache-read and cache-creation tokens — and the savings they produce — are attributed there too.
Observed model inventory
Inventory → Models lists every model that has actually been called through the proxy — sourced from LLM request traffic, not a static catalog — with first/last-seen timestamps, call count, and total cost. Each row also shows whether the model is subject to a global model allowlist configured under Settings → Models → Governance:
| Allowlist state | Meaning |
|---|---|
| Unrestricted | No global model allowlist is configured — any model may be called. |
| Allowed | A global allowlist is active and this model is on it. |
| Not allowlisted | A global allowlist is active and this model is not on it — calls to it should be reviewed. |
Use this page to catch models being called that you didn't expect — a developer routing through a provider directly, or a new model release nobody's added pricing for yet (see Default model pricing).
Rules
Rules define spend caps. Each rule matches a scope (organization, team, or individual) and a model glob, and caps spend within a fixed calendar 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 | Hourly (1h), Daily (24h), Weekly (7d), or Monthly (30d) — each resets on a fixed calendar boundary (top of the hour, midnight UTC, every Monday, or the 1st of the month), not a trailing period counted back from now |
| 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 the per-model budget rules above, 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.