# Why is the cost of a query in SELECT different than the cost in Snowflake's Query Attribution History?

URL: https://select.dev/docs/reference/faq/using-select/why-is-the-cost-of-a-query-in-select-different-than-the-cost-in-snowflake-s-query-attribution-history
Index of all SELECT docs: https://select.dev/docs/llms.txt

> Explains the methodology gaps (idle time, short queries, acceleration, AI, cloud services, data transfer) that make SELECT's cost-per-query figures typically higher than Snowflake's own attribution.

SELECT and Snowflake use different methodologies to calculate the cost of a query, which can cause the numbers to differ — sometimes significantly.  
Snowflake's Query Attribution History table has several limitations in what it accounts for:

- **Idle time** — Snowflake does not factor in warehouse idle time when attributing cost to queries
- **Short-running queries** — Snowflake excludes queries below a certain execution time threshold
- **Query Acceleration costs** — Snowflake does not include query acceleration service charges
- **Data transfer costs** — Snowflake does not include data transfer costs driven by a query
- **AI costs** — Snowflake does not include AI-related costs (e.g., Cortex) attributed to a query
- **Cloud Services costs** — Snowflake does not include cloud services layer costs

SELECT's cost per query calculation accounts for all of the above. We look at all queries running concurrently in a warehouse alongside granular billing data, then allocate cost to each query proportional to its execution time — including idle time, query acceleration, AI, cloud services, and data transfer costs.  


As a result, SELECT will often report a higher cost per query than what you see in Snowflake's Query Attribution History.  


For a deeper dive into our methodology, see [Calculating cost per query in Snowflake](https://select.dev/posts/cost-per-query).