Tag: snowflake

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.

And here’s what the values actually mean:

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.

Nobody told me to do this.

No manager pinged me. No sprint ticket had “explore Cortex Code” written on it. I stumbled across it one evening while clicking around Snowsight after a long day of debugging dbt models, and three hours later I looked up and realized I hadn’t thought about Jira or Slack once.

That doesn’t happen to me.

I run this blog because I genuinely love poking around the parts of Snowflake that most people scroll past. Cortex Code is exactly that kind of thing — it’s been sitting quietly inside Snowsight, doing something remarkable, and I feel like almost nobody in the data engineering world is talking about it properly. So let’s fix that.

What Cortex Code Actually Is (And What It Is Not)

Before I go any further, I want to be really clear about something that tripped me up when I first read the Snowflake docs — and that I’ve seen cause confusion in the community too.

Cortex Code is not a SQL function you call.

It is not SELECT SNOWFLAKE.CORTEX.CODE_ASSIST(...). It doesn’t live in your query editor the way CORTEX.COMPLETE() or CORTEX.SENTIMENT() do. I wasted about 45 minutes trying to invoke it via SQL the first time, so I’m saving you that pain right now.

Cortex Code is a natural language interface built into Snowsight — Snowflake’s web UI. You access it by navigating to Snowsight, finding the Cortex Code section, uploading or referencing your files, and then literally just… talking to it in plain English. You describe what you want to do with your code or data files, and it responds. Think of it as having an AI pair programmer that lives inside your Snowflake environment, already understands your data context, and doesn’t need you to install anything.

This distinction matters a lot for how you think about using it in production versus exploration.

How to Actually Access Cortex Code in Snowsight

Here’s the step-by-step, because the docs skip over some of this:

Step 1: Log into Snowsight

Go to your Snowflake account URL and log in. Make sure you’re on an account that has Cortex features enabled — Enterprise edition or higher, with the right region support.

Step 2: Navigate to the Cortex Code Section

In the left sidebar, look for the AI/ML or Cortex section. This UI location has shifted slightly across Snowflake releases, so if you don’t see it immediately, use the search bar at the top of Snowsight and type “Cortex.”

Step 3: Upload Your Files Using a PUT Command

This is where it gets interesting. If you want Cortex Code to analyze a specific file — say a Python script, a dbt model, a JSON file, or a CSV — you first upload it to a Snowflake stage using a PUT command in a worksheet:

-- Create a stage if you don't have one
CREATE OR REPLACE STAGE my_cortex_stage;

-- Upload your file from your local machine
PUT file:///Users/yourname/projects/my_dbt_model.sql @my_cortex_stage;

-- Verify it landed
LIST @my_cortex_stage;

Step 4: Reference Your File in the Cortex Code Interface

Once staged, you can reference the file in the Cortex Code interface and start asking questions about it in plain English.

Step 5: Start Prompting

You don’t write SQL. You write sentences. That’s the whole point.

Real Example 1: Analyzing a dbt Model for Performance Issues

This is the first thing I tried, and it immediately earned its keep.

I had a dbt model — let’s call it fct_orders_daily.sql — that was consistently running for 14 minutes in production. I’d stared at it, I’d checked clustering, I’d looked at query profiles. I was going in circles.

I uploaded the file:

PUT file:///Users/bug/dbt_project/models/marts/fct_orders_daily.sql @my_cortex_stage;

Then in Cortex Code I typed something like:

“I’ve uploaded a dbt SQL model called fct_orders_daily.sql. It’s running for 14 minutes. Can you review the logic and tell me where the performance problems likely are? Suggest specific rewrites.”

What came back wasn’t a generic “add a WHERE clause” response. It identified a specific pattern I had — a correlated subquery inside a CASE statement that was executing per-row. It rewrote the logic using a LEFT JOIN with a pre-aggregated CTE instead. The rewrite took the query from 14 minutes to under 3 minutes when I tested it.

Did I feel a little embarrassed that an AI caught something I missed? Absolutely. Did I care? Not really. The model shipped.

Real Example 2: Explaining Someone Else’s Legacy Code

Every data engineer has that one Snowflake procedure. The one that nobody touches. The one with variable names like tmp_ctr2 and no comments anywhere. The one that was written by someone who left the company in 2021.

I had one of those. It was a stored procedure managing some SCD2 logic on a customer dimension table. About 200 lines. No documentation.

I staged the file:

PUT file:///Users/bug/legacy/sp_customer_dim_scd2.sql @my_cortex_stage;

Then in Cortex Code:

“This is a Snowflake stored procedure. Can you explain what it does step by step, in plain English? Then flag any parts that look fragile or risky.”

It produced a section-by-section breakdown that I turned directly into an internal wiki page. It also flagged that the procedure was doing a full table merge without any row count validation before and after — which, it noted, meant a failed intermediate step could silently produce a partial merge with no error thrown.

That was a legitimate production risk I had never noticed. I added the validation. Nobody told me to. I just did it because now I knew.

Real Example 3: Generating New Transformation Code from a Description

This one genuinely surprised me. I described a transformation I needed in plain language — no file, just a description — and asked Cortex Code to write the SQL.

My prompt was roughly:

“I have a table called SALES_EVENTS with columns: event_id, customer_id, event_type (values: ‘purchase’, ‘return’, ‘browse’), event_timestamp, and amount. I want to build a daily summary table that shows, for each customer and each day: total purchases, total returns, net revenue (purchases minus returns), and a flag if they had any browse events that didn’t convert to a purchase on the same day. Write me the Snowflake SQL for this.”

Here’s essentially what it produced (I’ve cleaned it up slightly for readability):

WITH daily_events AS (
    SELECT
        customer_id,
        DATE(event_timestamp) AS event_date,
        SUM(CASE WHEN event_type = 'purchase' THEN amount ELSE 0 END) AS total_purchases,
        SUM(CASE WHEN event_type = 'return' THEN amount ELSE 0 END) AS total_returns,
        SUM(CASE WHEN event_type = 'purchase' THEN amount ELSE 0 END) -
        SUM(CASE WHEN event_type = 'return' THEN amount ELSE 0 END) AS net_revenue,
        MAX(CASE WHEN event_type = 'browse' THEN 1 ELSE 0 END) AS had_browse,
        MAX(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END) AS had_purchase
    FROM SALES_EVENTS
    GROUP BY customer_id, DATE(event_timestamp)
)

SELECT
    customer_id,
    event_date,
    total_purchases,
    total_returns,
    net_revenue,
    CASE 
        WHEN had_browse = 1 AND had_purchase = 0 THEN TRUE 
        ELSE FALSE 
    END AS browse_no_convert_flag
FROM daily_events
ORDER BY customer_id, event_date;

That’s clean, readable, and correct. It took maybe 30 seconds from my prompt to a working query. Normally I’d have spent 10-15 minutes writing and testing that from scratch.

Real Example 4: Reviewing Python Scripts for Data Quality Issues

I had a Python ingestion script that was pulling data from a REST API and writing to a Snowflake stage. I staged it:

PUT file:///Users/bug/scripts/api_ingest.py @my_cortex_stage;

My prompt: “Review this Python script. It ingests data from a REST API into a Snowflake stage. Are there any data quality risks, error handling gaps, or things that might fail silently in production?”

The response flagged three things:

• No retry logic on the API call, so a transient network failure would abort the entire run with no retry
• The script was casting all numeric fields as strings before writing to the stage, which would cause downstream type errors in the COPY INTO command
• There was no check on API response status codes — a 429 (rate limit) or 500 was being handled the same way as a 200

All three were real issues. None of them were obvious from a quick read. Finding them manually would have required either running the thing and watching it fail, or very careful code review.

Where Cortex Code Fits in Your Daily Workflow

I want to be honest here: Cortex Code is not a replacement for knowing what you’re doing. If you give it a bad prompt, you’ll get a bad answer. If you blindly paste its output into production without reading it, eventually something will break and you’ll deserve it.

But used as a thinking partner — as a way to get a first draft, spot what you might have missed, or understand something unfamiliar faster — it’s genuinely useful in a way that saves real time.

Here’s how I’ve actually worked it into my day:

Morning code review pass: Before I open a PR for anything significant, I stage the file and run a quick “what could go wrong with this?” prompt. It takes 2 minutes and has caught things twice in the last month.

Legacy code archaeology: Any time I have to touch something old that I didn’t write, I stage it and ask for an explanation before I touch a single line. This alone is worth it.

First-draft SQL: When I have a new transformation to build and I know exactly what the output should look like but I’m not in the mood to write boilerplate aggregations, I describe the output and let Cortex Code give me a starting point. I always read and edit what it gives me — but starting from something is faster than starting from nothing.

Onboarding help: I’ve started pointing people who are new to the team at Cortex Code for understanding existing models. “Stage the file, ask it to explain it, then come ask me questions.” It makes onboarding conversations much more productive because they’ve already done some of the basic reading.

What It Can’t Do (And Where You Still Need to Think)

I don’t want this to sound like a Snowflake brochure. There are real limitations.

It doesn’t know your data. It can reason about code logic and SQL patterns, but it doesn’t have context about what’s actually in your tables — so it can’t tell you whether a join is correct because it doesn’t know your actual cardinality or data distribution.

Complex business logic still needs you. If your transformation encodes ten years of institutional knowledge about how a specific business process works, Cortex Code can write syntactically correct SQL but it can’t know if the business logic is right.

You have to read the output. Every time. No exceptions.

And the Snowsight UI for it, as of my exploration, is still evolving — some things feel a little rough around the edges. That’s fine. So did Cortex Analyst when it launched, and it’s much smoother now.

A Few Prompting Tips That Actually Help

After spending time with this, here’s what I’ve learned about getting better results:

Be specific about what you want back. “Review this code” is okay. “Review this code and give me three specific things to change, written as SQL snippets I can copy” is much better.

Tell it the context it’s missing. “This table has 2 billion rows and is clustered on event_date” is useful information that shapes the advice you’ll get.

Ask follow-up questions. If the first answer is good but you want to go deeper on one part, just ask. The interface supports back-and-forth.

Tell it what you’ve already tried. If you’ve already checked clustering and it didn’t help, say so. Otherwise it’ll suggest clustering.

Why I Think This Matters

I started this blog because I noticed that a lot of the Snowflake content online is either too shallow (“here’s what the feature is”) or too abstract (“here’s why AI in data warehouses matters”). What’s missing is the honest, practical, “here’s what I actually did and what happened” stuff.

Cortex Code is one of those features that I think is genuinely going to change how data engineers do their day-to-day work — not in a science fiction way, but in the quiet, unglamorous way where you just realize one day that you’re spending three hours less per week on the boring parts and three hours more on the interesting parts.

Nobody told me to learn this. I’m glad I did.

If you try it, tell me how it goes. I’m genuinely curious whether your experience matches mine.

Why Document Processing Matters in 2026

Enterprises store approximately 80-90% of their business data in unstructured formats—PDFs, Word documents, scanned images, contracts, invoices, and reports. Yet most enterprise data warehouses, including Snowflake, were built to handle structured data.

Snowflake’s AI_PARSE_DOCUMENT function, a Cortex AI SQL function that extracts text, data, and layout elements from documents with high fidelity, bridges this gap by allowing you to extract and structure document content directly within Snowflake using AI.

This guide covers everything you need to know about implementing AI_PARSE_DOCUMENT for production use—from understanding the two processing modes, to pricing calculations, to end-to-end RAG pipeline optimization.

What is AI_PARSE_DOCUMENT?

AI_PARSE_DOCUMENT is a fully managed SQL function that transforms unstructured documents into AI-ready structured data. It extracts text or layout from documents stored on internal or external stages, preserving structure like tables, headers, and reading order.

Key capabilities:

• Optical Character Recognition (OCR) and layout extraction modes
• Extract images embedded in PDF and Word documents alongside text, data, and layout elements
• Horizontal scalability for efficient batch processing of multiple documents
• Support for 12+ languages
• Markdown-formatted structured output

Why Should You Use AI_PARSE_DOCUMENT?

Real Business Problems It Solves

Problem 1: Manual Document Processing Bottleneck Extracting data from 10,000 PDFs manually takes 500+ hours at $50/hour = $25,000+ cost. AI_PARSE_DOCUMENT does it in minutes for ~$50-100.

Problem 2: RAG Pipeline Quality Issues Generic text extraction loses document structure (tables, relationships, context), making RAG systems retrieve wrong information. AI_PARSE_DOCUMENT provides high-fidelity extraction that ensures retrieval systems find relevant content with proper context, dramatically improving answer quality.

Problem 3: Unstructured Data Can’t Be Queried 20,000 customer contracts sit in S3 but you can’t answer “How many customers have SLA clauses?” AI_PARSE_DOCUMENT converts them to queryable structured data.

Problem 4: Building Knowledge Bases at Scale Creating searchable knowledge bases from 100,000+ documents requires extracting, validating, and embedding structured content. AI_PARSE_DOCUMENT enables structured output for semantic search and AI reasoning across large document collections.

LAYOUT Mode vs. OCR Mode: Which One Do You Need?

LAYOUT Mode: Perfect for Retaining Precise Layout and Formatting

The preferred choice for most use cases, especially for complex documents is the Layout mode. It’s specifically optimized for extracting text and layout elements like tables, making it the best option for building knowledge bases, optimizing retrieval systems, and enhancing AI based applications.

Best for:

• Technical manuals and documentation
• Financial reports with tables and charts
• Legal documents with structured sections
• Business presentations with layouts
• Any document where structure = meaning

Output format: Markdown with tables, headers, and sections preserved

Real SQL example:

SELECT 
  SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
    TO_FILE('@documents_stage', 'quarterly_report.pdf'),
    {'mode': 'LAYOUT', 'page_split': TRUE}
  ) as parsed_content
FROM document_queue;

OCR Mode: Fast Text Extraction

OCR mode is recommended for quick, high-quality text extraction from documents such as manuals, agreements or contracts, product detail pages, insurance policies and claims, and SharePoint documents.

Best for:

• Scanned documents and images
• Contracts and agreements (when structure doesn’t matter)
• SharePoint documents
• Quick text extraction without layout preservation
• Flat documents without complex formatting

Output format: Plain text only (no tables or structure)

Real SQL example:

SELECT 
  SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
    TO_FILE('@documents_stage', 'insurance_claim.pdf'),
    {'mode': 'OCR'}
  ) as extracted_text
FROM claims_queue;

Image Extraction: New in January 2026

The AI_PARSE_DOCUMENT AI Function can now extract images embedded in PDF and Word documents, alongside text, data, and layout elements. Extracted images can be written to stages or passed directly to other Cortex AI Functions for further analysis.

Use cases for image extraction:

• Enrich data: Extract images from documents to add visual context for deeper insights
• Multimodal RAG: Combine images and text for retrieval-augmented generation (RAG) to improve model responses
• Image classification: Use extracted images with AI_EXTRACT or AI_COMPLETE for automatic tagging and analysis
• Compliance: Extract and analyze images (e.g., charts, signatures) for regulatory and audit workflows

Important: There is no additional cost for image extraction beyond the standard page-based billing for AI_PARSE_DOCUMENT.

How AI_PARSE_DOCUMENT Is Priced

Page-Based Billing Model

The Cortex AI_PARSE_DOCUMENT function incurs compute costs based on the number of pages per document processed.

How pages are counted:

Paged document formats such as PDF and DOCX are billed per page in the file.Image formats including JPEG, JPG, PNG, TIF, and TIFF are billed as one page per image file.For HTML and TXT files, billing is based on every 3,000 characters, with each 3,000‑character block counted as one page. The final block is also billed as a page, even if it contains fewer than 3,000 characters.

Cost Examples by Document Type

PDF Documents:

Word Documents (.DOCX): Same page-based billing as PDFs. 10-page document = 10 pages charged.

Image Files (JPG, PNG, TIF):

Text/HTML Files: Every 3,000 characters = 1 page charged

Supported File Formats

AI_PARSE_DOCUMENT supports:

• PDF files (.pdf)
• Microsoft Word (.docx)
• Images (JPEG, JPG, PNG, TIF, TIFF)
• HTML files (.html)
• Plain text files (.txt)
• Multi-page documents with page filtering

End-to-End Implementation Guide

Step 1: Create a Document Stage

-- Create encrypted internal stage for documents
CREATE STAGE IF NOT EXISTS parse_documents
  DIRECTORY = (ENABLE = TRUE)
  ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');

-- Create external stage for S3/Azure/GCS documents
CREATE STAGE IF NOT EXISTS external_documents
  URL = 's3://your-bucket/documents/'
  CREDENTIALS = (AWS_KEY_ID = '...' AWS_SECRET_KEY = '...');

Step 2: Upload Documents to Stage

1. Using Snowflake UI (Snowsight)

1. Navigate to Data → Databases → Your DB → Stages
2. Select parse_documents stage
3. Click “Upload Files”
4. Select PDFs/documents to upload

Method 2: Using SQL PUT Command

PUT file:///local/path/invoice.pdf @parse_documents;

Method 3: External Stages (S3, Azure Blob, GCS) Documents auto-discovered from S3 bucket path

Step 3: Parse Single Document

-- Simple parse with LAYOUT mode
SELECT 
  SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
    TO_FILE('@parse_documents', 'invoice_001.pdf'),
    {'mode': 'LAYOUT'}
  ) as parsed_json

Output format:

{
  "metadata": {
    "pageCount": 2
  },
  "content": "# Invoice\n\n## Header\n...",
  "pages": [
    {
      "index": 0,
      "content": "# Invoice 001..."
    },
    {
      "index": 1,
      "content": "# Page 2..."
    }
  ]
}

Step 4: Parse Multiple Documents in Batch

-- Batch parse all PDFs in stage
CREATE OR REPLACE PROCEDURE parse_documents_batch()
RETURNS TABLE(
  file_name VARCHAR,
  page_count INT,
  parsed_content VARIANT
)
LANGUAGE SQL
AS
$$
  SELECT 
    file_name,
    (parsed_output:metadata:pageCount)::INT as page_count,
    parsed_output
  FROM (
    SELECT 
      'document_' || ROW_NUMBER() OVER (ORDER BY relative_path) as file_name,
      SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
        TO_FILE('@parse_documents', relative_path),
        {'mode': 'LAYOUT', 'page_split': TRUE}
      ) as parsed_output
    FROM DIRECTORY('@parse_documents')
  );
$$;

-- Execute batch parsing
CALL parse_documents_batch();

Step 5: Extract Structured Data

Once parsed, extract specific fields using AI_EXTRACT:

-- Extract invoice details from parsed content
SELECT 
  file_name,
  SNOWFLAKE.CORTEX.AI_EXTRACT(
    parsed_content:content::VARCHAR,
    'Extract invoice number, vendor name, total amount, and payment terms'
  ) as extracted_fields
FROM parsed_documents
WHERE parsed_content:metadata:pageCount > 0;

Step 6: Load Into Table

-- Create table for structured invoice data
CREATE TABLE invoices_extracted (
  file_name VARCHAR,
  invoice_number VARCHAR,
  vendor_name VARCHAR,
  total_amount DECIMAL(10, 2),
  payment_terms VARCHAR,
  parsed_at TIMESTAMP
);

-- Load extracted data
INSERT INTO invoices_extracted
SELECT 
  file_name,
  (extracted:invoice_number)::VARCHAR,
  (extracted:vendor_name)::VARCHAR,
  (extracted:total_amount)::DECIMAL(10, 2),
  (extracted:payment_terms)::VARCHAR,
  CURRENT_TIMESTAMP
FROM parsed_documents
WHERE extracted IS NOT NULL;

Real-World Use Cases

Use Case 1: Invoice Processing Automation

Scenario: Process 10,000 vendor invoices/month from email attachments

-- Step 1: Parse invoices
WITH parsed_invoices AS (
  SELECT 
    file_name,
    SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
      TO_FILE('@invoice_stage', file_name),
      {'mode': 'LAYOUT'}
    ) as parsed
  FROM invoice_queue
)
-- Step 2: Extract structured data
SELECT 
  file_name,
  SNOWFLAKE.CORTEX.AI_EXTRACT(
    parsed:content::VARCHAR,
    'Extract: invoice_id, vendor, amount, invoice_date, due_date, line_items'
  ) as invoice_data
FROM parsed_invoices;

Cost breakdown:

• 10,000 invoices × 1 page × ~$0.04/page = $400/month
• Compared to manual processing: $25,000/month
• ROI: $24,600/month savings

Use Case 2: Legal Document Analysis

Scenario: Analyze 5,000 contracts for SLA clauses, payment terms, renewal dates

-- Parse contracts with LAYOUT mode (important for structure)
WITH parsed_contracts AS (
  SELECT 
    contract_id,
    SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
      TO_FILE('@contracts_stage', contract_filename),
      {
        'mode': 'LAYOUT',
        'page_split': TRUE,
        'page_filter': [{'start': 0, 'end': 3}]  -- First 3 pages only
      }
    ) as parsed
  FROM active_contracts
)
-- Extract legal terms
SELECT 
  contract_id,
  SNOWFLAKE.CORTEX.AI_EXTRACT(
    parsed:content::VARCHAR,
    'Extract SLA terms, payment schedule, termination clause, and renewal date'
  ) as legal_terms
FROM parsed_contracts;

Cost:

• 5,000 contracts × 3 pages × $0.04 = $600/month
• Saves 100+ hours of legal review time

Use Case 3: Insurance Claims Processing

Scenario: Extract data from 20,000 insurance claim forms (mixed scanned + digital)

-- Use OCR for scanned documents, LAYOUT for digital
WITH claims_data AS (
  SELECT 
    claim_id,
    SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
      TO_FILE('@claims_stage', claim_filename),
      {
        'mode': CASE 
          WHEN claim_type = 'SCANNED' THEN 'OCR'
          ELSE 'LAYOUT'
        END
      }
    ) as parsed
  FROM claims_queue
  WHERE status = 'pending'
)
-- Extract claim fields
SELECT 
  claim_id,
  SNOWFLAKE.CORTEX.AI_EXTRACT(
    parsed:content::VARCHAR,
    'Extract claimant name, claim amount, incident date, claim type, supporting documents list'
  ) as claim_info
FROM claims_data;

Cost: 20,000 × 1 page × $0.04 = $800/month

Use Case 4: Building RAG-Ready Knowledge Bases

Scenario: Create searchable knowledge base from 50,000 product manuals

-- Parse all manuals with LAYOUT mode (preserves structure = better RAG)
CREATE OR REPLACE TASK parse_manuals_daily
  WAREHOUSE = compute_wh
  SCHEDULE = 'USING CRON 0 2 * * * UTC'
AS
WITH parsed_manuals AS (
  SELECT 
    manual_id,
    section_number,
    SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
      TO_FILE('@manuals_stage', file_path),
      {
        'mode': 'LAYOUT',
        'page_split': TRUE
      }
    ) as parsed_content
  FROM manual_queue
)
-- Create embeddings for semantic search
INSERT INTO manual_embeddings
SELECT 
  manual_id,
  section_number,
  parsed_content:content::VARCHAR as content,
  SNOWFLAKE.CORTEX.AI_EMBED(
    'snowflake-arctic-embed-m-v2',
    parsed_content:content::VARCHAR
  ) as embedding
FROM parsed_manuals
WHERE parsed_content:metadata:pageCount > 0;

Benefits:

• Preserves table structure from manuals
• Better semantic search accuracy
• Enables multimodal RAG with extracted images (new Jan 2026)
• Cost: 50,000 pages × $0.04 = $2,000 initial + ongoing embeddings

Page Filtering: Process Specific Pages Only

Sometimes you don’t need to parse entire documents. Use page_filter:

-- Extract only first 5 pages of long contracts
SELECT 
  SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
    TO_FILE('@contracts_stage', 'long_contract.pdf'),
    {
      'mode': 'LAYOUT',
      'page_filter': [{'start': 0, 'end': 5}]  -- Pages 0-4 only
    }
  ) as first_pages
;

-- Extract only page 10 (index 9)
SELECT 
  SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
    TO_FILE('@documents_stage', 'report.pdf'),
    {
      'mode': 'LAYOUT',
      'page_filter': [{'start': 9, 'end': 10}]  -- Only page 10
    }
  ) as page_10
;

Cost reduction: Parsing 100-page contract’s first 5 pages costs $0.20 vs. $4.00 for all pages

Performance Optimization Tips

Tip 1: Use Appropriate Warehouse Size

Snowflake recommends executing queries that call the Cortex AI_PARSE_DOCUMENT function in a smaller warehouse (no larger than MEDIUM). Larger warehouses do not increase performance.

Wrong:

-- Uses 4 credits/hour, no speed benefit
USE WAREHOUSE large_wh;
SELECT SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(...);

Right:

-- Uses 1 credit/hour, same speed
USE WAREHOUSE xsmall_wh;
SELECT SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(...);

Cost difference: Small vs. Large warehouse = 4x cost reduction.
For more AI-powered optimization techniques, see how Cortex Code can cut dbt build times by 48%.

Tip 2: Batch Processing

Process multiple documents in a single query rather than individual calls:

-- GOOD: Batch processing
SELECT 
  file_name,
  SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(TO_FILE('@stage', file_name), {'mode': 'LAYOUT'})
FROM DIRECTORY('@stage')
;

-- BAD: Individual queries (loop overhead)
FOR each_file IN (SELECT file_name FROM stage_list) LOOP
  SELECT SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(...);
END LOOP;

Tip 3: Cache Parsed Results

Don’t re-parse same documents:

-- Cache parsed documents
CREATE TABLE parsed_documents_cache AS
SELECT 
  file_name,
  file_hash,
  parsed_json,
  parsed_at
FROM (
  SELECT 
    file_name,
    MD5(file_content) as file_hash,
    SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(...) as parsed_json,
    CURRENT_TIMESTAMP as parsed_at
  FROM documents
);

-- Check cache before parsing
SELECT 
  COALESCE(
    (SELECT parsed_json FROM parsed_documents_cache WHERE file_hash = MD5(doc_content)),
    SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(...)
  ) as parsed_content
FROM documents;

Tip 4: Use Page_Split Strategically

Split documents only when needed:

-- DON'T: Split for simple text extraction
SELECT SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
  TO_FILE('@stage', 'document.pdf'),
  {'mode': 'OCR', 'page_split': TRUE}  -- Unnecessary split
);

-- DO: Split only for layout analysis or per-page processing
SELECT SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(
  TO_FILE('@stage', 'document.pdf'),
  {'mode': 'LAYOUT', 'page_split': TRUE}  -- Needed for table extraction
);

FAQ: Common Questions About AI_PARSE_DOCUMENT

How accurate is AI_PARSE_DOCUMENT?

AI_PARSE_DOCUMENT uses proprietary Arctic-TILT model to extract text, tables, and entities from PDFs and images with 90% ANLS benchmark accuracy, outperforming GPT-4.

For specific domains (invoices, contracts, forms), accuracy is 93-97% with proper document quality.

What languages does it support?

AI_PARSE_DOCUMENT supports 12+ languages including English, Spanish, French, German, Italian, Dutch, Portuguese, Chinese, Japanese, Korean, Russian, and Arabic.

Can I extract images with no extra cost?

There is no additional cost for image extraction beyond the standard page-based billing for AI_PARSE_DOCUMENT.

What happens if parsing fails?

If a document can’t be parsed, the response includes error information in the errorInformation field. Common causes:

• Corrupted PDF file
• Unsupported file format
• Encrypted/password-protected document
• Extreme image quality degradation

Should I use OCR or LAYOUT mode?

Use LAYOUT if:

• Document contains tables or complex formatting
• Building RAG system (structure improves retrieval)
• Financial/legal documents with sections
• Structure = meaning

Use OCR if:

• Simple text extraction needed
• Scanned documents/images
• Fast processing is priority
• Layout doesn’t matter

How do I integrate this with Cortex Search?

-- 1. Parse documents
-- 2. Create embeddings
-- 3. Build Cortex Search service

CREATE CORTEX SEARCH SERVICE manual_search ON
  SELECT 
    manual_id,
    parsed_content,
    embedding
  FROM parsed_manual_embeddings
  WHERE embedding IS NOT NULL
;

Troubleshooting Common Issues

Issue 1: “Permission denied” Error

Solution: Grant CORTEX_USER role

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE your_role;

Issue 2: Parsing Takes Too Long

Solution: Use smaller warehouse + batch processing

USE WAREHOUSE xsmall_wh;  -- Not medium/large
-- Batch process instead of individual calls

Issue 3: Extracted Data Quality Poor

Solution: Use LAYOUT mode instead of OCR for structured docs

-- Before (poor quality)
SELECT SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(..., {'mode': 'OCR'});

-- After (better quality)
SELECT SNOWFLAKE.CORTEX.AI_PARSE_DOCUMENT(..., {'mode': 'LAYOUT'});

Key Takeaways

1. AI_PARSE_DOCUMENT bridges the unstructured data gap – Transform 80-90% of enterprise data (PDFs, contracts, forms) into queryable structured data
2. Two modes for different needs:
   • LAYOUT: Best for complex documents, tables, RAG systems
   • OCR: Best for scanned documents, simple text extraction
3. Page-based pricing – Cost scales with document pages, not complexity
   • ~$0.04 per page (varies by region/contract)
   • 1,000 invoices = ~$40/month
4. Image extraction (new Jan 2026) – No extra cost, enables multimodal RAG
5. RAG optimization – LAYOUT mode + page structure preservation = better retrieval accuracy
6. Batch > Individual – Process multiple documents in one query for efficiency
7. Smaller warehouse = same speed, lower cost – Don’t use Large/Medium warehouses
8. Page filtering reduces costs – Process only pages you need

External References (Official Snowflake Documentation)

• AI_PARSE_DOCUMENT Official Documentation
• AISQL AI_PARSE_DOCUMENT Function Reference
• Document Processing with Cortex
• Image Extraction from Documents (Jan 2026)
• Document Processing Playground
• Cortex Search Documentation

Next Steps

1. Start small: Upload 10-20 test documents to Snowflake stage
2. Test both modes: Compare OCR vs. LAYOUT output quality
3. Calculate costs: Count pages in your document inventory
4. Integrate: Connect to Cortex Search or AI_EXTRACT for downstream processing
5. Scale: Batch process entire document library

Disclaimer: Pricing and features current as of January 2026. Always verify with official Snowflake documentation for most current information.