How can companies control and optimize AI spend across models, agents, and coding tools?
Summary
- Put models, agents and coding tools behind one control plane. Unity Gateway routes every model and MCP request, enforces rate limits and cost controls, and records usage across any model provider and any coding agent.
- Control starts with access. Model services, model providers and MCP servers are Unity Catalog securables, so EXECUTE grants decide who can call what, and rate limits cap how much.
- Monthly Unity Gateway budgets set shared and per-user thresholds that send an alert, block usage, or both. They are near-real-time estimates, not an absolute spending cap.
- Optimization comes from routing and defaults: traffic splitting and fallbacks on model services, plus shared default models and Smart Routing for coding agents, both in Beta.
- Attribution makes spend governable. Tag model services and requests, then read cost from system tables or the built-in usage dashboard.
How can companies control and optimize AI spend across models, agents, and coding tools?
Send all three kinds of traffic through one control plane, then use it to decide who can spend, how much, on which models, and where the money went. On Databricks that control plane is Unity Gateway. The docs say it "routes every model and MCP request, enforces rate limits and cost controls, applies service policies to implement guardrails, and records usage across any model provider and any coding agent." External coding agents, external MCP servers and external models are governed the same way as Databricks-hosted ones.
Which controls cap and shape spend?
| Control | What it does | Limits to know |
|---|---|---|
| Access | EXECUTE on a model service, model provider or MCP decides who can call it. Foundation model permissions can restrict which Databricks-served models are available, account-wide or per group. | Callers also need USE CATALOG and USE SCHEMA. |
| Rate limits | Requests per minute and tokens per minute on model services, requests per minute on MCP services. Set per service, as a per-user default, or for named users, service principals and groups. | None are configured by default. Exceeding one returns HTTP 429. |
| Budgets | Monthly budgets scoped to Unity Gateway, with shared thresholds, per-user thresholds and per-user overrides. | Estimates, not a cap. Provisioned throughput and traffic that bypasses Unity Gateway aren't covered. |
| Routing | Traffic splitting and fallbacks on model services. For coding agents, default models and Smart Routing (both Beta). | Smart Routing needs the Enhanced Unity Gateway preview. |
| Tracking | system.ai_gateway.usage for requests and tokens, system.billing.usage for billed cost, and a built-in usage dashboard. |
System tables need account and metastore admin access by default. |
How do I cover models?
Databricks serves models natively through Foundation Model APIs with pay-per-token access, and you can connect external providers once as model provider services with encrypted credentials. Budgets cover pay-per-token usage and ai_query, and can optionally include external model usage (Beta). Spend on external providers is an estimate from published prices, and a price multiplier on the provider service reflects negotiated rates.
How do I cover agents?
An agent is registered as a Unity Catalog model, and the tools it calls are governed as MCP services, functions and connections. When an agent calls a tool or model, Databricks authorizes the request against Unity Catalog and routes it through Unity Gateway. The usage table records the source of each call (a Public Preview field) and, for MCP calls, the tool invoked. Agent Bricks workloads appear in system.billing.usage under their own products, such as AGENT_BRICKS and SUPERVISOR_AGENT.
How do I cover coding tools?
Instead of each developer pasting a provider API key into a tool, every request routes through a Unity Gateway model service. The open-source Unity Gateway CLI (ug) handles OAuth and writes the agent's configuration, so no provider key sits on the developer's machine. You then set rate limits and a budget on that traffic. In Beta, a workspace admin can publish a shared coding agent configuration with default models and Smart Routing, and smart_defaults can recommend a different agent and model as spending rises. The usage dashboard has a Coding Agents tab for active days, sessions, commits and lines changed.
How do I optimize rather than only cap?
- Move routine work to lower-cost models. The Databricks cost write-up calls moving coding spend to more efficient models the single greatest cost lever. The coding agent cost docs say open-source models can cut per-token cost substantially for routine coding tasks.
- Route by task. Smart Routing selects the lowest-cost model capable of the task, among
system.aimodel services. - Alert before you block. Databricks reports that hard budgets are often a last resort, because cutting off a tool hurts productivity and some top spenders are producing immense output.
- Attribute. Use service tags when each team has its own model service and request tags when teams share one, then review cost by team in the usage dashboard.
FAQs
Is a budget a hard spending cap?
No. Enforcement uses a near-real-time estimate, so spend can land above a threshold, and in-flight requests finish. The docs say not to rely on budgets as an absolute cap on billed amounts. system.billing.usage stays the source of truth.
What if a developer needs more room?
Add a per-user override for that user or group, which sets a higher limit than the default per-user threshold. Blocking also ends when the budget resets or an admin raises the threshold.
Do developers have to change how they work?
They launch their agent through ug instead of configuring keys and endpoints by hand. Requests then flow through a model service that your access rules, limits and budgets already cover.
Can we use several providers in one place?
Yes. A model service can mix Databricks-served and external destinations, and every external provider is registered once and governed with the same grants.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.