Decision models have reached the warehouse. Copy the way they ask

On October 19 Snowflake announced Decision Fast, a low-latency decision model in private preview.¹ A decision model doesn’t write prose: you give it some content and a few questions with fixed answers, and it returns the answers with a probability for each option. Its batch-oriented sibling, Snowflake Decision, joined Cortex AI Functions two weeks earlier.² Snowflake says demo round trips stayed under 300 ms, but gives no test setup, pricing or model size.¹

The part worth copying is the way it asks, more than the speed: write each judgement as a question with fixed options, and the answer lands in the table with its probability. The call is one line of SQL: name the model in AI_COMPLETE and every row gets a decision, returned as a column.¹ Databricks is on the same road, with ai_decide in SQL and TypeSafe’s System One API behind its gateway, using almost the same request format.⁵ (Snowflake’s Python example also uses TypeSafe’s SDK, though Snowflake doesn’t say who trained the model.¹)

Type the question and the answer fits a column

Because the question type limits the answer to valid options, the result can be used as a column straight away. A request has a state, such as the text of a ticket, and a set of typed questions.¹ There are three types:²⁵

• Yes/no (called noul in the API): returns the probability of yes, a number column from 0 to 1.
• Choice: picks one option and gives a probability for each, an enum column.
• Score: rates the state on an ordered scale, with a weighted score and a probability per level.

A general-purpose model returns text you parse into JSON, retrying when parsing fails; with typed answers, Snowflake says, the parser and the retry loop go away.¹

Probability is the way out: act when sure, hand off when not

The probability decides whether an answer can be used: set a threshold, act above it, and send the rest to a larger model or a person. Snowflake’s example is a 0.99 for routing to Billing, ready to compare against a threshold.¹ The Decision launch post also suggests letting the model judge how hard a request is and sending the hard ones to a larger model.² That is a suggestion without data; the threshold and the hand-off are yours to build.

In my post on d1 I argued for routing by confidence, and in the one on OpenJev I criticised a gateway policy for squeezing probabilities into block-or-allow. Snowflake returns them intact in the SQL result,² so routing is a WHERE clause, and storing the probability with the decision lets anyone check later how sure the model was.

Two speeds: pick by how long you can wait

Choose the tier by one question: is someone waiting for the result? For whole tables that can wait, use snowflake-decision, for review categories, ticket queues or answer QA.² When someone is waiting, use snowflake-decision-fast: routing a ticket while it is still being typed, real-time fraud checks, an agent’s first triage step.¹ Snowflake’s docs draw the same line: batch for large tables, the REST API for latency-sensitive work.³

Open-ended work such as summaries and free-form extraction is, by Snowflake’s own account, a poor fit² and stays with a general-purpose model. Numbers that must be exact, like amounts and metric definitions, belong in fixed SQL and code.

The biggest saving sits in front of the large model

Ranked by payoff, there are three places for it.

First, route in front of the large model, which saves the most expensive calls. A hypothetical: a pipeline sends a million requests a day to a general-purpose model. If the decision model handles 80% of them with high confidence, large-model calls drop to 200,000 a day. Measure that 80% on your own data.

Second, bulk labelling, which saves output tokens and retries. AI_COMPLETE bills both input and output tokens, with the warehouse on top.⁴ A decision model writes nothing: the Databricks example asks three questions for 238 input tokens and 0 output tokens.⁵ A general model writes JSON, often with a justification, pays for every output token and reruns rows that fail to parse. Decision has no price yet, so the exact saving can’t be computed.

Third, live decisions, which save people from waiting. Under 300 ms, a decision fits inside a flow someone is waiting on, like filing a ticket into the right queue on submit. That number comes from a demo with no load or p95 (the time within which 95% of requests return), so load-test it first.

Three things to do before you copy it

• List the decisions your warehouse already makes: CASE WHEN branches, keyword rules, manual labels. Any with a short, fixed set of answers is a candidate.
• Measure the error rate on your own data, multiply by daily volume, and ask whether the business can live with that many mistakes.
• Store the probability, model name and question version with each decision. Snowflake promises rapid model updates;¹ when the model changes, the same row can get a different answer, and without versions you can’t explain the old one.

Whether this way of asking pays off comes down to three things: where the threshold sits, who takes the unsure cases, and whether a stored decision can be traced.