Databricks and Snowflake put different clocks on AI-agent spend controls
Both gateways can stop runaway usage, but their user views, shared limits, enforcement lag and billing authority differ enough to change the operating model.
Two enterprise gateways now promise to make coding-agent and model traffic governable, but “budget” does not mean the same control—or the same clock—on Databricks and Snowflake. Platform teams choosing an enforcement pattern should compare four separate questions: who can see usage, whether limits are shared, how quickly a block lands and which ledger settles the bill.
Databricks puts the warning beside the agent
Databricks exposes applicable Unity Gateway limits directly through ug usage. The default shows the five limits with the highest percentage consumed; --all is required for the complete list. Entries can be daily or monthly and personal or shared, and the same spending can count against several limits.
That makes the CLI a useful self-service warning surface. A developer can see that personal headroom remains while a shared limit is nearly exhausted. The catch is that the default is a risk-ranked summary, not a policy inventory.
Databricks’ Unity Gateway budget contract supports shared thresholds, per-user thresholds and per-user overrides. Alerts and blocks use near-real-time estimated spend and take effect within moments. They do not interrupt a request already running, and Databricks explicitly says the result is not an absolute cap on the final bill.
Snowflake separates the auditor from the spender
Snowflake’s Cortex AI Gateway controls center on request-level accounting. AI_GATEWAY_USAGE_HISTORY records the authenticated user, gateway, operation and credits for each logged request, retains 365 days and links a request ID to agent traces. A role with MONITOR can audit that history without receiving USAGE permission to generate new traffic. Logging must be enabled or requests are not recorded.
Its enforcement is split across two clocks. Per-user quotas can block a user within minutes after a daily, weekly or monthly credit limit is reached. They are not pooled: ten users with a 100-credit quota can collectively consume 1,000 credits. Shared or custom budgets operate at team or resource scope and can invoke a stored procedure—such as revoking a role’s gateway access—but evaluation can take up to 6.5 hours, or one hour with the low-latency option.
The deployment choice is about failure containment
| Question | Databricks Unity Gateway | Snowflake Cortex AI Gateway |
|---|---|---|
| End-user visibility | CLI shows personal and shared limits; five by default | Audit view is role-gated and request-level |
| Fast isolation | Personal or shared budget block within moments | Per-user quota block within minutes |
| Team ceiling | Native shared threshold | Budget plus automated policy action |
| Final authority | system.billing.usage; external-provider invoice for external models | Snowflake credit history for routed, logged traffic |
Neither design preauthorizes the exact cost of the next request. Databricks can enforce shared limits faster, while Snowflake gives administrators a more explicit separation between rapid per-user containment and slower team automation. In both systems, the practical maximum should sit below the financial maximum: active or recently completed work can cross a threshold before denial takes effect.
The safest operating model is layered. Restrict which models agents may call, set individual limits low enough to absorb enforcement lag, add a shared team control, and keep billing records—not the live budget display—as the reconciliation source. The products differ most in interface and timing; they agree on the important point that a gateway limit is a feedback control, not a prepaid meter.
sources
- Databricks — ug CLI reference: Check your usagedocs.databricks.com
- Databricks — Manage budgets for Unity Gatewaydocs.databricks.com
- Snowflake — Govern Your AI Spend With Cortex AI Gatewaywww.snowflake.com
comments · 0