What AI Analytics Actually Costs Per Question

The line item nobody models

AI analytics pricing is usually quoted per seat or per platform. The cost that decides whether the deployment survives is per question, and it is almost never in the proposal.

It matters because the whole pitch is that questions become cheap enough to ask freely. If each one costs a dollar in compute, "ask anything" is a budget conversation, not a feature. Model that number before you sign, not in month five when finance asks.

The three layers

Model inference

A single analytics question is rarely one model call. A realistic chain:

• Interpret the question and retrieve relevant schema or metric definitions
• Generate the query
• Validate or repair it, often a second call when the first attempt fails
• Summarize the result set into an answer

That is three to five calls. Input tokens dominate, because schema context, metric definitions, and few-shot examples are large while the question is small. A question carrying 15,000 tokens of schema context and returning 800 tokens of output costs somewhere between half a cent and eight cents at 2026 frontier-model pricing, depending on which model tier you route to.

For an agentic system doing multi-step root cause, multiply by the step count. A five-step investigation with an intermediate result fed into each subsequent prompt runs 10 to 25 cents.

Warehouse compute

This is the layer that surprises people, and it is frequently larger than inference.

A generated query is not a tuned query. It does not know your clustering keys, it will happily scan a full fact table, and it has no reason to prefer the pre-aggregated table over the raw one. On a consumption-priced warehouse, a single badly-shaped question against a large fact table can cost more than a hundred well-shaped ones.

Budget 2 to 20 cents per question on a mid-sized warehouse, with a long right tail. The tail is the problem, not the average.

Continuous monitoring, if you have it

Systems that watch metrics rather than waiting to be asked run queries whether or not anyone is looking. This is usually the largest cost line by a wide margin and it is entirely invisible in a per-seat quote.

A chain monitoring 20 metrics across 400 stores and 30 categories hourly is running a large number of aggregations continuously. Well-built systems do this as a handful of wide scheduled aggregate queries, not 240,000 individual ones. Ask the vendor which it is. The difference between those two implementations is roughly two orders of magnitude on your warehouse bill.

A worked example

A 400-store retailer, 200 licensed users, of whom 40 are genuinely active. Assume 8 questions per active user per week.

• Ad hoc questions: 40 users x 8 per week x 52 = 16,640 per year
• Inference at 4 cents average: $666
• Warehouse compute at 8 cents average: $1,331
• Continuous monitoring, well-implemented: $4,000 to $15,000
• Continuous monitoring, naively implemented: $80,000 to $400,000

The ad hoc side is a rounding error against a platform subscription. Inference cost is not the thing to negotiate.

The monitoring implementation is the entire variable, and it is a property of the vendor's architecture that you cannot change after purchase. It is also not something any proposal discusses.

What to ask a vendor

"Who pays for warehouse compute?" If the answer is you, the vendor has no incentive to write efficient queries, and this shows up in the bill within a quarter. If the vendor pays, ask what limits they impose, because there will be some.

"How many queries per hour does continuous monitoring run at my dimensionality?" Ask for the number, not the reassurance. Then price it against your warehouse's rate card yourself.

"Are results cached, and for how long?" Analytics questions repeat heavily. Fifteen people asking about last week's margin on Monday morning should produce one query. Caching typically cuts total cost 40 to 70% and many implementations do not have it.

"What is the model routing policy?" Sending every step to a frontier model is a 5 to 10x cost multiplier over routing simple steps to a smaller one. This is also where LLM-agnostic architecture pays for itself: if you can point the system at your own keys and choose the tier per step, you control this line directly instead of inheriting the vendor's margin on it.

"What are the guardrails on a runaway query?" Statement timeouts and bytes-scanned caps. Without them, one generated cross join produces a memorable invoice.

How to control it

1. Pre-aggregate the common shapes. Most questions hit the same handful of grains. Materializing daily store-category aggregates cuts per-question warehouse cost by an order of magnitude and improves latency at the same time.
2. Cache aggressively. Analytics data is not real-time. A five-minute cache on identical questions is free money.
3. Route by step complexity. Query generation needs a strong model. Summarizing a returned result set does not.
4. Cap and alert. A per-user daily spend cap and a warehouse credit alert. Cheap to add, and the thing you will wish you had.
5. Meter the monitoring separately. It is the dominant line and it should be visible on its own, not blended into a platform fee where nobody can see it grow.

Key takeaways

• Cost per question is the number that decides whether the deployment survives, and it is almost never in the proposal. Model it before signing.
• A single question is three to five model calls, and input tokens dominate because schema context is large while the question is small. Half a cent to eight cents ad hoc; 10 to 25 cents for a multi-step investigation.
• Warehouse compute usually exceeds inference. A generated query does not know your clustering keys and will scan the full fact table. Budget 2 to 20 cents with a long right tail, and the tail is the problem.
• Continuous monitoring is the dominant line and is invisible in per-seat pricing. Well-implemented as scheduled wide aggregates it runs $4K to $15K a year. Naively implemented as per-cell queries it runs $80K to $400K.
• That implementation difference is roughly two orders of magnitude, is fixed by the vendor's architecture, and cannot be changed after purchase. Ask which it is.
• Caching cuts total cost 40 to 70% because analytics questions repeat heavily, and many implementations do not have it.
• Controls that work: pre-aggregate common grains, cache identical questions, route simple steps to smaller models, set per-user spend caps and warehouse credit alerts, and meter monitoring as its own line.