Conversational Analytics in Looker: Pooled Tokens and Cost Planning

Conversational Analytics answers questions about Looker data in natural language. Its cost cannot be inferred from the visible answer length alone. The useful starting point is the instance’s total measured input and output, followed by the applicable subscription and billing terms. A token is a processing unit for text or data, not a fixed number of words.

Updated 24 October 2026: Google has extended promotional access within fair-use limits. The current price page promises at least 90 days’ formal notice before quota enforcement and overage billing. The previously stated fixed start on 1 October is therefore no longer a reliable planning date.

A shared allowance for the instance

The published monthly allocation is pooled across authenticated users on an instance. It is not a personal Viewer, Standard or Developer allowance. Unused capacity does not carry into the next month or transfer to other Data Cloud products.

Standard in this table is a platform tier, not the Standard user licence. Adding a user or changing a user’s role does not, by itself, enlarge this pool. Permissions should follow the work that needs to be performed.

What the measurements include

Input includes the question, conversation history and supplied context. Output can include generated SQL or API calls, charts and other generated content as well as prose. A 300-token visible summary is therefore not evidence of a 300-token total output.

The Token usage tab in System Activity reports estimated input and output, with breakdowns by agent, user and conversation. Its current documentation specifies a six-hour synchronization delay. Conversation-surface tagging begins with the enabled feature in Looker 26.14 and is not retroactive. An untagged historical row does not establish that no usage occurred.

A cost calculation with explicit assumptions

Published overage rates are USD 3 per million input tokens and USD 20 per million output tokens. The following calculation describes a hypothetical billable month after enforcement begins; it is not a current invoice or a complete Looker cost estimate.

input overage  = max(0, monthly input  - input allowance)
output overage = max(0, monthly output - output allowance)
overage USD    = 3 × input overage / 1,000,000
               + 20 × output overage / 1,000,000

Suppose a Standard instance records 70 million input and 1.5 million output tokens. The excess is 10 million input and 300,000 output: USD 30 + USD 6 = USD 36. This does not include platform licences, user licences, database charges or other separately billed services.

Twenty summaries per day over 30 days, each assumed to consume 300 total output tokens, would use 180,000 output tokens. That is 15% of the Standard output pool, not automatically USD 3.20 of personal overage. With no other usage, the output remains below the pool. With 1.1 million output tokens already consumed, the same routine would take the instance to 1.28 million, giving USD 1.60 of output overage. Input still requires a separate calculation.

Optimize the task, not just the answer length

A short question can require substantial context and generated queries. A long answer is not automatically the largest cost driver. The 50:1 allocation ratio does not establish which pool will run out first; actual consumption determines that.

Clear field definitions, focused Explores and concise agent instructions can reduce unnecessary context and ambiguity. Database-query optimization remains relevant to latency and database work. Its effect on data tokens needs measurement; “query optimization changes nothing” is too broad.

For Explore conversations, Google recommends Fast mode for most questions. Thinking mode adds tokens for visible reasoning, without a documented accuracy advantage over Fast mode. The choice should serve the investigation rather than imply that a more elaborate response is necessarily more correct.