Snowflake Cortex Analyst cost: what one question actually bills you

Cortex Analyst is billed per message, not per token. Snowflake's Service Consumption Table prices it at 67 credits per 1,000 messages, which works out to 0.067 credits for every question a user asks. What that costs in dollars depends entirely on your credit price. On-demand pricing in AWS US East is roughly $2.00 per credit on Standard, $3.00 on Enterprise and $4.00 on Business Critical, so a single Cortex Analyst message lands at about $0.13, $0.20 or $0.27 respectively. Higher-cost regions and non-AWS clouds push that up. Capacity contracts pull it down.

That number is only half your bill. The per-message rate covers the model turning English into SQL. It does not cover running that SQL. The generated query executes on one of your virtual warehouses at normal warehouse rates, with the usual 60-second minimum billing on resume. For a lot of teams the warehouse line ends up larger than the Cortex Analyst line. Budget for both, plus a separate charge if your semantic model uses Cortex Search to resolve literal values. Rates change, so treat the figures here as the shape of the bill and confirm the current numbers against Snowflake's published Service Consumption Table before you commit.

The three things you are actually paying for

Storage and cloud services charges apply as normal and are usually noise by comparison.

Why the per-message model is unusual, and where it helps

Most Snowflake Cortex features bill per million tokens. Cortex Analyst does not. A three-word question and a 300-word one cost the same. A semantic model with 40 tables costs the same per message as one with four.

That has a practical consequence: investing in a richer semantic model is free at the margin. More verified queries, better column descriptions and more synonyms improve accuracy without raising your per-question price. They also cut retries, and retries are where per-message billing bites.

Because the charge is per message rather than per correct answer, you pay for every attempt. A question the model misreads, a query that errors, a clarifying round trip, a follow-up in a multi-turn conversation: each is a billable message. Three round trips to get one usable answer costs three messages.

Worked example: a 20-person analytics team

Twenty people, five questions each per working day, 20 working days:

• 2,000 messages per month. At 0.067 credits each that is 134 credits. On Enterprise at $3.00 per credit, $402.
• Warehouse compute. Assume a dedicated X-Small warehouse for Analyst queries, 1 credit per hour, staying warm across a roughly eight-hour working day. That is around 8 credits per day, 160 credits per month, $480.

Total, near enough $880 per month, and the compute half is larger than the AI half. Now change one variable. Point Analyst at a Large warehouse instead, at 8 credits per hour, and that compute line goes from $480 to roughly $3,840 while the message line does not move at all. The single biggest lever on Cortex Analyst cost is which warehouse the generated SQL runs on.

Run the same maths at low volume and the picture inverts. A five-person team asking two questions a day generates 200 messages, about 13 credits, $40 on Enterprise. If the warehouse only wakes for those queries and auto-suspends after 60 seconds, compute might be another 3 to 4 credits. Under $60 a month total. At that scale nobody needs to optimise anything.

Where the simple answer breaks

Multi-turn conversations multiply messages. Cortex Analyst is conversational by design. "Show me revenue by region", then "just Q3", then "now split by product" is three messages, not one. Teams estimating from "questions asked" routinely undercount by two to three times because they count topics, not turns.

Suggested questions are messages. If your interface offers clickable follow-ups and users click them, each click bills.

API calls from your own code count. Cortex Analyst is a REST endpoint. If you embed it in an internal app, a Streamlit page or a Slack bot, every programmatic call is a message. An auto-refreshing dashboard that regenerates a question on a timer will quietly generate thousands of messages a month. A retry loop with no backoff can do it in an afternoon.

Cortex Search creates a floor. If your semantic model uses a Cortex Search service so users can filter by values like customer names or SKUs, that service bills for indexing and for serving on an ongoing basis. It is a fixed monthly cost that exists at zero usage. Check it before you assume a quiet month costs nothing.

Warehouse resource monitors will not save you. Resource monitors govern virtual warehouse credits. Cortex Analyst consumption is serverless, so it sits outside them. Use Budgets if you want a spend ceiling and alerts on the AI services portion. This surprises people at exactly the wrong moment.

Result cache still applies to the SQL. If two people ask the same question the same way within 24 hours and the generated SQL matches, the second execution can be served from result cache at effectively no compute. The Analyst message is still billed, because the model still ran. So caching reduces the compute half of the bill, never the message half.

How to see what you are spending

Query SNOWFLAKE.ACCOUNT_USAGE.CORTEX_ANALYST_USAGE_HISTORY for message counts over time, and cross-reference metering views for the credit conversion. Two things worth doing on day one:

1. Give Cortex Analyst its own dedicated warehouse. Not because it needs isolation for performance, but because it makes the compute attributable. Shared warehouses make it impossible to answer "what did this cost us".
2. Tag the warehouse and set a Budget with an alert threshold. Serverless AI spend that nobody is watching is the standard way a $400 month becomes a $4,000 one.

Practical ways to bring the number down

• Right-size the warehouse. Start X-Small. Most Analyst-generated queries are aggregate reads over modelled tables and do not need more. Scale up only when query profiles show spilling.
• Set auto-suspend to 60 seconds on that warehouse. Analyst usage is bursty and idle time is pure waste.
• Build out the verified query repository. Every verified query that matches a common question removes a class of retries and improves first-attempt accuracy, which directly reduces messages.
• Do not wire Analyst into anything that polls. Scheduled refreshes should run saved SQL, not regenerate it from English every time.
• Watch who has access. Per-message billing means cost scales with curiosity, which is usually good. It stops being good when a public-facing or heavily embedded surface exposes it to unbounded traffic.

The comparison people are really making

Against a per-seat BI licence, the maths favours per-message more often than not. At roughly $0.20 a message on Enterprise, a $50 per seat per month licence buys around 250 questions. Very few individuals ask 250 analytical questions in a month. The seat-based tool wins on cost only for genuine power users, and loses badly for the long tail of people who ask three questions a quarter and pay for a seat all year.

The honest caveat: that comparison holds for the AI line item alone. Add the warehouse and the picture depends on how disciplined your compute configuration is, which is a variable you control and most seat-based estimates ignore.

The boundary worth knowing before you budget

Everything above prices questions that Cortex Analyst can actually answer, and that means questions answerable from your semantic model. It is a well-defined and genuinely useful boundary: modelled tables in Snowflake, and literals it can resolve.

Plenty of real questions sit just outside it. "Why did churn spike in March" is often answered half by a cohort table and half by a support thread in Zendesk, a renewal note in HubSpot and a decision someone typed into Slack. No amount of semantic modelling brings that evidence into the warehouse, because it was never structured data in the first place. That is not a shortcoming of Cortex Analyst pricing, it is a scoping question you should settle before you forecast usage, because it determines how many of your team's real questions the tool will absorb. If the answer is "most of ours live across tools rather than in tables", that is a different problem, and Skopx is built for that half.