Snowflake AI Credits Cost: Not Warehouse Credits, and How to Cap It

Last updated: August 2026

The Snowflake AI bill that surprises somebody usually lands the month after a proof of concept goes wide. Finance pulls the warehouse credit trend, sees it flat, and cannot work out where the money went. It went into a different currency.

Snowflake meters AI features in AI Credits, not the platform credits your warehouses consume. Separate flat rate, separate metering service types, separate ACCOUNT_USAGE views. Budget AI work as a percentage uplift on warehouse spend and you will be wrong by a wide margin.

Here is the estimate you should be able to build before running anything: what each component bills for, the token constants that decide how big the bill gets, the two controls that work, and the trap that breaks chargeback reports.

Snowflake AI Credits cost is a separate currency from compute

Snowflake's pricing docs split consumption in two. Platform Credits are the default price for all other usage, varying by edition and region. AI Credits apply to the AI features listed in Table 6 of the Snowflake Service Consumption Table, and the docs are explicit that they price flat regardless of edition (Standard, Enterprise, Business Critical, VPS) or region. A Business Critical account in a premium region pays the same per AI Credit as a Standard account in us-east-1, so your blended credit rate tells you nothing about AI spend.

There is one rate lever, and it is a data residency decision rather than a discount negotiation. The rate follows the account parameter CORTEX_ENABLED_CROSS_REGION: ANY_REGION, AWS_GLOBAL, GCP_GLOBAL or AZURE_GLOBAL allow global routing at the lower rate, while DISABLED or a pinned region pays the higher regional rate. Snowflake publishes both figures (2.00 and 2.20 USD per AI Credit at the time of writing) and applies automatic discounts based on annual contract value, so treat them as a starting point rather than your rate. Worth knowing before you model it: the docs state that capacity discounts do not apply to AI Credits, so whatever you negotiated on platform credits does not carry across. The durable shape: roughly a ten percent premium for keeping inference at home.

AI Credits are additive to compute, not a replacement. The warehouse running a query containing AI_COMPLETE still bills platform credits for that query's full duration, and SQL generated by Cortex Analyst still costs warehouse time. Every estimate needs both lines.

What each AI service actually bills for

There is no single AI meter. Each service has its own unit, which is why a spreadsheet built on "tokens" alone never reconciles.

Note the two units that are not tokens. AI_PARSE_DOCUMENT bills on the number of document pages processed, so a 40-page contract costs the same whether it is dense legalese or whitespace. Cortex Search serving bills per GB per month, unrelated to query volume. Rates for both live in the Service Consumption Table, not in the feature docs.

The token constants nobody puts in plain language

A token is roughly four characters of text, varying by model and media type. Fine for prose, useless for anything else. Snowflake publishes fixed constants for the non-text cases that almost nobody quotes:

• Documents: 970 tokens per page. A 20-page PDF through AI_EXTRACT is 19,400 input tokens before your extraction schema, and 10,000 such documents is 194 million tokens.
• Audio: 50 tokens per second. A ten-minute support call is 30,000 tokens of input before you write a word of prompt. An hour is 180,000.
• Images: model dependent. Token equivalence is determined by the model used, so there is no single constant. Measure it rather than assume it.
• AI_CLASSIFY labels are not free. Labels, descriptions and examples count as input tokens for each record processed. This is the most expensive misunderstanding in AI SQL.

Work that through, because it is where estimates blow up. Twelve categories with a one-line description and two examples each is maybe 700 tokens of scaffolding. Classify four million tickets and that scaffolding alone is 2.8 billion input tokens, billed on every row. The ticket text you care about may be a rounding error next to it. The fix is arithmetic in advance, then a decision: trim descriptions, drop examples, or pre-filter rows a WHERE clause could handle for free.

Which functions bill input only, and which bill input plus output

Half these functions bill only what you send. The rest bill what comes back too, which makes verbose output a real cost lever on some and irrelevant on others.

• Input tokens only. AI_SIMILARITY, AI_EMBED, the SNOWFLAKE.CORTEX.EMBED_* family, and Cortex Guard, metered against the output tokens of the AI_COMPLETE call it screens.
• Input plus output. AI_COMPLETE, AI_CLASSIFY, AI_FILTER, AI_AGG, SNOWFLAKE.CORTEX.SUMMARIZE, AI_TRANSLATE and their earlier versions, plus AI_EXTRACT and AI_REDACT.
• Special case. For EXTRACT_ANSWER, billable tokens are the sum of the tokens in the from_text and question fields.
• No AI Credits at all. AI_COUNT_TOKENS incurs only the compute cost to run it, which makes it usable as an estimator.

So telling AI_COMPLETE to be concise is a genuine cost control, and capping generated length is worth doing on every batch job. Telling an embedding function the same does nothing. Redaction and extraction sit on the expensive side, which surprises people who assume extraction is read-only.

How to estimate an AI bill before you run anything

AI_COUNT_TOKENS exists so you can size a workload without paying for it. It takes the function name, the model name where one is needed, the input text, and any options that affect the count.

-- AI_COUNT_TOKENS bills warehouse compute only, no AI Credits.
-- Run it on the real corpus, not a sample, if the length distribution is skewed.
WITH sized AS (
    SELECT AI_COUNT_TOKENS(
               'ai_complete',
               'claude-sonnet-5',
               'Summarise this support ticket in two sentences: ' || ticket_body
           ) AS input_tokens
    FROM support.tickets
    WHERE created_at >= DATEADD('day', -30, CURRENT_DATE())
)
SELECT
    COUNT(*)                                   AS rows_to_process,
    SUM(input_tokens)                          AS total_input_tokens,
    ROUND(SUM(input_tokens) / 1000000.0, 2)    AS millions_of_input_tokens,
    ROUND(AVG(input_tokens), 1)                AS avg_tokens_per_row,
    MAX(input_tokens)                          AS worst_row
FROM sized;

The gotcha, straight from the docs: AI_COUNT_TOKENS estimates input tokens only. It does not estimate output tokens, which also bill on every function in the input-plus-output list above. For classification that barely matters. For summarisation it does, so add a ceiling: cap generation at 150 tokens per row, add 150 times the row count, and you have a defensible upper bound.

SELECT AI_COUNT_TOKENS(
    'ai_classify',
    'Refund never arrived and the agent hung up on me.',
    [
        {'label': 'billing', 'description': 'charges, refunds, invoices, payment failures'},
        {'label': 'shipping', 'description': 'delivery delays, lost parcels, tracking'},
        {'label': 'product_defect', 'description': 'item arrived broken or does not work'},
        {'label': 'agent_conduct', 'description': 'complaints about how staff behaved'}
    ]
) AS tokens_per_row;

-- Now strip the descriptions and run it again. The difference is what those
-- descriptions cost you on EVERY row in the table.

Cortex Search bills whether or not anyone searches

Serving is incurred per GB per month of uncompressed indexed data while the service is available to respond to queries, and the docs say plainly that this applies even if no queries are served. It is a standing charge on an index, not a usage charge on a search.

Which produces the most common avoidable AI cost I see: the proof-of-concept search service nobody dropped. No queries, no users, nothing pointing at it, billing every hour until someone runs DROP CORTEX SEARCH SERVICE. Warehouse-oriented cost reviews never catch it, because it stops touching a warehouse once built.

Four meters sit behind one search service. CONSUMPTION_TYPE in CORTEX_SEARCH_DAILY_USAGE_HISTORY separates the first three:

• SERVING. Charged per gigabyte-month of indexed data, metered at one-second resolution.
• EMBED_TEXT_TOKENS. Embeddings are recomputed each time a row is inserted or updated, so a churny source table is a recurring embedding bill rather than a one-off indexing cost.
• BATCH. Batch Cortex Search charges on the size of the search index and how long the batch job runs, excluding startup time, plus the tokens embedded for the input queries. A rental rather than a subscription, which suits scheduled bulk matching.
• Warehouse compute. Refreshing the service, orchestrating embedding jobs and building the index all need a virtual warehouse. Platform credits, billed separately, absent from the AI Credit total.

Storage is a flat rate per terabyte. And the credits-per-GB figures in most walkthroughs are worked examples from documentation, not published rates. The actual rate lives in the Service Consumption Table.

Agents are additive, and Cortex Analyst changes its unit inside one

Agents are where estimates come in several times low, because people model a turn as one unit of something. Snowflake's guidance: agents incur charges for orchestration and for the tools they use. Orchestration on tokens, Cortex Analyst per token, Cortex Search depending on index size and how long it persisted, custom tools on warehouse size and runtime.

One question that plans, calls Analyst to generate SQL, runs it on a warehouse, then calls Search to ground a follow-up touches four meters. Three bill AI Credits, one bills platform credits, and none appears in the others' totals.

The detail almost everyone misses: standalone Cortex Analyst bills on the number of messages processed, counting successful HTTP 200 responses only, and token volume in those messages does not affect the bill. Invoked through Cortex Agents, token count starts affecting cost. Same tool, different billing behaviour depending on how it was called. Size an agent programme on the standalone per-message rate and the model is wrong for the agent path.

Agents are also what you expose to non-engineers, and a system that decides for itself how many tool calls to make gives them no stable unit economics. Cap it rather than forecast it.

Per-user quotas and budgets: the two controls that work

Resource monitors are warehouse-scoped, the wrong shape for this problem. When an analyst points AI_COMPLETE at a forty-million-row table from a notebook, warehouse credits barely move so the monitor never fires. AI Credits move a great deal. There was no user-scoped control until per-user quotas, an open preview available to all accounts.

A quota monitors one of five domains: WAREHOUSE, AI FUNCTION, SNOWFLAKE INTELLIGENCE, CORTEX AGENT or CORTEX CODE. Two of those names are historical rather than descriptive: SNOWFLAKE INTELLIGENCE is the domain for Snowflake CoWork and CORTEX CODE for Snowflake CoCo. Warehouse compute cannot share a quota with AI domains, because the units differ, so plan for two quota objects per group of users.

USE SCHEMA cost_mgmt.quotas;

CREATE SNOWFLAKE.CORE.QUOTA analyst_ai_quota();

-- AI domains only. Warehouse compute cannot share a quota with these,
-- because platform credits and AI Credits are different units.
CALL analyst_ai_quota!ADD_SHARED_RESOURCE('AI FUNCTION');
CALL analyst_ai_quota!ADD_SHARED_RESOURCE('SNOWFLAKE INTELLIGENCE');
CALL analyst_ai_quota!ADD_SHARED_RESOURCE('CORTEX AGENT');

-- Monthly ceiling per user, plus a daily one to survive a bad afternoon.
CALL analyst_ai_quota!SET_PER_USER_LIMIT(120);
CALL analyst_ai_quota!SET_PER_USER_LIMIT(20, 'DAILY');

-- Scope by tag so joiners and leavers do not need a quota edit.
CALL analyst_ai_quota!SET_USER_TAGS(
    [
        [(SELECT SYSTEM$REFERENCE('TAG', 'cost_mgmt.tags.department',
                                  'SESSION', 'APPLYBUDGET')), 'analytics']
    ],
    'UNION'
);

-- Warn on projected overrun, then actually stop the spend.
CALL analyst_ai_quota!ADD_NOTIFICATION_THRESHOLD(80, 'PROJECTED', TRUE);
CALL analyst_ai_quota!SET_ADMIN_EMAILS('dataplatform@example.com');
CALL analyst_ai_quota!SET_BLOCK_ENFORCEMENT_ENABLED(TRUE);
CALL analyst_ai_quota!SET_REFRESH_TIER('TIER_1H');

Notes before enabling block enforcement. Quotas run on a monthly cycle aligned to the UTC calendar month, and custom cycles are not supported, so a quota will not follow a fiscal calendar. Block enforcement covers the AI domains only, not warehouse compute, which can be tracked in a separate quota but never blocked. Creating quotas needs the SNOWFLAKE.QUOTA_CREATOR database role plus CREATE SNOWFLAKE.CORE.QUOTA on the schema. And there is no implicit ceiling: until you call SET_PER_USER_LIMIT, nothing is capped. Run GET_PER_USER_USAGE_PREVIEW over a recent date range first, because a limit below what your heaviest legitimate user already consumes turns a cost control into an incident. The enforcement itself is fast, evaluated within minutes of a spend event rather than on the quota's measurement task, though changes to a limit or to scope take roughly fifteen minutes to propagate, and a user can overshoot slightly before the block lands.

Resource budgets are the object-scoped counterpart, covering AI services including Snowflake CoWork and Cortex Agents, with resources attached via ADD_RESOURCE and a SYSTEM$REFERENCE handle. Add them by tag, not by name: historical data for the month is only backfilled for resources added using a tag, so naming an agent mid-month starts you at zero. The catch is latency. The default refresh interval is up to about six and a half hours, reducible to roughly one hour at around twelve times the evaluation cost, and Snowflake puts enforcement actions at up to eight hours normally or two hours latency-optimised. That is a long time for a runaway batch job, which is why you run both.

The chargeback trap: total-cost views versus supplementary views

ACCOUNT_USAGE carries two families of AI usage views: one representing total cost per feature, one for supplementary analysis that overlaps the first. Sum them and you get a number that never matches the invoice, usually discovered when finance asks about the gap.

Build reporting on these: CORTEX_AI_FUNCTIONS_USAGE_HISTORY, CORTEX_AGENT_USAGE_HISTORY, CORTEX_ANALYST_USAGE_HISTORY, CORTEX_SEARCH_DAILY_USAGE_HISTORY, SNOWFLAKE_COWORK_USAGE_HISTORY, CORTEX_CODE_CLI_USAGE_HISTORY, CORTEX_CODE_SNOWSIGHT_USAGE_HISTORY, CORTEX_REST_API_USAGE_HISTORY, CORTEX_AI_GUARDRAILS_USAGE_HISTORY, CORTEX_FINE_TUNING_USAGE_HISTORY and CORTEX_PROVISIONED_THROUGHPUT_USAGE_HISTORY. Keep these out of any total:

CORTEX_AISQL_USAGE_HISTORY deserves a specific warning, because it is where older tutorials send you, including Snowflake's own deprecation notice on the retired CORTEX_FUNCTIONS_USAGE_HISTORY. Supplementary, silently missing AI_PARSE_DOCUMENT, and carrying a deprecation date of its own. A dashboard built on it today is both wrong and temporary.

The naming trap. Snowflake Intelligence was renamed to Snowflake CoWork and the usage view followed, becoming SNOWFLAKE_COWORK_USAGE_HISTORY. The metering service type did not. That usage still appears in METERING_DAILY_HISTORY under SERVICE_TYPE = 'SNOWFLAKE_INTELLIGENCE', and the doc URL still carries the old slug. Filter metering for COWORK and you get zero rows, then conclude the feature is free.

-- Step 1: the number that ties to the bill. Note SNOWFLAKE_INTELLIGENCE,
-- which is where Snowflake CoWork usage still meters after the rename.
SELECT
    SERVICE_TYPE,
    SUM(CREDITS_BILLED) AS credits_billed
FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_DAILY_HISTORY
WHERE USAGE_DATE >= DATE_TRUNC('month', DATEADD('month', -1, CURRENT_DATE()))
  AND USAGE_DATE <  DATE_TRUNC('month', CURRENT_DATE())
  AND SERVICE_TYPE IN (
        'AI_FUNCTIONS',
        'AI_SERVICES',
        'AI_INFERENCE',
        'CORTEX_AGENTS',
        'CORTEX_SEARCH',
        'CORTEX_SEARCH_BATCH',
        'CORTEX_CODE_CLI',
        'CORTEX_CODE_SNOWSIGHT',
        'CORTEX_AI_GUARDRAILS',
        'SNOWFLAKE_INTELLIGENCE')
GROUP BY SERVICE_TYPE
ORDER BY credits_billed DESC;

SELECT
    h.USER_ID,
    h.FUNCTION_NAME,
    h.MODEL_NAME,
    h.QUERY_TAG,
    COUNT(DISTINCT h.QUERY_ID)   AS query_count,
    SUM(h.CREDITS)               AS ai_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY h
WHERE h.START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3, 4
HAVING SUM(h.CREDITS) > 1
ORDER BY ai_credits DESC
LIMIT 50;

Two properties of that view matter. It is fast: running queries update roughly every two minutes on a best-effort basis with a five-minute SLA, quick enough for a runaway-query detector rather than a monthly post-mortem. It is also young: usage is included from 5 January 2026 onward, with user attribution, query tag and role fields populated only for data acquired after 16 February 2026, so per-user chargeback for earlier periods cannot be reconstructed. Long-running queries split into one-hour windows, which is why the query above counts distinct QUERY_ID rather than rows.

The rule that keeps chargeback honest is short. One canonical view per feature, never a supplementary view in a total, reconcile against METERING_DAILY_HISTORY before anyone outside the data team sees it. If the two disagree, metering is right.