How to Reduce Snowflake Credits From AI Agent Query Traffic
A five-layer way to tag, attribute, cap and trim the warehouse spend your agents create
To reduce Snowflake credits from AI agent query traffic, first make the traffic visible: give every agent its own user, role and QUERY_TAG, then price each query with the QUERY_ATTRIBUTION_HISTORY view, which reports credits per query and keeps a 365-day window. Once agent spend is its own line item, the fixes are ordinary: isolate a warehouse, cap it with a resource monitor, and cut the repeated, unbounded queries that agents produce. This guide walks through each step.
Key Takeaways
- •Snowflake's QUERY_ATTRIBUTION_HISTORY view reports CREDITS_ATTRIBUTED_COMPUTE per query, carries QUERY_TAG and USER_NAME, and covers the last 365 days, so agent spend can be attributed after the fact.
- •Attribution has gaps: the view excludes warehouse idle time and queries of roughly 100 ms or less, so a warehouse that agents keep awake costs more than the per-query sum shows.
- •The cheapest control is structural: one service user, one role and one dedicated warehouse per agent, so spend is attributable without any query parsing.
- •A resource monitor can hold up to five Notify actions plus one Suspend and one Suspend Immediate action, and it is built for per-interval budgets, not tight per-credit control.
- •Agents waste credits through repetition, not complexity: the same question asked again, unbounded scans, and short bursts that keep a warehouse from suspending.
Why agent traffic is a different cost problem
A human analyst runs a handful of queries, reads the result, and stops. An agent connected to the warehouse through an MCP server behaves differently. It explores: it lists tables, samples rows, retries a failed query with a small change, and asks a follow-up before it answers. Each step is a query, and each query can wake a suspended warehouse. The MCP specification describes tools as model-controlled, meaning the model decides when to call them, so query volume is no longer set by a person clicking a button.
That shifts the unit of cost. Instead of asking which dashboard is expensive, you ask which agent, which prompt and which tool call produced a spike. General Snowflake cost guides, such as Sedai's guide to optimizing Snowflake costs, cover the baseline advice well: match warehouse size to workload, turn on auto-suspend, set budget alerts and review billing regularly. None of it tells you which agent caused the bill, and that attribution step is where agent workloads need extra work.
We treat the problem as five layers, applied in order. Each layer is cheap on its own, and each one makes the next one possible. Skipping straight to caps without attribution means you throttle the wrong workload.
The five layers at a glance
| Layer | What you do | Snowflake feature | What it answers |
|---|---|---|---|
| 1. Identify | Give each agent its own user, role and query tag | ALTER SESSION SET QUERY_TAG, service users | Who sent this query? |
| 2. Attribute | Price each query in credits and roll up by tag | QUERY_ATTRIBUTION_HISTORY | How many credits did agent X use? |
| 3. Isolate | Route agents to dedicated, small warehouses | Warehouse per agent or per fleet | Is agent spend separate from BI and ELT? |
| 4. Cap | Set credit quotas with notify and suspend actions | Resource monitors | What stops a runaway loop? |
| 5. Trim | Remove repeated, unbounded and wake-up queries | Result reuse, LIMITs, auto-suspend | Which queries should not run at all? |
Layer 1: Identify every agent with its own user and query tag
Attribution starts at login. If three agents share one service account, no query-level view can separate them. Create one service user and one role per agent, or at minimum per agent fleet, so USER_NAME in the cost views already tells you who ran what. This also helps governance, because a role-per-agent model gives you a clean list of what each agent can read.
On top of identity, set a query tag at the start of each session. Snowflake documents the syntax on its ALTER SESSION page: ALTER SESSION SET QUERY_TAG = '<string>', reset with ALTER SESSION UNSET QUERY_TAG. We suggest a structured string such as agent=orders-analyst;task=weekly-summary;run=8841, so you can split cost by agent, by task type and by individual run without joining against another system.
The tag has to be set by the MCP server or connection layer, not by the model. If the model can write its own tag, a loop can mislabel its traffic. Put the tag in the server code that opens the Snowflake session, and let the model call only the tools you expose.
Layer 2: Attribute credits per query
With tags in place, the QUERY_ATTRIBUTION_HISTORY view does the pricing. It exposes CREDITS_ATTRIBUTED_COMPUTE alongside QUERY_ID, WAREHOUSE_NAME, QUERY_PARAMETERIZED_HASH, QUERY_TAG and USER_NAME. Latency for the view can be up to eight hours, so treat it as a daily report, not a live meter. Group by QUERY_TAG for per-agent totals, and by QUERY_PARAMETERIZED_HASH to find the same query shape repeating hundreds of times.
Know what the view leaves out before you trust the totals. Per the same documentation, it does not include credit usage for warehouse idle time, and queries of roughly 100 ms or less are too short for per-query attribution. It also excludes cloud services, serverless features, data transfer, storage and AI token costs. In practice, the sum of attributed credits will be lower than the warehouse's metered bill, and the difference is the idle and short-query overhead that agents often create.
Compare the two numbers. Take the warehouse credits for a dedicated agent warehouse over a week, subtract the attributed credits for that warehouse, and look at the remainder. A large remainder means agents are keeping the warehouse awake with many tiny queries, which points you to layer 5 rather than to query tuning.
Layer 3: Isolate agent traffic on its own warehouse
Attribution by tag tells you where credits went. Isolation makes the answer structural. Give agents a dedicated warehouse, sized small, with a short auto-suspend interval, and keep BI dashboards and ELT jobs off it. Now the warehouse's metered credits equal agent spend, including the idle time that per-query attribution misses.
Separate warehouses also stop agent bursts from slowing human users. An agent exploring a schema can queue behind or in front of a dashboard refresh, and the complaint reaches the data team as a slow-warehouse ticket. A dedicated agent warehouse keeps that conflict out of the shared queue and makes sizing decisions simple: if agent queries are slow on a small warehouse, you can test a larger one in isolation and read the credit difference directly.
If you run several agents with very different jobs, such as a quality checker that scans large tables and a lookup agent that reads small dimension tables, consider one warehouse per class of work rather than one per agent. The aim is a clean cost boundary, not a warehouse sprawl that nobody reviews.
Layer 4: Cap spend with resource monitors
Reporting finds waste after the fact. A cap limits the damage while it happens. Snowflake's resource monitor documentation explains that a monitor tracks credit use against a quota and fires actions at percentage thresholds. A monitor can have up to five Notify actions, one Suspend action and one Suspend Immediate action, and thresholds can exceed 100%. Attach one to the agent warehouse with a weekly or daily interval.
Pick the thresholds by what each action does. Notify sends an alert and changes nothing. Suspend lets running statements finish, so a query that started before the threshold can keep consuming credits. Suspend Immediate cancels running statements. The documentation also notes that monitors are meant for tracking spend per interval, not tight hourly control, and that suspension can take time, so it suggests setting thresholds below 100%, such as 90%, as a buffer.
For agent warehouses we would set notify points at 50%, 75% and 90%, a Suspend at 100%, and a Suspend Immediate only if a runaway loop is a realistic risk. A suspended agent warehouse is an outage for the agent, so decide in advance who gets the alert and how fast the quota is raised. A cap you cannot raise quickly will be disabled by the first person it blocks.
Layer 5: Trim the queries agents should not run
Once attribution is running, patterns appear. The usual ones are repeated identical questions, unbounded SELECT statements that scan a large table to look at a few rows, and polling loops that check freshness every few minutes. Each has a direct fix: cache the answer in the agent layer for a defined window, add row limits and column lists to tool templates, and replace polling with a single metadata query on a schedule.
Constrain the tools, not just the model. If the warehouse tool accepts any SQL, the agent can scan anything. If it exposes named operations such as 'row count by day for table X' or 'schema of table Y', most exploratory queries become metadata reads. Pair that with a statement timeout so a bad query ends early; Snowflake's default STATEMENT_TIMEOUT_IN_SECONDS allows a statement to run for two days, per its parameters reference, which is far too long for an agent session. Set a limit for the agent role that matches your longest legitimate query.
Finally, re-run the idle comparison from layer 2 after each change. If attributed credits stay flat but metered credits fall, you removed wake-up overhead. If attributed credits fall, you removed real work. Either result is a measurable outcome you can report.
Where an agent can help run this loop
The five layers are a manual routine: query the view, group by tag, compare against metered credits, and propose changes. Teams that already work in Claude Code or Cursor can script this themselves. Our Cost Agent runs the same loop as an MCP server, flagging idle warehouses and sizing inefficiencies and recommending savings, and the Connectors Agent handles the Snowflake connection. In the OSS edition, access is read-only by default, so the agent reports and recommends while a person applies the change.
We would not hand cost control to an agent that can also change warehouse settings without review. Write access to warehouse size, auto-suspend and monitors belongs behind an approval step, because a wrong change affects every workload on that warehouse. Use the agent for detection and attribution, and keep the approval on the action.
Frequently Asked Questions
How do I see which AI agent used the most Snowflake credits?
Query QUERY_ATTRIBUTION_HISTORY, group by QUERY_TAG or USER_NAME, and sum CREDITS_ATTRIBUTED_COMPUTE over your chosen window. This only works if each agent sets a tag or uses its own user, so do layer 1 first. Remember the view can lag by up to eight hours and excludes idle time.
Why do my attributed credits not match the warehouse bill?
The attribution view leaves out warehouse idle time and queries of roughly 100 ms or less, plus cloud services and serverless costs. Agents that send many tiny queries can keep a warehouse running between them, so the gap is often largest for agent workloads.
Should AI agents get their own Snowflake warehouse?
Usually yes. A dedicated small warehouse makes agent spend a single metered number, keeps agent bursts away from dashboards, and gives you one place to attach a resource monitor. If you have many low-volume agents, group them by workload type instead of one warehouse each.