Price analytics agents by the meter, not the seat

Analytics-agent buyers should stop comparing only the number printed beside a user seat. The more important question is what the platform counts after an agent receives a question.

That is the useful finding in a new Colrows comparison of semantic-layer pricing. The vendor argues that one natural-language request may decompose into many internal calls, so per-metric, per-query, token or capacity meters can make agent traffic scale differently from human dashboard use. Colrows sells a competing semantic-execution product and promotes its own request-based model, so its rankings should not be treated as neutral. But the underlying procurement test is independently visible on vendors’ own pricing pages.

The meters are already different

dbt’s pricing page lists Starter at $100 per user per month and includes 5,000 queried metrics monthly; its Enterprise tiers list 20,000 queried metrics. That means buyers need to model metric requests as well as developer seats.

Cube’s pricing page lists developer seats, request limits and separate hourly rates for dedicated deployments, API instances and Cube Store workers. It also says order-form customers can be billed in arrears for uncommitted seats and usage. A seat comparison alone therefore misses infrastructure and usage dimensions.

ThoughtSpot’s pricing page explicitly offers user and usage pricing views. It says the platform does not meter LLM tokens, while subscription governance can still depend on queries or users; MCP Server and unlimited Spotter can also be add-ons depending on plan.

Microsoft uses another model. Its Fabric Copilot Capacity documentation says Copilot and data-agent usage is charged to Fabric capacity. Administrators can designate one capacity to collect that usage, and the capacity must be at least F2 or P1.

These are not interchangeable units. A workload can look inexpensive under a user meter but expensive under a downstream-query or capacity meter, especially when an agent retries, explores alternatives or decomposes a request.

Run a billing replay before signing

Procurement teams should take 50 to 100 representative business questions and run them through the proposed production architecture. For each question, record:

• semantic metrics requested;
• generated warehouse queries and retries;
• model input and output usage;
• capacity or compute consumed;
• cached results and free re-runs;
• add-ons needed for MCP, governance and observability.

Then price the same replay under each contract. Include a stress case in which an agent issues ten or twenty internal operations for one user request, and ask the vendor which of those operations appear on the invoice.

The output should be a cost per completed business question, not merely cost per seat. Also require a usage export and an alert before quotas or committed capacity are exhausted. Without those controls, the first realistic agent workload becomes the billing experiment.

Colrows’ comparison is vendor-authored, but its central warning survives that conflict: agent pricing is an execution-path problem. Buyers need to inspect every meter between the prompt and the answer.