Research-backed calculator guide
Gemini Grounding with Google Search: Per-Query vs Per-Prompt Billing
Learn how Gemini Google Search grounding is billed, calculate query fan-out costs, and separate current Gemini 3+ pricing from older per-prompt semantics.
Quick answer
For Gemini 3 and newer models, Google Search grounding is billed by the individual Search query that Gemini generates, not simply by the number of API prompts. Google’s current Gemini API documentation lists 5,000 free Search grounding requests per month shared across Gemini 3 and newer models, then $14 per 1,000 requests. A single customer prompt can produce one or more queries, so the practical estimate is:
grounding fee = max(0, prompts × average non-empty queries per prompt − 5,000) ÷ 1,000 × $14
That estimate covers the Search grounding meter only. Gemini input, output, and thinking-token charges still apply according to the selected model and service tier. Google also documents a default 1,500 grounding-request-per-day limit per project for Gemini 3 and newer models in the paid tier of the Gemini Developer API. [1]
Gemini 2.5 and older models use a different billing semantic in the current grounding documentation: the project is billed per prompt. That means query fan-out should not be multiplied into the grounding meter in the same way for those models. Do not use an old $35-per-1,000 figure as a current Gemini 3+ quote. The current Gemini 3+ documentation describes per-query billing and $14 per 1,000 after the allowance, while the older model-family documentation retains per-prompt semantics. [2]
What “per query” means in Gemini grounding
Grounding with Google Search is a tool workflow. Your application sends a user prompt with the Search tool enabled. Gemini analyzes the prompt, decides whether Search will improve the answer, generates one or more searches, processes the results, and returns an answer with citations. The generated searches are not necessarily identical to the words in the user’s prompt. The API can expose the generated queries in a Search call or grounding metadata, which makes them useful for cost measurement. [3]
This distinction matters because “10,000 grounded prompts” and “10,000 grounding queries” are not interchangeable on Gemini 3 and newer. If every prompt creates exactly one non-empty query, the counts match. If the model averages 1.4 queries per prompt, 10,000 prompts produce an estimated 14,000 billable-unit candidates before the free allowance. If some prompts are answered without Search, or if dynamic retrieval produces no grounding support URL, the chargeable count can be lower than a simple prompt-volume forecast.
Google Cloud’s terminology makes the same distinction. A Grounding Prompt is an end-user prompt for which Gemini makes one or more queries to a Google web index. Each individual query is a Grounding Query, and the documentation’s example charges three queries generated from one question. [4] The names differ slightly between products, so reconcile the actual product and SKU on your bill rather than copying a Developer API estimate directly into an Agent Platform forecast.
Current Gemini 3+ formula
Use four inputs:
- Monthly prompts: the number of successful application requests with Search enabled.
- Average non-empty queries per prompt: measured from response metadata, not guessed from the user’s wording.
- Included queries: 5,000 per month, shared across Gemini 3 and newer models in the Gemini API documentation.
- Excess rate: $14 per 1,000 Search requests, or $0.014 per excess query.
The simple model is:
estimated queries = monthly prompts × average queries per prompt
billable queries = max(0, estimated queries − 5,000)
estimated grounding fee = billable queries × $0.014
The rate is a vendor-published price, while the average fan-out is your workload assumption. Label the result as an estimate until you reconcile it with usage data. If your account has a negotiated enterprise price, a different product SKU, tax, credits, or currency conversion, the invoice can differ. Google Cloud’s pricing page also says its prices are in USD and describes a separate Agent Platform pricing context, so keep the product boundary explicit. [5]
Worked cost example
Assume a US-dollar Developer API estimate for a support assistant during one calendar month:
- 18,000 customer prompts
- 1.4 average non-empty Search queries per prompt
- Gemini 3.8 Flash with Search grounding enabled
- 5,000 included Search requests available to the shared Gemini 3+ allowance
- $14 per 1,000 excess Search queries
- Model token charges excluded from this example
| Step | Assumption or input | Calculation | Output |
|---|---|---|---|
| 1. Prompt volume | 18,000 prompts | Given | 18,000 |
| 2. Query fan-out | 1.4 queries per prompt | 18,000 × 1.4 | 25,200 queries |
| 3. Free allowance | 5,000 queries | 25,200 − 5,000 | 20,200 billable queries |
| 4. Grounding rate | $14 per 1,000 | 20,200 ÷ 1,000 × $14 | $282.80 |
| 5. Model inference | Input, output, and thinking tokens | Not included | Add separately |
The grounding portion of the estimate is therefore $282.80 for the month. The result is not a quote for the full Gemini bill. It excludes model token consumption, retries that create additional successful searches, any other tools, taxes, negotiated discounts, and currency conversion. It also assumes the documented allowance is available to this workload and has not already been consumed by another Gemini 3+ model in the same shared account or project.
The fan-out assumption has a large effect. At one query per prompt, the same 18,000 prompts produce 18,000 queries and an estimated $182.00 after 5,000 free queries. At two queries per prompt, they produce 36,000 queries and an estimated $434.00. The arithmetic is simple; observing the fan-out is the important control.
Per-prompt billing for Gemini 2.5 and older
The current Google Search grounding documentation says Gemini 2.5 or older models are billed per prompt. In that model-version family, the number of searches generated inside one grounded prompt is not the same cost meter as the Gemini 3+ query meter. You should still monitor generated queries for latency, quality, and operational load, but do not apply the Gemini 3+ $0.014 × query calculation without checking the applicable model price sheet.
There is also a historical pricing trap. Older blog posts, forum answers, and internal spreadsheets can preserve a rate from a different model family or launch period. Treat those figures as historical context only. Record the model family, product, and source date before using an older number, then re-check the current pricing table.
A migration plan should therefore have a model column. For each request, record the model ID, API surface, Search tool name, number of non-empty generated queries, and the billing product. A Gemini 2.5-to-Gemini 3 migration can change both the model-token price and the grounding unit. Treat it as a meter change, not only a model-name change.
Quota is not the same as price
A free allowance reduces a charge. A quota or rate limit constrains how much traffic the project can send. Google’s Gemini Developer API documentation describes a default 1,500 Search-grounding requests per day per project for Gemini 3 and newer models in the paid tier. A monthly estimate can be under the 5,000-query allowance and still fail during a burst if requests exceed a daily or other rate limit. [1]
Conversely, a workload can stay under the daily limit and still incur a fee once its shared monthly allowance is consumed. For the worked example, spreading 25,200 estimated queries across 22 working days would average about 1,145 queries per day, but that average does not prove that every day stays below the limit. Use the maximum-day traffic shape, not only a monthly average, for capacity planning.
Google Cloud documents a much higher default daily limit in its Agent Platform context and says to contact an account team for more than one million Grounding Prompts per day. That is a product-specific limit, not evidence that the Gemini Developer API has the same quota. [4] Put the platform name beside every quota in a budget sheet.
How to measure query fan-out instead of guessing
Start by instrumenting the response before optimizing. On the Interactions API, inspect the google_search_call steps and their queries arrays. On the generateContent API, inspect groundingMetadata.webSearchQueries. Count non-empty generated query strings for each request and store the result with a request ID, timestamp, model ID, project, and outcome. The official documentation describes these fields as the record of searches used to ground the response. [3]
Then calculate at least three workload statistics: mean queries per prompt for a simple estimate, P95 queries per prompt for a budget guardrail, and the percentage of prompts that produced no grounding call. The mean drives the monthly forecast. The P95 helps explain burst and worst-case behavior. The no-search percentage tells you whether enabling the tool on every request is creating avoidable work.
If you use dynamic retrieval, include the grounding-support condition in the ledger. Google’s pricing notes say that, with dynamic retrieval, only requests containing at least one grounding support URL from the web are charged for Search grounding. Gemini model costs still apply. [1] That makes a response-level audit more reliable than multiplying all requests with a tool flag.
For reconciliation, compare the application ledger with the provider usage export for the same UTC or account billing period. Investigate differences caused by retries, parallel calls, failed requests, shared allowances, delayed usage records, and requests routed through another project. The AI API invoice reconciliation calculator can help structure the comparison, while the LLM cost calculator and AI token cost calculator cover the separate inference-token layer.
FAQ
Is Gemini grounding charged per prompt or per Search query?
It depends on the model family. Gemini 3 and newer models are documented as per-query: each non-empty Search query generated and executed by Gemini can count toward the grounding meter. Gemini 2.5 and older models are documented as per-prompt. Verify the model ID and current product pricing before applying a formula. [3]
How much does 1,000 Gemini 3 Search queries cost?
After the shared 5,000-query monthly allowance is used, Google’s current Gemini API documentation lists $14 per 1,000 Search requests. That is $0.014 per excess query. It is a grounding-tool charge, not the full cost of the Gemini request, because model tokens and other applicable fees remain separate. [1]
Can one Gemini prompt create several billable queries?
Yes. The Search grounding workflow can automatically generate one or multiple searches. The Google Cloud example shows three queries generated from one end-user prompt, and the Gemini API documentation gives the same operational warning. Measure the response metadata rather than assuming one prompt equals one query. [3] [4]
Does the 5,000-query allowance apply to each model?
The current Gemini API pricing page describes 5,000 free Search requests per month shared across Gemini 3 and newer models. It is not a fresh 5,000 allocation for every model in your project. Google Cloud’s pricing page similarly describes aggregation across Gemini 3 and 4 in its Agent Platform pricing context. Confirm which account, project, or billing product owns the allowance before forecasting. [1] [5]
Are grounding results free if the model tokens are free?
Do not assume that. Search grounding and model inference are separate meters. A free token tier, AI Studio experience, promotional credit, or model-specific allowance does not automatically establish that a production API grounding charge is zero. Check the product-specific pricing table and include token, grounding, quota, and retry assumptions separately.
What should I log for a defensible estimate?
Log the model, API surface, request ID, prompt timestamp, whether a Search call occurred, the non-empty generated query count, support URLs when dynamic retrieval is enabled, response status, retry count, and billed project. Aggregate those fields by billing period, then compare the result with the provider usage record. This turns a headline estimate into an auditable cost model.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.