Budgets, Quotas, and Monitors: The Cost Controls I Map Before Agents Go Wider

Running Snowflake in the Agent Era, Part 3 of 4. The cost_center tag from Part 1 finally earns its keep, and I learn which control actually stops spend and which only tells me about it.

Part 1 ended with a query I was proud of. It grouped QUERY_METERING_HISTORY by QUERY_TAG and told me, for every Adaptive Warehouse, who or what had spent the credits. Every pipeline and every agent session on the platform sets a query tag, so the answer was precise.

Then a colleague asked the obvious follow-up: “Great. What stops it?”

That query is a report. It tells me after the fact. An agent does not get tired at six in the evening, and a Cortex Agent’s orchestration tokens never show up as a warehouse query at all. So in the same AWS proof of concept I used for Part 1 (a POC, not production), I set out to map the cost controls Snowflake now offers against the questions I actually need answered: which team spent it, which person spent it, which agent spent it, and what changed that nobody predicted.

I tried four of them hands-on: budgets scoped by the cost_center tag, per-user quotas, cost anomaly alerts, and a budget on a Cortex Agent. The rest of this post comes from the documentation, and I say so where it matters.

Two kinds of spenders, two kinds of credits

In the POC, people and agent sessions spent on the same account. A person runs a dbt model or an ad hoc query. An agent does that too, but it also burns tokens that never touch a warehouse.

Cortex Agents (generally available since November 2025) show why. Orchestration is charged by the tokens it uses. Custom tools run on a warehouse and incur warehouse cost. One question from a user can produce both kinds of spend.

That split runs through every control in this post. Snowflake measures warehouse compute in credits and AI services in AI credits, and the documentation is explicit that the two are different units and cannot be added together. A per-user quota watches either warehouse compute or AI domains, never both. An anomaly monitor tracks one credit family. If you want one number per team, you will build it from two.

Four questions, four controls

This is the map I ended up with.

• Which team? Custom budgets scoped by a tag such as cost_center.
• Which person? Per-user quotas.
• Which agent? A resource budget on the Cortex Agent object.
• What changed that nobody predicted? Cost anomalies, and anomaly monitors for a narrower scope.

They differ in the way that matters most: what happens when a limit is crossed. Snowflake’s AI cost governance page describes per-user quotas as the only AI cost control with built-in enforcement. Budgets notify you and run the stored procedures you attach to them. Anomaly detection tells you once a day. Only the quota blocks.

Budgets by cost center, not by object

In Part 1 I tagged every Adaptive Warehouse at creation with governance.tags.cost_center (the tag name is illustrative). This is where that tag pays off.

A custom budget can track objects by a tag and value pair instead of by a list of objects. Every object carrying the pair counts, including objects that inherit the tag from a parent, such as tables in a tagged database. An object can count toward several budgets, so a central platform budget and a team budget can watch the same warehouse. New warehouses with the right tag join the budget without anyone editing it, which is the whole point: the budget follows the cost model, not the inventory.

GRANT APPLYBUDGET ON TAG governance.tags.cost_center TO ROLE budget_admin;
USE SCHEMA budgets_db.budgets_schema;
CREATE SNOWFLAKE.CORE.BUDGET data_platform_budget();
CALL data_platform_budget!SET_SPENDING_LIMIT(1000);
CALL budgets_db.budgets_schema.data_platform_budget!SET_RESOURCE_TAGS(
  [
    [(SELECT SYSTEM$REFERENCE('TAG', 'governance.tags.cost_center', 'SESSION', 'APPLYBUDGET')), 'data_platform']
  ],
  'UNION');

The limit here is illustrative. SET_RESOURCE_TAGS takes an array of tag references and values, plus 'UNION' (any pair matches) or 'INTERSECTION' (all pairs must match). It replaces whatever tags the budget had before, and a budget takes up to 20 resource tags by default.

Two timing rules belong in your runbook. After you change a tag on an object, it can take up to six hours to show up in tag-based budgets. And tag changes made in the first two days of a month are applied to the prior month’s usage, which will confuse anyone reconciling month-end numbers.

Budgets can also act. A custom action runs a stored procedure when spend reaches a threshold, based on projected or actual consumption, and a cycle-start action can undo it when the monthly cycle restarts. In the POC, that is where I met the first surprise: a budget action fired later than I expected. The docs explain why. Thresholds are evaluated periodically, and Snowflake’s AI cost governance page says budget thresholds take up to eight hours to act, or up to two hours with the latency optimized option. A budget is a lagging control. Plan for that.

Shared resources are different. When several teams use the same AI features, a budget can count only the credits used by tagged users. Budgets for AI features became generally available in April 2026. The same user-tag model extends to shared warehouses, where the budget tracks each user’s share of interactively issued query cost and leaves out idle time, very short queries, cloud services overhead, and automated work such as tasks.

Per-query showback with QUERY_TAG

Budgets tell me a cost center crossed a line. They do not tell me which pipeline or which agent session pushed it there. That is still the job of the Part 1 query.

For Adaptive Warehouses, QUERY_METERING_HISTORY returns per-query credits with USER_NAME, ROLE_NAME, WAREHOUSE_NAME, and QUERY_TAG. QUERY_ATTRIBUTION_HISTORY has no records for Adaptive Warehouses. Our agent sessions set QUERY_TAG exactly as Part 1 describes, so I did not need anything new here.

Snowflake’s cost attribution guidance draws the same line I do. Use object tags for resources and users owned by one group. Use query tags when one application runs queries on behalf of several departments, which is exactly what an agent serving many teams does. The object tag sets the boundary. The query tag explains who crossed it.

Per-user quotas: the only control that blocks

Per-user quotas became generally available in August 2026, and weekly limits followed in September. A quota is an object (SNOWFLAKE.CORE.QUOTA) with a scope of users, a per-user limit per cycle, and an enforcement setting.

USE SCHEMA cost_mgmt_db.quota_schema;
CREATE SNOWFLAKE.CORE.QUOTA ai_quota();
CALL ai_quota!ADD_SHARED_RESOURCE('CORTEX AGENT');
CALL ai_quota!ADD_SHARED_RESOURCE('CORTEX CODE');
CALL ai_quota!SET_PER_USER_LIMIT(120, 'DAILY');
CALL ai_quota!SET_BLOCK_ENFORCEMENT_ENABLED(TRUE, TRUE);

Again the limit is illustrative. Cycles are daily, weekly, or monthly, all aligned to UTC. By default a quota covers every user in the account, and you can narrow it with user tags or name users to include or exclude.

Three details changed how I think about quotas.

Limits are per user, never pooled. Every user in a quota gets the same limit, and there is no collective cap. Snowflake’s own example: a 100-credit quota across 10 users permits up to 1,000 credits. A quota protects you from one runaway user or agent session. It is not a team budget.

Blocking covers AI domains only. Block enforcement applies to AI functions, Cortex Agents, Snowflake CoWork, CoCo (generally available), and AI Gateway (in preview as of September 2026). You can add warehouses to a quota and track them, but block enforcement does not apply to warehouses.

Blocks are fast, not instant. The docs say evaluation is not real time but occurs within minutes, and that spend can overshoot. Their example is a 100-credit limit where a user ends at 130 before the block lands. That matches what I saw in the POC: blocks kicked in later than I expected and spend went past the limit. Add the cycle boundary, where a user can spend a full limit just before the reset and another just after, and you see why the limit should sit below what you can actually tolerate.

When someone legitimately needs more, the documented pattern is a second quota with a higher limit, scoped with an INTERSECTION of user tags, rather than raising the limit for everyone. CoCo also has its own per-user daily credit limit parameters if you want a separate control for that surface.

A budget on the agent itself

A quota limits people. Sometimes I want to limit the agent: a monthly cap on one Cortex Agent, whoever calls it. That is a resource budget for Cortex Agents.

The setup reuses the tag pattern. Tag the agent with ALTER AGENT … SET TAG, create a budget, set a monthly limit, and associate the tag with SET_RESOURCE_TAGS. To make the budget act, you register a stored procedure with ADD_CUSTOM_ACTION that revokes a dedicated agent role at 100 percent, and a cycle-start action that grants it back next month. You can set thresholds up to 500 percent, which lets you reinstate a few users and still keep a hard stop higher up.

ALTER AGENT IF EXISTS my_agent
  SET TAG governance.tags.cost_center = 'data_platform';

In the POC I put a budget on a Cortex Agent, and it behaved like every other budget: the action came later than I wanted. The docs say enforcement can take up to eight hours after the budget is exceeded, or about two hours with the low latency option, and they recommend an early alert at 80 percent. I now treat that 80 percent notification as the real control and the revoke as the backstop.

Two gaps to plan around. Revoking only works if the agent has a dedicated role and users have no other path to it. And requests that start in Snowflake CoWork and call the agent are billed to CoWork, so a budget scoped only to the agent’s tag does not see them. Cover CoWork in the same budget or give it its own.

Catching what nobody predicted

Budgets and quotas only catch what I thought to limit. Cost anomalies catch the rest.

Cost anomaly detection (generally available since December 2025) compares each day’s consumption with the expected range based on prior consumption. It is always on at account and organization level, with no setup. It needs at least 30 days of history, and it stays quiet when the last seven days were under 10 credits. Since July 2026 the notifications can also go to Slack, SMS, or a webhook through a notification integration.

In the POC an account-level anomaly alert caught something real, something none of our budgets or quotas had been set up to watch. That is exactly the job I want from it.

Anomaly monitors (in preview as of August 2026) narrow the scope. A monitor is defined by object tags and service types, so you can watch one cost center instead of the whole account. Each monitor tracks one credit family, credits or AI credits, so one cost center that spends both needs two monitors. An account can have 20 monitors, monitors work in a single account, they recompute daily, and they cannot split a shared resource’s spend by user. I have only read about monitors so far.

The order I would roll it out

This is a recommendation, not the order we followed in the POC.

1. Tag first. Warehouses, agents, and users. Every other control reads tags.
2. Budgets per cost center. Tag-scoped, with an early notification threshold.
3. QUERY_TAG showback. So a crossed budget leads to a pipeline or session, not a guess.
4. Per-user quotas with block on AI domains. Limits below what you can tolerate, because of overshoot.
5. Resource budgets on the riskiest agents. Dedicated roles, an 80 percent alert, CoWork covered.
6. Anomaly alerts routed to the team channel. Then monitors per cost center once you trust them.

What these controls do not do

None of these is a hard real-time limit. Budgets act on a delay of hours. Quotas act within minutes and overshoot. Anomalies arrive daily and need 30 days of history.

Quotas cannot block warehouse spend. For warehouses, the resource monitors from Part 1 are still the control that stops intake, and on an Adaptive Warehouse they disable it rather than suspend it.

There is one open question I could not settle from the docs, and I would like you to test it. The shared warehouse budget page says it attributes user cost using QUERY_ATTRIBUTION_HISTORY boundaries, and that view has no records for Adaptive Warehouses. Neither that page nor the per-user quota page says whether user-tag budgets or the warehouse domain of a quota cover Adaptive Warehouses. If you run them on Adaptive Warehouses, compare their numbers with QUERY_METERING_HISTORY before you trust them.

Durable cost models on variable spenders

Part 1 closed on durable models on variable compute. Part 3 is the same idea one level up. The tag is the durable model. People and agents are the variable spenders. Budgets follow the tag, quotas follow the person, resource budgets follow the agent, and anomaly detection watches for what none of them expected.

The lesson from the POC was not a number. It was learning which control acts, how fast, and which one only reports.

Budgets, Quotas, and Monitors: The Cost Controls I Map Before Agents Go Wider was originally published in Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.