Skip to content

SYSTEM Cited by 4 sources

Unity AI Gateway — Budgets

Budgets are the policy layer that rides on top of Unity AI Gateway's usage-tracking metering. Admins set monthly spend thresholds per user or group; the Gateway emits alerts when consumption approaches or crosses the threshold. As of 2026-05-20 the surface is alerting-only; hard enforcement is on the roadmap ("more to share on that soon").

Definition (from the source)

"Budgets in Unity AI Gateway add the policy layer. Admins set monthly spend thresholds per user or group and get alerted when consumption approaches or crosses them — the signal you need before spend becomes a problem, not after. Hard enforcement is the natural next step, and we'll have more to share on that soon." — Source: sources/2026-05-20-databricks-governing-ai-agents-at-scale-with-unity-catalog

Position in Pillar 3 (Cost intelligence)

The post frames cost intelligence as a two-component composition:

Component Role What it surfaces
Usage-Tracking Metering "every request to usage tables, including token counts, latency, requester identity and model destination across Databricks-hosted and external providers in a single table"
Budgets Policy "monthly spend thresholds per user or group" with alerts at approach / cross

Without metering, budgets have no input; without budgets, metering is ledger-only. The composition matches the more general meter-then-throttle shape (budget-enforced-quota-throttle).

What Budgets buy (per the post)

  • Pre-emptive signal, not post-hoc invoice. "the signal you need before spend becomes a problem, not after." The framing is operational: surprise invoices break finance trust; alerts before the threshold give admins time to act.
  • Per-identity, not per-tool. Per the 2026-04-17 launch post: "admins give each developer one budget and the developer burns it on whichever tool of choice (Cursor / Codex / Gemini CLI / Claude Code / …)." The 2026-05-20 generalisation extends this to per user or group for general-agent populations, not just developers.
  • Cross-provider scope. Because Unity AI Gateway's unified billing surface sees Databricks-hosted + external (Azure OpenAI / AWS Bedrock / Anthropic) traffic in one substrate, a single Budget policy applies regardless of where the tokens were spent.

Hard enforcement is now live (2026-07-28 disclosure)

The 2026-07-28 post (sources/2026-07-28-databricks-coding-agent-spend-unity-ai-gateway-budgets) confirms hard enforcement shipped and discloses Databricks' internal production deployment architecture — a dual-budget system that separates runaway-spend protection from monthly spend governance.

Dual-budget architecture

Budget Purpose Reset cycle Unblock path
Daily budget Catch runaway spend (accidental automation loops) Every evening (lowest-usage hour) + full reset at month start Self-serve acknowledgment (Slack button, CLI, or portal)
Monthly budget Govern extraordinary spend Monthly Manager approval, time-limited to project duration

The effective limit at any moment: min(month_to_date + one daily increment, monthly maximum). This formula determines which limit was hit and therefore which unblock path applies.

The two are coupled via a fixed ratio: an engineer spending smoothly across the month never trips the daily limit because monthly budget ÷ working days sits below the daily threshold. When a manager raises the monthly tier, the daily increment scales proportionally.

Tiered overrides via group membership

Both budgets move through fixed tiers (implemented as Gateway group membership), not arbitrary per-user values:

  • Daily tiers — auto-promote on each self-serve acknowledgment; scheduled job also proactively promotes at ~90% of ceiling (at most once/day); full reset to base at month end.
  • Monthly tiers — coarse steps (~2×, 5×, effectively unlimited); require manager/skip-level approval; time-scoped (1/3/6 months); auto-revert when project ends.

Self-serve acknowledgment workflow

When a user crosses ~90% of their daily limit, they receive a notification (Slack, CLI, internal portal) with spend context and a single button to acknowledge intentional spend. This raises the daily limit by one increment immediately. No cap on daily acknowledgments. Key property: an unattended cron job cannot click a Slack button — the human signal is the runaway discriminator.

Result at Databricks' scale

Under the old single-limit model, 500–1,000 engineers hit the cap monthly → hundreds of tickets. Under the dual-budget model, only a handful of heaviest users see a daily notification per month, each resolved with one click. Monthly increases went from recurring per-engineer chore to rare project-scoped decisions.

Previous state (2026-05-20): alerting-only

The original 2026-05-20 disclosure stated hard enforcement was "on the roadmap". The 2026-07-28 post confirms it shipped and is deployed internally at scale.

From two budgets to four — model-class-scoped budgets (2026-09-28 disclosure)

The 2026-09-28 How Databricks rolls out frontier models to 12,000 employees on Day 1 post (sources/2026-09-28-databricks-how-databricks-rolls-out-frontier-models-to-12000-employees) extends the dual-budget (daily + monthly) architecture to four principal per-user budgets, adding two that are scoped to a model class rather than to a time window. This is the enforcement substrate behind experimental-tier model promotion.

Budget Scope Purpose
Monthly maximum all models overall monthly spending ceiling per user
Daily runaway limit all models catch runaway sessions; raisable directly in Slack
[NEW] Quality frontier budget premium models only a fraction of the monthly budget reserved for the most premium models at the quality frontier (e.g. GPT Astra, Claude Fable). Intent: these are not daily drivers — they're rationed for specialized tasks where they're uniquely suited, to justify a 2–3× cost premium over the next quality tier.
[NEW] Experimental budget new, untested models only a fraction of the monthly budget reserved for new models on the experimental tier, balancing speed of adoption against the downside risk of widely exposing a model that is not on the efficiency frontier.

The key generalisation: the first two budgets bound spend by time window (daily/monthly); the two new ones bound spend by model class (premium-known-good vs new-untested). A model-class budget is what makes Day-1 access to all 12,000 employees affordable — a newly-released model is tagged into the experimental bucket on Unity Gateway, so exposing it fleet-wide has a bounded cost during the few-day evaluation window, and promotion out of the experimental tier is what moves it into standard circulation. (Source, §Step 2.)

The two axes compose: a user has one monthly maximum and one daily runaway limit spanning all models, plus a carve-out that says of that budget, at most X% may go to premium models and at most Y% to experimental ones — so a runaway experiment or premium-model overuse can't consume the whole monthly budget.

Why per-identity budgets work and per-tool budgets don't

The 2026-04-17 post already framed this for the coding-agent case: developers fluidly switch between Cursor / Codex / Claude Code, and a per-tool budget would either over-allocate (developer can run any tool to the limit) or under-allocate (developer hits a tool-specific cap while overall spend is fine). Per-developer budgets are tool-portable: the developer makes the spend-vs-tool tradeoff, not the admin. The 2026-05-20 generalisation extends this beyond developers — analytics, sales-ops, support, marketing, and finance teams now run their own agents, and the same per-user / per-group budget shape applies across all of them.

Linked deeper-dive

The post links to a companion deeper-dive titled Introducing AI Spend Controls in Unity AI Gateway (databricks.com/blog/introducing-ai-spend-controls-unity-ai-gateway) — not yet ingested.

Seen in

Source

Last updated · 766 distilled / 2,225 read