Snowflake’s legacy Cortex cutoff is account-specific—and a late test will not save inactive accounts

Snowflake has published a pending behavior change that will make 12 legacy SNOWFLAKE.CORTEX functions fail in accounts it classifies as inactive. The unusual part is the classification rule: Snowflake looks for use of any listed legacy function from July 9 through October 6, 2026. If an account had none, calling one after the bundle ships does not change that status. Snowflake also says it will not redirect failed calls automatically to their replacements. (Snowflake behavior-change notice)

The change sits in the 2026_08 behavior-change bundle. Snowflake says that bundle was introduced as disabled by default in release 10.37, so administrators can enable it for testing before a later planned move to enabled-by-default and eventually generally enabled; those later dates remain subject to change. (2026_08 bundle status)

Why a search-and-replace is not enough

The affected set spans completion, classification, translation, sentiment, document parsing, token counting, answer extraction and embeddings. Snowflake maps them to the newer AI_* interface, but its migration guide divides the work into direct replacements and calls whose arguments, output shape or error semantics change. (Migration guide)

Three examples show the operational risk. AI_CLASSIFY returns a labels array rather than the legacy label field. AI_SENTIMENT returns an object with categories instead of a numeric score. And AI_COMPLETE uses row-level error handling: failed records return NULL by default rather than necessarily stopping successful rows, unless callers request error details. Those are downstream contract changes, not namespace cleanup. (Migration guide)

The same guide warns that changing a dynamic-table definition can trigger reinitialization, replacing a UDF used by a dynamic table can break the next incremental refresh, and replacing views can drop grants. It recommends finding both recent query-history calls and references embedded in views, tasks, procedures, UDFs and dynamic tables; application code, notebooks, Streamlit apps and BI-issued SQL need a separate inventory because SQL metadata scans do not reach them. (Migration guide)

What teams should do now

First, check the bundle state and reproduce the change in a test account or clone rather than enabling it blindly. Second, inventory every listed legacy function across SQL history, object definitions and external code. Third, classify each call as a direct rename or a contract migration, then test schemas, JSON paths, vector dimensions and failure handling—not only whether the statement compiles. Snowflake provides example discovery queries and recommends EXPLAIN CHANGES for dynamic-table work. (Migration guide)

Python users have another dependency boundary: Snowflake says inactive accounts using legacy APIs in snowflake.cortex.* should upgrade snowflake-ml-python to version 2.4.0, whose backend calls the replacement AI Functions, or move to AI Function APIs in snowflake.snowpark.functions. (Snowflake behavior-change notice)

The practical lesson is that “inactive” does not mean “unimportant.” A disaster-recovery account, dormant environment or rarely run scheduled job may contain exactly the legacy call that the 90-day usage test misses. The safe migration test is therefore an inventory of code and objects, not a last-minute invocation intended to keep the old interface alive.