Start with the call itself. `AI_COMPLETE` is a scalar function, so it is evaluated once per row inside the `SELECT`, composing with `WHERE`, `JOIN` and `GROUP BY` like anything else in the language [1]. That is why the walkthrough's `LIMIT 5` is doing more work than it looks like: five rows, five model calls, five prompts' worth of tokens [19]. Take the `LIMIT` off against the two-million-ticket table the author names and the same statement issues two million calls [8], which is 400,000 times the development run [20]. The SQL text itself doesn't change, and the planner has no opinion about your invoice.
The natural-language predicate deserves a second look for the same reason. `AI_FILTER` is written inside the `WHERE` clause [12], where it reads like a filter and bills like a scan, because the model has to judge a row before that row can be excluded [22]. If you want token spend to track a small result set, the cheap predicates have to reduce the input first, and whether they do is a question for the query profile rather than the tutorial.
The task-specific functions are the part I would adopt on merit. `AI_CLASSIFY` returns a value from a category list you supply, so it groups and aggregates like a normal column instead of prose you parse afterwards [11]. `AI_AGG` takes a whole column against a single prompt and, per the walkthrough, is not bound by the model context window, so there is no chunking loop to write [13]. That is good engineering. It also puts the token accounting somewhere the SQL does not show it, which argues for running it once over a week's slice and reading the usage view before you aim it at full history.
Two meters run per statement: tokens for the function, warehouse credits for the query wrapped around it [2]. The sample cost query sums `token_credits` from `CORTEX_AI_FUNCTIONS_USAGE_HISTORY` [14], so it prices the model side and is silent on the compute side [21]. Hence the advice to give AI work its own warehouse, so the credits separate in billing with no tagging scheme [5]. If that view returns nothing an hour after your first call, the walkthrough says to read it as ingestion latency rather than a missing grant [16], and the view's columns have already changed shape more than once, so check them before you build a dashboard on them [17].
Two more details cost time rather than money. `SNOWFLAKE.CORTEX_USER` is a database role and cannot be granted to a user at all, only to a role [4]. Model availability varies by region and release, which is why `SHOW CORTEX BASE MODELS` belongs before the first `SELECT` [7].
One caveat on all of it. This is a single walkthrough, and it quotes no prices, so nothing here gives you cost per row. Getting that number needs your own average prompt length, a model chosen from your own `SHOW` output [7], and one run against a slice large enough to register in the usage view [14]. The five-row example transfers as a shape. The arithmetic is yours.
