Summary

  • Google plans separate TabFM model-token billing from 30 October 2026, while non-model BigQuery query work retains slot or bytes-processed charges.
  • The published token formula scales with training rows, prediction rows, columns and n_ensembles; doubling the ensemble count doubles the model-token line for otherwise identical inputs.

The query looks single. The bill will not.

A data team can put labelled rows and unlabelled rows into BigQuery's AI.PREDICT and get a classification or regression result without deploying a separate model. That single SQL statement is the product's appeal. Google's function documentation now gives the appeal a second meter: from 30 October 2026, TabFM tokens consumed by the model will be charged separately, while slots or bytes processed by the non-model parts of the query remain billable. During preview, the documentation says Enterprise and Enterprise Plus usage is billed in slots and on-demand usage by bytes processed. The new arrangement is scheduled, not an invoice already presented to customers on 28 October.

The TabFM description calls it a built-in model for tabular regression and classification. It draws on labelled examples in context rather than a training job that leaves a conventional model artifact behind. That is commercially neat. One can avoid an explicit training-and-deployment project, then discover that every prediction carries a model meter inside the query. BigQuery has turned ease of invocation into an additional unit of sale.

A small parameter with a large multiplier

Google's price table specifies input tokens as (training rows × columns + prediction rows × (columns − 1)) × n_ensembles; output tokens equal prediction rows × n_ensembles. The listed rates are $0.05 per million input tokens and $0.20 per million output tokens. Here “columns” includes the feature columns and target label referenced in the computation. The ensemble parameter counts differently shuffled versions for which the model predicts and averages results. It multiplies both token totals. The documentation also caps included feature columns at 50.

Take an illustrative call with one million labelled rows, 20 columns, 100,000 prediction rows and four ensembles. Google's formula yields 87.6 million input tokens and 400,000 output tokens: $4.38 plus $0.08, or $4.46 in model list charges. Eight ensembles double that model line to $8.92. Those figures are arithmetic examples from the published formula, not observed invoices. They exclude the SQL query's slot or byte charge, storage, contract discounts and any other workload costs. The calculation is useful precisely because it isolates the new meter; the total invoice still depends on the customer's query and contract.

Convenience changes who owns the cost decision

A platform team can govern warehouse capacity and still miss a cost choice embedded in SQL written by an analyst or application developer. The same dataset can be queried with a different ensemble count, a wider feature selection or a larger prediction set, and the model component moves. The old capacity discussion was about how much BigQuery work ran. The new one also asks which model work the query requested. Finance will see a bill; engineering controls the line that makes it grow.

The price per million tokens is low enough to make a one-off experiment look trivial. At production frequency, repetition matters more than a single run. An application calling the prediction function on every refresh can multiply the model line without a new procurement decision. The published formula makes a budget control possible: record row counts, columns, ensembles and call frequency before approving a recurring job. It also makes a sharper product question possible. If another ensemble improves accuracy only slightly, its extra model charge must earn its place in the operating budget.

Google has disclosed the rates, formula and date. It has not supplied a customer invoice or a distribution of real workloads that would show which users will feel the largest change. The next decisive evidence is a post-30 October bill tied to a known query plan and ensemble setting. Until then, the market fact is already clear: the SQL call stays singular while the economic unit splits in two.

Sources