Looker Conversational Analytics: pricing, data tokens, and what Looker AI costs from October 2026

Looker Conversational Analytics is Google's natural-language layer on top of Looker: you type a question, it writes the query against your LookML model, runs it and returns an answer with a chart. It is currently free to use without limits, and that ends on 1 October 2026. From that date Google enforces a monthly data token quota per instance and bills overage at $3.00 per 1M input data tokens and $20.00 per 1M output data tokens. If you have rolled it out to a team on the assumption that it came with the platform, this is the number to look at before the quarter closes.

The figures here were read from Google's own Looker pricing page on 19 August 2026. Nothing is estimated except where we say so.

What Google is actually metering

Conversational Analytics usage is measured in what Google calls data tokens, which it describes as quantifying the data processing and model orchestration behind an answer: translating natural language into a Looker query, routing to the right tools, and assembling secure context. Usage splits into two meters.

Input data tokens are everything sent to the model. That covers the prompt somebody typed, the conversational history of the session, and any relevant context such as metadata and agent instructions. That last part matters, because context is sent on every turn. A long conversation about one dashboard is not one question, it is a growing prompt resent each time somebody follows up.

Output data tokens are everything the model generates and sends back: the natural-language response, the API call or SQL query it wrote to retrieve the data, any visualization it created, and the reasoning it shows in Thinking mode. Thinking mode output is billed like any other output.

The included allowance, by subscription tier

Every Looker platform subscription comes with a monthly pool. These are the published allowances:

Two details in that table decide how it behaves in practice. The allocation is applied at the instance level as an aggregated pool shared across all authenticated users on that instance, so it is not a per-seat allowance and adding people to Looker does not add capacity. And every non-production or add-on instance gets the same flat baseline regardless of what tier you bought, which is generous for a genuine dev instance and thin if your staging environment gets used like production.

Tokens reset every month and unused tokens do not roll over, so a quiet August buys you nothing in September. Google also notes the pools are ring-fenced specifically to Looker and are not fungible across other Google data surfaces, which rules out the obvious workaround of borrowing headroom from elsewhere in your Google Cloud commitment.

Output is the meter that runs out

Here is the part worth doing arithmetic on. Every tier is given exactly fifty times more input tokens than output tokens: 60M against 1.2M, 300M against 6M, 1.2B against 24M. But the overage rates are not in a fifty to one ratio. Output costs $20.00 per 1M against $3.00 per 1M for input, so output is 6.7 times more expensive per unit.

Price the included pools at Google's own overage rates and the imbalance is obvious:

A Standard instance is handed $180 of input allowance and $24 of output allowance. Unless your team's questions are enormously long relative to the answers they get back, which is not how anybody uses a chat interface, output is what you exhaust first. So when you model this, model output tokens. Treat the input pool as effectively free and stop worrying about how much context Looker attaches to each turn.

That also tells you which usage patterns are expensive. Long generated explanations, charts, and Thinking mode reasoning all land on the expensive meter. Short factual answers to well-scoped questions land cheaply. A team that uses Conversational Analytics to look up a number is in very different territory from a team using it to generate narrative summaries.

What to do before 1 October 2026

Google is explicit that the current unlimited period exists so customers can establish a usage baseline, and that consumption is tracked and exposed through Looker's System Activity dashboards and Explores. That is the whole assignment. Between now and the end of September you can see exactly what your instance consumes, at no cost and with no quota, and you will not get that opportunity again.

Pull a full month of output token consumption from System Activity, not a week, because analytics usage is lumpy around month end and quarter end. Compare it against your tier's output allowance. If you are at 40% of the pool in a normal month, you have room to grow. If you are already over, you now know your October bill in advance, and you know it in dollars: every extra 1M output tokens is $20.00.

It is worth putting the resulting figure somewhere it will be noticed, because a new metered line item on a cloud bill is the kind of thing that is invisible until it is annoying. Teams that already watch their cloud and SaaS spend in one place will spot it immediately; teams reading a Google Cloud invoice once a quarter will not.

Two other things worth checking. First, whether your non-production instances are quietly doing production work, because their flat 0.12M output allowance is roughly a tenth of the Standard tier and will run out fast. Second, whether Thinking mode is on by default for your users, since its reasoning output bills at the output rate and delivers no numbers.

How this compares to the rest of the Looker bill

In isolation these are small numbers. $20.00 per 1M output tokens against a Looker contract that third-party procurement data puts near $150,000 a year is a rounding error, and for most instances the included pool will cover normal use. The reason to look at it now is not the amount, it is the shape: this is the first genuinely usage-based meter in a product otherwise sold as an annual seat contract, and usage-based meters are the ones that surprise people.

It also does not change the underlying economics of Looker, which are set by the platform contract and the seat entitlements rather than by tokens. Google publishes no dollar price for any Looker edition, and a Viewer seat cannot open Explore or SQL Runner at all, which is why new questions keep routing back to the same few Developer seats. We laid all of that out with the source figures in our Looker pricing breakdown, and untangled which of the two Google products you are actually buying in Looker Studio vs Looker.

If the metered model does not suit you

Conversational Analytics is a good fit when you already run Looker, already have a maintained LookML model, and want a chat surface on top of the metrics that model defines. The tokens are the cheap part of that arrangement. The expensive part is the model underneath, and the fact that a question outside it still becomes a ticket.

If what you actually want is for people to ask questions of the database without a semantic layer in front of it, that is what we build. Agentsql connects read-only to BigQuery, Snowflake, Postgres or MySQL, turns a plain-English question into SQL, runs it, and returns a chart, a table and a one-line answer with the SQL shown every time so an analyst can check the logic before anyone trusts the number. There is no LookML to write first, pricing is on the page rather than behind a sales call, and it starts at $49 a month. Plenty of teams run both: Looker for the governed numbers they watch every week, something lighter for the questions in between. If you are still choosing platforms, Looker vs Tableau and the BI tools comparison put the options side by side.