Research-backed calculator guide
Gemini Thinking Token Budget: Estimating Output Costs Under Reasoning
Learn how Gemini thinking tokens affect API bills, estimate low/medium/high reasoning costs, and reconcile forecasts with total_thought_tokens.
Quick answer
Gemini thinking token cost is normally part of the model's output-token charge, not a separate free meter. For a planning estimate, add visible output tokens and estimated thought tokens, divide by 1,000,000, and multiply by the model's applicable output price. Then add input-token cost, and separately account for caching, tools, grounding, or other billable features when they apply. Google's documentation states that the response usage object can expose total_thought_tokens, total_output_tokens, and other token fields, so a forecast should be reconciled against the returned usage after the call. [1] [2] [3]
For example, assume one Gemini 2.5 Pro Standard request has 18,000 input tokens, 900 visible output tokens, and an estimated 2,100 thought tokens. The billable output estimate is 3,000 tokens. At the Google AI Developer API rate checked on November 2, 2026—$10.00 per 1 million output tokens for Gemini 2.5 Pro prompts up to 200,000 tokens—the output estimate is $0.0300. Input at $1.25 per 1 million tokens adds $0.0225, for an estimated request total of $0.0525 before caching, tools, grounding, taxes, or account-specific terms. [1]
That is an estimate, not a promise that thinking will equal 2,100 tokens. Thinking is non-deterministic, and the right way to replace the estimate is to log the actual usage fields from each response. A small visible answer can still have a large billable output if the model used substantial internal reasoning.
What is included in a Gemini thinking-token estimate?
A useful estimate has four separate quantities:
- Input tokens: the prompt, conversation history, system instruction, and other input content that the API counts. Use
count_tokensbefore the request when you need a preflight input count, but remember that this is an input-only check. [3] - Visible output tokens: the answer text or other model output that your application receives.
- Thought tokens: tokens generated during internal reasoning. They may not appear as ordinary visible answer text, but Google says they are included in billable usage for supported thinking models. [2]
- Other meters: cached content, tool use, grounding requests, images, audio, or other modality-specific charges. These are not safely folded into a simple text-only formula.
For a text-only first-pass estimate, use:
estimated input cost = input tokens / 1,000,000 × input price
estimated output cost = (visible output tokens + estimated thought tokens) / 1,000,000 × output price
estimated request cost = estimated input cost + estimated output cost
The output price must come from the rate for the exact model and billing mode. Do not copy a Gemini 2.5 Pro rate into a Gemini 3 or Gemini 4 estimate, and do not mix Standard, Batch, Flex, or Priority prices. Google's pricing table labels the output row as including thinking tokens for the relevant model and lists different prices by tier. [1]
A simple planning method when thought tokens are unknown
Before the first production calls, thought-token usage is unknown. You can still build a transparent range rather than hiding the uncertainty in one number. Start with the visible output you expect, then choose planning multipliers for thought tokens based on your own workload hypothesis. For example, you might model low as 0.5 times visible output, medium as 1.5 times, and high as 3 times. These are planning assumptions, not Google defaults and not universal percentages.
If the visible answer is 900 tokens, those assumptions produce 450, 1,350, and 2,700 estimated thought tokens. The corresponding estimated billable output is 1,350, 2,250, and 3,600 tokens. At $10.00 per million output tokens, output-only estimates are $0.0135, $0.0225, and $0.0360. Add input cost to each scenario. If your prompt is 18,000 tokens at $1.25 per million, the same input cost is $0.0225 in all three cases, giving totals of $0.0360, $0.0450, and $0.0585.
This range is more useful than claiming that thinking always adds a fixed percentage. Google notes that thinking is not guaranteed for every request even when it is enabled, so some calls may return no thought parts. [2] Once you have enough logs, replace the assumed multipliers with observed percentiles from your own request class. Keep separate distributions for short classification, retrieval-heavy prompts, coding, tool use, and multi-turn agents because averaging unlike workloads can make the budget misleading.
Worked cost example: Gemini 2.5 Pro Standard
The following example uses dollars per 1 million tokens and a prompt below the 200,000-token pricing breakpoint. It assumes a paid Gemini API Standard request with no context-cache charge, no grounding charge, no image or audio input, and no taxes or negotiated discount. The prices are vendor-published rates checked on November 2, 2026, while the token counts are illustrative estimates. Gemini 2.5 Pro is listed at $1.25 per million input tokens and $10.00 per million output tokens for prompts up to 200,000 tokens. [1]
| Step | Input or assumption | Formula | Output |
|---|---|---|---|
| 1. Count the prompt | 18,000 input tokens | 18,000 / 1,000,000 × $1.25 | $0.0225 input cost |
| 2. Forecast visible answer | 900 visible output tokens | Workload estimate | 900 tokens |
| 3. Forecast reasoning | 2,100 thought tokens | Workload estimate; not a vendor guarantee | 2,100 tokens |
| 4. Combine output meters | 900 + 2,100 | visible output + thought tokens | 3,000 billable output tokens |
| 5. Price output | 3,000 billable output tokens | 3,000 / 1,000,000 × $10.00 | $0.0300 output cost |
| 6. Add request cost | $0.0225 + $0.0300 | input cost + output cost | $0.0525 estimated total |
The visible answer is only 900 tokens, but the estimate prices 3,000 output tokens because the thought budget is included. If you omitted reasoning, you would estimate $0.0090 for output and $0.0315 for the request. The 2,100-token assumption therefore adds $0.0210 to this example. At 100,000 identical requests, the modeled total would be $5,250. That monthly figure is only a multiplication of the stated example; it is not a forecast of any provider invoice.
The practical next step is to record the response's usage fields. The token-counting documentation lists total_input_tokens, total_output_tokens, total_thought_tokens, cached-content fields, tool-use fields, and total tokens. [3] Compare the observed thought count with the planning assumption, multiply the observed counts by the rate in force for that model and tier, and flag any request that crosses a pricing breakpoint or adds a separate feature charge.
For a broader side-by-side rate check, use the model pricing comparison. If you need the arithmetic across input, output, and cached tokens, the AI token cost calculator keeps those meters separate.
Why max_output_tokens can change the estimate
max_output_tokens is not a “visible answer only” allowance for thinking models. Google's thinking documentation says it sets the maximum number of tokens a response can generate, including thought tokens. If the model hits the limit while reasoning, the response can be incomplete or have truncated or empty visible output while the generated thought tokens are still billable. [2]
That creates two different budgeting controls. Lowering a small output cap can reduce the maximum combined generation, but it can also cut off useful answers. Lowering the model's thinking level is a separate way to trade reasoning depth for cost and latency where the selected model supports it. For Gemini 3 and later, Google documents thinking_level; Gemini 2.5 and earlier use thinking_budget, and the parameters should not be mixed across those model generations. [2]
Do not treat a high max_output_tokens value as a prediction that the model will consume the full cap. Treat it as a ceiling, record actual usage, and test the failure mode. A reasonable cost guardrail can combine a per-request estimate, a maximum combined-token limit, and an alert when observed thought tokens exceed the workload's expected percentile.
How to reconcile an estimate with an actual call
Use a three-stage ledger:
- Before the call: record model, region or endpoint if relevant, billing tier, prompt-token count, expected visible output, thought-token assumption, and the prices used. Mark every non-vendor number as an estimate.
- After the response: store request ID, status, visible output count,
total_thought_tokens,total_input_tokens,total_output_tokens, cached tokens, tool-use tokens, and any grounding or modality events. Thecount_tokensmethod helps with input preflight, while response usage is the evidence for what the call generated. [3] - During invoice review: group calls by model and tier, compare usage-derived cost with provider billing exports, and investigate variance caused by retries, caching, tools, rounding, taxes, credits, or a rate change. Google's billing guide says usage can be monitored in AI Studio and describes prepay and postpay plans, so an API estimate should not be treated as the account ledger. [4]
The AI API invoice reconciliation calculator is useful for the last step. Keep an explicit “unexplained variance” field instead of forcing every difference into thought tokens. A duplicate retry, a grounded search request, or a different model version can create variance that reasoning alone does not explain.
Common estimation mistakes
Pricing visible text only. This understates the bill for thinking models because internal reasoning is part of the output charge. Use visible output plus observed or explicitly estimated thought tokens.
Using a single universal reasoning ratio. A ratio from one coding prompt is not a reliable ratio for every classification or agent workflow. Use workload-specific samples and report the assumption beside the result.
Confusing input preflight with final usage. count_tokens checks input. It does not tell you how many thought tokens the model will generate. Use the response usage object after the call. [3]
Ignoring the pricing breakpoint. Gemini 2.5 Pro has different listed rates for prompts at or below 200,000 tokens and prompts above that threshold. Check the current table before applying a rate. [1]
Treating the cap as a bill. max_output_tokens is a ceiling, not an invoice line. It can still truncate a response when thinking consumes the combined budget. [2]
Mixing API billing surfaces. Google AI Studio, Google Cloud or Vertex-style deployments, free access, paid access, and batch processing may have different terms. Name the surface and tier in every estimate. Google's billing guide also describes account tiers and monitoring, which are separate from the per-token arithmetic. [4]
FAQ
Are Gemini thinking tokens billed as output tokens?
For supported thinking models, yes: Google's documentation says pricing when thinking is enabled sums output tokens and thinking tokens. The pricing table expresses the applicable output price as including thinking tokens. [1] [2] The exact amount still depends on the model, tier, request, and actual generated usage.
Can I calculate Gemini thinking token cost from visible output alone?
No. Visible output alone is insufficient when thinking tokens are generated. You can create a planning estimate by adding an explicitly labeled thought-token assumption, but the reliable post-call value comes from response usage such as total_thought_tokens. [2] [3]
Does max_output_tokens limit only the answer shown to the user?
No. It applies to the combined generation budget that includes thought tokens. A low limit can cause incomplete or empty visible output if reasoning reaches the cap first, and Google warns that already generated thought tokens can still be billed. [2]
Does every Gemini request generate thought tokens?
No guarantee should be assumed. Google's documentation says thinking behavior is non-deterministic and a request may return without thought parts even when thinking is enabled. Build a range for planning and reconcile against actual response metadata. [2]
What should I log for a Gemini cost audit?
At minimum, log the model, billing mode, input-token count, visible output count, total_thought_tokens, cached tokens, tool-use tokens, request status, and request identifier. Keep the price snapshot and date used in the estimate. The token guide documents the main usage fields, while the billing guide explains account-level monitoring and plans. [3] [4]
Is Gemini 2.5 Pro Batch automatically the right choice for a cheaper estimate?
Not automatically. Google lists separate Batch rates, but Batch changes processing behavior and suitability. Compare the workload's deadline and operational needs with the published Batch input and output prices; do not apply a Batch rate to an interactive Standard call. [1]
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.