Google Gemini, choosing a model, the API, and real costs

Google Gemini, choosing a model, the API, and real costs

Gemini is Google's model family with two traits that set it apart: a context window reaching two million tokens and native handling of images, audio, and video in the same call as text. You reach it through the free AI Studio for experiments, through the Gemini API in code, and through Vertex AI when you need an enterprise layer.

Where you actually run Gemini

Four routes lead to the same model, and they are easy to confuse when hunting for documentation.

The Gemini app is an end user interface, irrelevant to a developer beyond a quick sanity check. Google AI Studio provides a browser playground with prompt inspection and code generation, and it is the right place to start. The Gemini API means ordinary HTTP calls with a key, which suffices for most applications. Vertex AI adds service account authentication, control over the data processing region, organisational quotas, and integration with the rest of Google Cloud.

Choosing between the last two comes down to requirements. If your company mandates processing inside Europe and billing through an existing cloud account, you go to Vertex. If you are building a product and want a key in an environment variable, the Gemini API is enough.

Models and which to pick

The selection rule is simple and rarely fails. Start with Flash. If quality holds, stay there, since the price gap against Pro runs several times over. If the task needs multi step reasoning or analysis of a several hundred page document, move to Pro. For repetitive work where throughput matters more than finesse, drop to Flash-Lite.

Since April 2026, Pro family models are available on paid plans only. Flash and Flash-Lite kept a free tier with reduced daily quotas, which still covers a prototype.

How to actually cut the bill

Two mechanisms change cost more than model choice does.

Context caching lowers the price of repeated input to roughly 0.20 USD per million tokens, about ninety percent off. That matters wherever the same large block returns on every request: a system instruction, product documentation, terms of service. Without caching you pay for those same tokens on every call.

The bill has a second line here, though, easy to forget beside the discount itself. Keeping the cache alive is charged separately, by time and size, on the order of several dollars per million tokens per hour on the Pro models. A cache therefore pays off under traffic that is dense in time rather than a few queries a day, since storage then exceeds the saving on input. Price both parts together before switching it on.

Batch processing gives fifty percent off for work that need not return immediately. Overnight classification of ten thousand tickets or generating product descriptions fits that mode perfectly.

It also pays to check how much of your input needs to reach the model at all. In many applications the prompt swells with conversation history appended in full on every turn, when the last few messages plus a summary of the rest would do. That change alone can halve the bill before you touch caching or batch mode.

The third factor is response length. Output costs several times more than input, so an instruction constraining the answer format trims the bill more effectively than shortening the prompt. Asking for five bullet points instead of an essay is often a multiple, not a margin.

Your first call

pip install google-genai
export GOOGLE_API_KEY=...

from google import genai

client = genai.Client()

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="Summarise the contract below in five points: " + contract_text
)

print(response.text)

TypeScript follows the same shape and drops into a Next.js API route without ceremony.

import { GoogleGenAI } from '@google/genai'

const ai = new GoogleGenAI({})

export async function POST(req: Request) {
  const { question } = await req.json()
  const result = await ai.models.generateContent({
    model: 'gemini-3.5-flash',
    contents: question
  })
  return Response.json({ answer: result.text })
}

Keep the key server side. A call from a client component exposes it to anyone opening developer tools, and the bill lands on you.

What long context genuinely buys

Two million tokens is roughly fifteen hundred pages of text. The temptation is to drop entire documentation into the prompt instead of building retrieval, and sometimes that is the right call.

It pays off for one off analysis: reading a three hundred page contract, comparing two specification revisions, going through a log dump from an outage. You do it once, the cost is one off, and quality beats chunk retrieval because the model sees the whole.

It does not pay off in an application answering user questions. A hundred thousand context tokens per question, across a thousand questions a day, produces a bill against which a vector database like Pinecone or pgvector comes out many times cheaper. Latency adds to that, since the model has to process the entire input before it starts answering.

It is also worth knowing that retrieval accuracy inside very long context degrades for information sitting in the middle. When you do submit a large document, put the question at the end and the most important passages at the start or the end, not halfway through.

Multimodality in practice

Gemini accepts images, audio, video, and PDFs in the same call as text, with no separate endpoints and no prior conversion.

file = client.files.upload(file="meeting-recording.mp4")

response = client.models.generate_content(
    model="gemini-3.1-pro",
    contents=[file, "List the decisions made in this meeting with timestamps."]
)

This is where Gemini stands apart most, in scenarios that elsewhere require a pipeline of several services. Analysing a recorded call, reading a scanned invoice, describing an error screenshot, transcribing with a summary, all of it goes through one call.

With scanned documents, check reading quality on your own files before building a process around it. Invoices with a stamp across them or tables with merged cells get misread often enough, and one wrong digit in an amount costs more than the whole model does.

The limitation concerns cost and time. A minute of video is far more tokens than a minute of reading, so price longer recordings before making a process permanent. For hour long material it is often cheaper to transcribe with a smaller model and work on the text.

Responses in a fixed structure

Integration with code needs a predictable response shape, not prose. Gemini accepts a schema and returns an object conforming to it.

from pydantic import BaseModel

class Ticket(BaseModel):
    category: str
    priority: int
    needs_human: bool

result = client.models.generate_content(
    model="gemini-3.1-flash-lite",
    contents=f"Classify this ticket: {content}",
    config={"response_mime_type": "application/json", "response_schema": Ticket}
)

That single change removes a whole class of bugs: no parsing responses with regular expressions, no handling the case where the model wrote a sentence before the JSON. For classification work, a schema plus Flash-Lite handles high volume at low cost.

Function calling works similarly: you describe the tools, the model states which to call and with what arguments, and you execute them on your side. For more elaborate flows it is worth wiring this through LangChain, which normalises the interface across providers.

Streaming and real time work

A model response can take a dozen seconds to form, so waiting for the whole thing ruins the sense of a working interface. Streaming hands over text in pieces as it is generated and changes how the application feels more than speeding up the model would.

for chunk in client.models.generate_content_stream(
    model="gemini-3.5-flash",
    contents=question
):
    print(chunk.text, end="", flush=True)

On the browser side you pass data through a response stream rather than a single JSON payload at the end. When deploying to Vercel, mind the function timeout: streaming keeps the connection open, so long answers hit that limit sooner than expected.

A separate mode covers real time audio, where the model takes a microphone stream and answers by voice with latency in the hundreds of milliseconds. That is a different kind of integration from an ordinary call, since it requires a bidirectional connection rather than a single HTTP request. Before building a product on it, price a minute of conversation and compare against a text model plus separate speech synthesis, because the gap can be large in either direction.

With streaming, also handle cancellation. A user closing the tab mid generation does not stop billing on the provider side unless your code aborts the request explicitly.

Gemini against GPT and Claude

Practical advice: do not bind your code to one provider at the level of business logic. A thin layer with one call interface lets you compare models on your own data, which is the only meaningful test. Public benchmarks measure tasks that rarely resemble yours.

How to compare models on your own data

Picking a model from public leaderboards leads to surprises, because they measure tasks that rarely resemble yours. A proper comparison takes half a day and pays for itself on the first invoice.

Start with thirty real cases from production or from logs. For each, record the input and what you consider a good answer. It need not be text word for word, a list of conditions the answer must satisfy is enough.

Then run the same set through two or three models and compare three things: the share of answers meeting the conditions, median response time, and the cost of one full pass. That last number multiplied by expected volume forecasts the monthly bill better than any calculator.

The result tends to surprise in a specific way. A cheaper model often loses not on content quality but on holding the format, and that is fixed with an instruction or a response schema rather than by changing models. Before moving to a pricier tier, check whether the prompt is the actual problem.

Keep the test set in your repository and run it after every model or instruction change. Providers retire older variants and swap versions, so an answer that worked in March may look different in July, and without a comparison set nobody notices until the first complaint.

Common mistakes

The first is using Pro where Flash suffices. The bill difference runs several times over, while the quality difference on simple tasks goes unnoticed.

The second is skipping context caching for a repeated system instruction. You then pay full rate for the same tokens on every request, when a tenth would do.

The third is ignoring per minute rate limits. The free tier carries low daily and per minute quotas, so code without retry and backoff falls over on the first traffic spike.

The fourth is hardcoding a model name in a dozen places. Names change quickly and older variants get retired, so keep the identifier in configuration.

The fifth is leaving content safety settings untouched in user facing applications. Default thresholds can be too restrictive for medical or legal content, and the model refuses where a refusal is not warranted.

FAQ

Does Gemini have a free plan for developers?

Flash and Flash-Lite kept a free tier with limited daily quotas, enough for a prototype and for learning. Since April 2026 the Pro models are paid only. Google AI Studio remains free for testing prompts in the browser.

Which model should I start with?

Flash. It covers most production tasks at a reasonable price, and moving to Pro for a harder task is a one string change. The reverse order, starting from the most expensive model, usually means overpaying for several months.

How does the Gemini API differ from Vertex AI?

In the access model and the layer around it. The Gemini API is a key in an environment variable and the fastest start. Vertex AI adds service account authentication, a choice of processing region, organisational quotas, and shared billing with the rest of Google Cloud. The models are the same.

Should I put whole documentation into context instead of building RAG?

For one off analysis yes, for an application answering repeated questions no. A hundred thousand context tokens per request multiply by user count, while chunk retrieval costs a fraction of that and answers faster.

Does Gemini handle languages other than English well?

Yes, quality holds for both generation and document analysis across major languages. Keep in mind that text in a highly inflected language consumes more tokens than English of the same content, so an identical task costs somewhat more.

Current pricing and quotas are described in the Gemini API documentation, and models for testing sit in Google AI Studio.