How does Gemini API pricing work for a small team?

Gemini API cost starts with the exact model row, not the word Gemini. Google separates free and paid tiers, fresh and cached input, output and Batch processing, then lists some tools separately. Measure a real request, apply every relevant line, and keep the Gemini consumer subscription out of the API calculation.

Read the Gemini pricing table in layers

An API, or application programming interface, lets software call a Gemini model. Google’s price page quotes text and multimodal use per one million tokens. A token is the unit the model processes. Text tokens are small word pieces; image, audio and video inputs are converted into tokens under Google’s modality rules. A modality is a type of input, such as text, image or audio.

First choose the model. In our pricing ledger, fetched from Google’s page, paid input for Gemini 2.5 Flash is $0.30 per million tokens and output is $2.50. Gemini 2.5 Pro is $1.25 for input and $10 for output under the recorded context condition. These are not interchangeable rows. The cheaper Flash model and the more capable Pro model need to be tested on the same job before price can decide between them.

Second choose the tier. Google’s table can show a free-tier rate and a paid-tier rate for the same model. Free tier means eligible usage billed at zero within its published restrictions and quotas. It does not mean every model, region, feature or volume is free. Paid projects use the paid row and receive the terms attached to that tier.

Third check context and processing mode. Context is all the material a model receives for one request. Some price rows change above a stated context threshold. Batch processing sends a group of jobs for later completion at separate rates rather than waiting for each interactive response. Use the Batch line only if the workflow can tolerate the documented delay.

Finally separate fresh input, cached input and output. Cached context is reusable material stored so later requests do not process the same prefix at the full fresh-input rate. The pricing page lists the cache token rate and, where applicable, a storage charge. Output includes generated response tokens. Google’s token guide says output usage can also include thinking tokens for models that use them, so visible answer length is not a complete meter.

Turn a Gemini workflow into a monthly estimate

Suppose a team classifies 20,000 short records a month with Gemini 2.5 Flash. Each request sends 800 input tokens and generates 100 output tokens. The monthly totals are 16 million input tokens and 2 million output tokens. Using the paid rates recorded above, the model-token estimate is:

16 x $0.30 + 2 x $2.50 = $9.80

That figure is a worked example, not an invoice. It assumes the specified model, paid tier, context condition and no cache, tools, retries, taxes or other charges. The arithmetic is simple because the assumptions are visible. If a request grows to include an attachment or a long conversation, measure again.

Google exposes usage metadata, the machine-readable token counts returned with a model response. Log prompt tokens, cached content tokens, generated candidates and total tokens where the SDK makes them available. A candidate is a possible model response. Use the recorded totals for budgeting rather than estimating only from the human-readable text.

For a prospective large request, use Google’s count-tokens method. The official guide explains that token usage can include instructions, files, cached content and tools as well as the visible prompt. Our guide to context windows covers the capacity side of the same count, while how AI model pricing works explains why output is usually the dearer line.

Free tier, paid tier and prepaid balance

Google’s billing guide explains that eligible new projects can begin on a free tier and move to paid usage through a linked billing account. The current guide describes prepaid credit for applicable accounts, including a minimum initial purchase. Prepaid credit is money added before API use and drawn down as billable requests run. Account arrangements can differ, so treat the billing console as the authority for the project rather than assuming every account follows an old tutorial.

Free testing is useful for proving a prompt and integration. It is not a production budget. Record what the same measured traffic would cost on the paid row before launch, because free quota can hide both the eventual bill and a capacity limit. Also read the data-use terms printed beside the tier if the workflow handles sensitive company material.

The Gemini consumer page and plan comparison cover Google AI subscriptions for people. Those subscriptions do not fund a Gemini API project. The Google hub connects both products, but their prices and limits belong in different spreadsheets.

Quotas and tool charges sit beside token cost

A rate limit caps activity over time, commonly requests per minute, tokens per minute or requests per day. Google’s rate-limit guide says quotas apply at the project level and vary by model and usage tier. Reaching one can stop or delay requests even when a prepaid balance remains. A financial budget and a throughput quota therefore need separate monitoring.

Some Gemini tools carry separate charges or cause additional billable processing. Grounding is the process of supporting a model response with retrieved information, such as web search results. Google’s price page lists terms for grounding and other tools rather than hiding them in the text token rate. Put each used tool on its own budget line. If the application stores cached context, add the storage duration and rate too.

Retries also count. Software should distinguish a temporary capacity response from a permanent bad request, wait according to official guidance, and avoid an immediate retry loop. A load test should measure both successful calls and attempts so the estimate reflects the traffic the API actually receives.

What it means for you

Begin with a fixed test set, a group of real examples scored by the team. Try the least expensive Gemini model that could reasonably meet the requirement. Log quality, latency and every usage field. Move to a dearer model only if the improvement is valuable in the actual workflow.

Build the budget in visible rows: fresh input, cached input, cache storage, output, tools and retries. Run it at normal and busy-month traffic, then verify project quotas can support the busy case. Check Google’s primary pricing and billing pages on the approval date, because the ledger is dated and the vendor can change a row later.

That process does more than find a dollar amount. It gives the team an estimate another person can reproduce, a clear reason for the chosen model, and an early warning when the product changes enough to require a new calculation.