Snowflake Cortex Code Cost Control in 2026 — The Right Way to Set Limits

When I first started using Cortex Code, cost was the last thing on my mind. It’s right there in the Snowsight UI, it feels like a built-in feature, and nothing in the interface tells you that tokens are being consumed behind the scenes.

Then I went digging through the official docs properly — not just the feature overview, but the cost controls section — and found something I hadn’t seen covered anywhere: Snowflake has a native, dedicated cost control system for Cortex Code that most people don’t know exists. Two specific parameters. Per-user. Per-surface. Configurable by any ACCOUNTADMIN in seconds.

This article is specifically about that. If you’re running Cortex Code in your Snowflake account — especially with a team — you need to set these up.

How Cortex Code Billing Works

If you’re new to Cortex Code, I’d recommend reading my earlier post What Is Snowflake Cortex Code and How I Taught Myself to Use It first — it covers what the tool actually does and how to access it in Snowsight. This article picks up at the cost control layer.

Cortex Code runs on two surfaces, each with its own billing model:

Cortex Code in Snowsight — the browser-based UI. Token-based billing tied to your existing Snowflake account. Snowflake will notify users before charges formally begin, but AI service costs are already accumulating underneath.

Cortex Code CLI — the command-line agent. Already billing via token consumption — pay-as-you-go for existing Snowflake accounts, or a subscription model for individual sign-ups.

The key thing to understand: unlike virtual warehouses where you can set a Resource Monitor with a credit quota, Cortex Code has its own separate cost control parameters that standard Resource Monitors don’t cover. You need to set these explicitly.

For the full official billing breakdown, see Snowflake’s Cortex Code billing documentation.

The Two Parameters You Need to Know

Snowflake provides exactly two parameters for Cortex Code cost control. Both are set by ACCOUNTADMIN only, operate on a rolling 24-hour window per user, and are completely independent of each other.

ParameterSurface ControlledDefault
CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USERCortex Code CLI-1 (unlimited)
CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USERCortex Code in Snowsight-1 (unlimited)

And here’s what the values actually mean:

ValueBehaviour
-1 (default)No limit — unlimited access
0Access blocked entirely for that user
Any positive numberAccess blocked once estimated credits exceed that number in the past 24 hours

Full parameter reference: Cost controls for Cortex Code — Snowflake Docs

Setting Account-Level Limits

This is the first thing I’d do — set a sensible default for all users at the account level. If someone goes over it, they’re blocked until the rolling window resets. No silent runaway spend.

-- Cap all users at 20 credits per day for CLI
ALTER ACCOUNT SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;

-- Cap all users at 20 credits per day in Snowsight
ALTER ACCOUNT SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;

To remove an account-level limit and restore unlimited access:

ALTER ACCOUNT UNSET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER;
ALTER ACCOUNT UNSET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER;

For the full ALTER ACCOUNT syntax reference, see ALTER ACCOUNT — Snowflake Docs.

Setting Per-User Limits (Override)

User-level settings override the account-level setting for that specific user. Everyone else keeps the account default.

-- Power user gets a higher CLI limit than the account default
ALTER USER power_user SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 50;

-- Junior analyst gets a tighter Snowsight limit
ALTER USER junior_analyst SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 5;

-- Block a service account or contractor from Snowsight entirely
ALTER USER contractor_account SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 0;

Setting the value to 0 blocks access completely for that user on that surface. Useful for service accounts that should never be touching Cortex Code interactively.

To remove a user-level override and fall back to the account default:

ALTER USER junior_analyst UNSET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER;

See ALTER USER — Snowflake Docs for the full syntax.

A Practical Setup for a Real Team

Here’s how I’d configure this for a typical data engineering team — let’s say you have senior engineers, analysts, and a few service accounts:

-- Step 1: Set sensible defaults for the whole account
ALTER ACCOUNT SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;
ALTER ACCOUNT SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;

-- Step 2: Give senior engineers more headroom on CLI
ALTER USER senior_eng_1 SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 50;
ALTER USER senior_eng_2 SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 50;

-- Step 3: Block service accounts from both surfaces
ALTER USER airflow_svc SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 0;
ALTER USER airflow_svc SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 0;

ALTER USER dbt_svc SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 0;
ALTER USER dbt_svc SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 0;

If you’re using dbt projects natively inside Snowflake, you’ll already have dedicated service accounts set up — I covered that in detail in How I Wired Snowflake’s Native dbt Projects to Airflow. Those same service accounts should be blocked from Cortex Code with a 0 limit.

Service accounts should never be using Cortex Code. Setting them to 0 explicitly means even if someone accidentally grants CORTEX_AGENT_USER to a service role, the credit limit acts as a safety net.

Auditing Who Has Custom Limits

Snowflake provides a script in the official docs to list all users with per-user overrides. This is exactly what you need for a quarterly governance review:

-- Audit all users with a custom CLI credit limit override
EXECUTE IMMEDIATE $$
DECLARE
  current_user STRING;
  rs_users RESULTSET;
  res      RESULTSET;
BEGIN
  CREATE OR REPLACE TEMPORARY TABLE _param_overrides (user_name STRING, param_value STRING);

  SHOW USERS;
  rs_users := (SELECT "name" FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())));

  FOR record IN rs_users DO
    current_user := record."name";

    EXECUTE IMMEDIATE
      'SHOW PARAMETERS LIKE ''CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER'' IN USER "' || :current_user || '"';

    INSERT INTO _param_overrides (user_name, param_value)
      SELECT :current_user, "value"
      FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
      WHERE "level" = 'USER';
  END FOR;

  res := (SELECT * FROM _param_overrides);
  RETURN TABLE(res);
END;
$$;

To audit Snowsight overrides instead, swap CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER for CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER in the SHOW PARAMETERS LIKE clause. Run both regularly. This script is taken directly from the official Snowflake cost controls page — I haven’t modified it.

What Happens When a User Hits Their Limit

When a user’s rolling 24-hour usage exceeds the configured threshold, that surface returns an error telling them the daily credit limit has been reached. They can’t use it again until enough time passes for usage to drop below the limit. The other surface is unaffected — hitting the CLI limit doesn’t lock them out of Snowsight.

Admins can adjust or remove the limit at any time to restore access immediately, without waiting for the window to roll.

This is worth communicating to your team before you set limits — nobody likes being surprised by a sudden block mid-workflow. Set the limits, tell people what they are, and tell them who to contact if they need a temporary increase.

One More Layer: Monitor Actual Usage Too

The credit limits control access — they stop runaway spend. But you also want visibility into what’s being consumed before limits are hit. Pair your limits with a monitoring query:

sql

SELECT
    DATE_TRUNC('day', start_time)   AS usage_day,
    function_name,
    model_name,
    SUM(tokens_used)                AS total_tokens,
    SUM(credits_used)               AS total_credits
FROM snowflake.account_usage.cortex_functions_usage_history
WHERE start_time >= CURRENT_DATE - 30
GROUP BY 1, 2, 3
ORDER BY usage_day DESC, total_credits DESC;

This tells you which models and functions are driving costs across your account. The credit limits stop the bleeding. This query tells you where the bleeding is coming from.

For a deeper look at how Snowflake bills for AI functions generally — token rates, model pricing differences, and what “output tokens” means for your bill — see my post Snowflake Cortex Pricing — What Every Data Engineer Should Know and the official Snowflake Service Consumption Table which is the source of truth for current credit rates.

The Bottom Line

The right Cortex Code cost control setup in 2026 takes about 10 minutes and covers you completely:

  1. Set account-level daily limits for both CLI and Snowsight — start with 20 credits as a reasonable default
  2. Override upward for power users who legitimately need more headroom
  3. Override to 0 for all service accounts
  4. Run the audit script quarterly to catch drift as people join or leave the team
  5. Monitor cortex_functions_usage_history for spend patterns alongside your limits

The alternative is the default: -1 for every user, unlimited spend, and a bill that arrives before anyone realized the meter was running.