Snowflake Cortex AI services use several credit meters in addition to virtual warehouse compute.
The applicable meter depends on the Cortex feature. A small number of AI_COMPLETE calls may consume little, while a production pipeline can multiply the same function across many rows. Snowflake documentation defines each meter and its unit.
Cortex AI features charge in Snowflake credits. An AI function called within a query creates a Cortex charge, while the surrounding SQL consumes virtual warehouse credits. Snowflake applies the same structure to Cortex Analyst: the AI charge covers text-to-SQL processing, and execution of the generated SQL produces a separate warehouse charge.
LLM-backed functions such as AI_COMPLETE and the AISQL family are metered by tokens processed. A token is roughly four characters, or about three-quarters of an English word. Snowflake publishes model-specific credit rates per million tokens, with larger models generally costing more per token. The Snowflake Service Consumption Table contains the governing rates when another source differs.
COUNT_TOKENS estimates token volume for a model and input, while AI_COUNT_TOKENS is its successor. COUNT_TOKENS excludes the managed system prompt that Snowflake prepends, so its estimate is lower than the billed total.
-- estimate tokens before running an AI function across a table
select sum(snowflake.cortex.count_tokens('mistral-large', review_text)) as total_tokens
from customer_reviews;
Cortex Search bills for virtual warehouse compute used to build and refresh the index, token-based embeddings, serving compute per gigabyte per month of indexed data, storage, and Cloud Services compute. Serving compute accrues while the service remains available, even without searches.
Cortex Analyst is metered by messages processed, and only successful responses that return HTTP 200 are counted. Token volume does not affect the Analyst charge unless it runs through Cortex Agents. Generated SQL incurs a separate warehouse charge when executed.
AI_COMPLETE over a table incurs the model's per-token Cortex rate and the warehouse credits required to scan and process rows. A retrieval application using Cortex Search also incurs embedding and serving charges. Index refreshes consume warehouse time, while the generation step consumes LLM tokens. These charges appear in usage views after execution.
Per-row token cost is multiplied by every row processed. AISQL supports this throughput pattern across tables with millions of rows. Classifying 47 million support tickets that average roughly 340 tokens each processes something near 16 billion tokens a night. A hundred-row test does not represent that production volume. Total cost can be estimated from tokens per row, row count, run frequency, and the rate in the Consumption Table.
Cortex Analyst usage appears in CORTEX_ANALYST_USAGE_HISTORY, Cortex Search has a separate daily usage history view, and aggregate AI spending appears in METERING_HISTORY under the AI_SERVICES service type. The following query returns the last 30 days of Cortex credit consumption.
-- last 30 days of Cortex (AI_SERVICES) credit consumption
select service_type, sum(credits_used) as credits
from snowflake.account_usage.metering_history
where service_type = 'AI_SERVICES'
and start_time >= dateadd(day, -30, current_timestamp())
group by service_type;
No, it adds to it. Cortex charges bill in credits separately from the virtual warehouse that runs your surrounding SQL, so a query calling an AI function pays both meters.
The Snowflake Service Consumption Table lists the credit cost per million tokens for each model, and Snowflake states that this table governs if any other source disagrees. Function documentation avoids quoting fixed rates because they change over time.
Not by default. Cortex Analyst meters per message and counts only successful HTTP 200 responses. Token count affects Analyst cost only when it runs through Cortex Agents, and executing its generated SQL is a separate warehouse charge.
Row volume is the cause, almost always. A small per-row token cost multiplied across millions of rows and a recurring schedule turns a cheap-looking function into a large charge, so estimate token counts and frequency before running at scale.