Vertex AI Pricing: Reading the Per-Token Rates

A Vertex AI price table is not a list of numbers to look up; it is a structure with about six moving parts. Learn the structure once and every future version of the table reads correctly, including the models that do not exist yet.

The unit, and what counts as a token

The unit is one million tokens, and input and output are priced separately with output several times dearer. That asymmetry is not a margin decision — generating a token requires a full forward pass while reading a token is part of a single parallel prefill, so the two operations genuinely cost different amounts to serve.

Input is further split by modality, and this is the part that surprises people building anything that takes audio. Google’s pricing page lists Gemini 2.5 Flash text, image and video input at $0.30 per million tokens and audio input at $1.00 per million — the same model, the same request, more than three times the rate depending on what you put in it. A transcription pipeline priced from the text row will be wrong by a factor of three.

Two more inclusions catch people. Reasoning tokens produced by a thinking model are output tokens and are billed as output even though the user never sees them, which is why a reasoning model’s effective cost per visible answer can be several times its headline output rate. And on recent Gemini versions, function declarations you send in the request count toward the input token total: a large tool schema attached to every call is a fixed cost per call, and it is one of the easiest large savings available to anyone who has never looked.

The 200K threshold is a cliff, not a slope

Long-context models carry two rate tiers, split at 200,000 input tokens. Google’s pricing page lists Gemini 2.5 Pro at $1.25 per million input tokens and $10.00 per million output tokens for requests at or below 200K input tokens, rising to $2.50 and $15.00 above it, with cached input at $0.13 and $0.25 respectively.

The important word is request. The higher tier is not applied only to the tokens above the threshold; a request that crosses it is billed entirely at the higher rate, output included. A prompt of 199,000 tokens and a prompt of 201,000 tokens differ by one percent in size and by a hundred percent in price. If your prompt length varies with user data — a long document, a big retrieval set, a chat history that grows — this is a real cliff to defend against, and the defence is a token budget enforced before the call rather than an alert after it.

Not every model is tiered. Google’s current table shows the Flash and Flash-Lite families at a single rate regardless of input length, which makes them predictable in a way the Pro tier is not. Check which behaviour applies before building a cost model on either.

Four multipliers on the base rate

• Context caching, roughly a tenth. Cached input tokens are priced at about 10% of the standard input rate — Gemini 2.5 Flash at $0.03 against $0.30, Flash-Lite at $0.01 against $0.10, on Google’s published table. Anything with a long shared prefix, a large system prompt or a fixed document, is a caching candidate. Cache storage is charged separately per hour, so a cache that is written and rarely read can cost more than it saves.
• Batch and flex, half. Google lists batch and flex rates at half the standard rates: Gemini 2.5 Pro at $0.625 input and $5.00 output, 2.5 Flash at $0.15 and $1.25, 2.5 Flash-Lite at $0.05 and $0.20. You give up latency guarantees. See batch prediction for how to submit the work.
• Tuned models, above the base. A tuned checkpoint is billed at a multiple of its base model’s rate, so a tune that buys a small quality gain over a cheaper base model is often a worse deal than simply using the more expensive base model untouched. Work this out before the tuning run, not after.
• Priority and provisioned tiers, above again. A priority service tier is priced above standard, and Provisioned Throughput is not token-priced at all: you commit to reserved capacity for a term and stop paying per token within it. The break-even is a utilisation calculation, and a commitment used at thirty percent is more expensive than paying retail.

The multipliers compose. A cached prefix inside a batch job gets both discounts, which is how bulk enrichment of a document set against a fixed instruction block ends up an order of magnitude below the naive interactive cost.

A worked example

Assume a support-triage call on Gemini 2.5 Flash: a 6,000-token system prompt shared by every request, 1,500 tokens of ticket text, and a 400-token answer. Rates as published on 11 August 2026 and stated above.

Uncached, standard tier
  input   7,500 tok / 1e6 * $0.30 = $0.00225
  output    400 tok / 1e6 * $2.50 = $0.00100
  total                            = $0.00325 per call

With the 6,000-token prefix cached
  cached  6,000 tok / 1e6 * $0.03 = $0.00018
  fresh   1,500 tok / 1e6 * $0.30 = $0.00045
  output    400 tok / 1e6 * $2.50 = $0.00100
  total                            = $0.00163 per call   (50% lower)

Same work run as a batch job with caching
  cached  6,000 tok / 1e6 * $0.015 = $0.00009
  fresh   1,500 tok / 1e6 * $0.15  = $0.00023
  output    400 tok / 1e6 * $1.25  = $0.00050
  total                             = $0.00082 per call  (75% lower)

Two assumptions are doing work there and both should be labelled. The batch line assumes the cached rate halves with the batch discount, which follows from both being percentage discounts on the same base but is worth confirming on the current table. And cache storage is excluded: at a few requests an hour it would dominate the saving, and at a few thousand it is negligible. The shape of the answer — caching roughly halves this workload, batching roughly halves it again — survives rate changes even when the digits do not.

The products that are not priced in tokens

This is where token-based cost models quietly break. A Vertex AI endpoint serving your own model is billed by node-hour for as long as it is deployed, whether it serves a million requests or none. So is a deployed Vector Search index. So is a Model Garden deployment of an open model. None of these appear in a per-token forecast, and all of them keep billing after the experiment that created them is forgotten.

Grounding is a third category: charged per retrieval rather than per token. Google’s pricing page lists grounding with your own data at $2.50 per 1,000 prompts, and Search-based grounding on a per-1,000-query basis with a monthly no-charge allowance. On a heavily grounded endpoint this line can exceed the generation line entirely.

One piece of good news in the same table: requests that fail are not billed. Only successful responses are charged, so a retry storm against a 400 costs latency rather than money — although a retry storm against a successful-but-useless response costs both.

What to check before you trust a number

1. Confirm the exact model identifier. Rates differ between the Pro, Flash and Flash-Lite lines of the same generation by more than an order of magnitude.
2. Confirm the modality of your input. Audio and video rows are separate from the text row.
3. Confirm which side of the 200K threshold your realistic worst-case prompt sits on, not your average one.
4. Confirm the region and endpoint. Google’s table distinguishes global from regional endpoints, and the two are not always priced the same.
5. Add the node-hour line items — endpoints, indexes, deployed open models — that no token calculator will show you, and put a budget alert on the project so the answer to “is this right” arrives in days rather than at the end of the month.