How to Prompt Google's Gemini Models

A practical, accurate guide to prompting Gemini 3 and 2.5: system instructions, long context, multimodal input, JSON mode, and thinking levels.

Reviewed

Gemini isn't just another chat model with a different name on the box. Google built its API around a few genuine differentiators — million-token context windows, native multimodal input, and (as of the Gemini 3 series) explicit control over how hard the model thinks — and prompting it well means using those features on purpose instead of writing generic prompts and hoping.

This guide targets the current lineup as of August 2026: Gemini 3.1 Pro (preview), Gemini 3.6 Flash, Gemini 3.5 Flash and Flash-Lite, Gemini 3.1 Flash-Lite, and the still-widely-deployed Gemini 2.5 Pro / Flash / Flash-Lite family. Field names below come from Google's Gemini API docs. Where behavior differs between the classic generateContent API and the newer Interactions API, both are called out.

Choosing a tier: Pro, Flash, or Flash-Lite

Gemini ships in three practical weight classes, plus one you can't prompt directly:

  • Gemini 3.1 Pro — the strongest reasoning model in the lineup. Use it for multi-step analysis, hard code generation, agentic planning, and anything where you'd rather pay latency than get a wrong answer.
  • Gemini 3.6 Flash / Gemini 3.5 Flash — the default for most production workloads. 3.5 Flash is tuned for agentic and coding tasks at a fraction of Pro's cost; 3.6 Flash is the newer, more token-efficient successor.
  • Gemini 3.5 Flash-Lite / Gemini 3.1 Flash-Lite — lowest latency, lowest cost, minimal default reasoning. Good for classification and extraction, where a tight schema does more work than model horsepower.
  • Gemini Nano — an on-device model built into Chrome and Android (via AICore), not callable through the cloud API. Don't confuse it with Nano Banana, Google's separate image-generation model family.

If you're comparing this against other vendors' tiering, the hub article on how to prompt the top AI models covers the same Pro/Flash-style tradeoff across providers.

System instructions and how Gemini weights them

Gemini accepts a dedicated system_instruction field (camelCase systemInstruction in raw REST) that's separate from the conversation turns. Google's guidance is explicit: this is a preamble applied before the model sees any user input, and it's supported across effectively every current Gemini model except the Imagen image generators. In practice, Gemini treats it as a higher-priority instruction layer than in-conversation text — persona, output format, and hard constraints belong here, not buried in the first user turn.

Two things trip people up:

  1. It's separate from your data. Put role, tone, and non-negotiable rules in system_instruction; put the document, transcript, or task-specific content in the user turn. Mixing them makes it harder for the model to tell who I am from what I'm working on.
  2. There are now two APIs. The established generateContent endpoint (stable, recommended for production) and the newer Interactions API (public beta from December 2025, reaching general availability around June 2026, recommended for access to the latest features) both accept a system instruction, but the surrounding request shape differs — Interactions uses a unified input array and adds fields like response_format and thinking_level that don't exist on generateContent. Pick one API and be consistent; don't mix field names from both.

Writing for a million-token context window

Long context is Gemini's signature feature, and Google's own long-context guidance is worth internalizing: put your actual question or instruction at the end of the prompt, after all the reference material, not before it. For a 50-page contract or a whole codebase pasted into context, that means: dump the material first, then ask the question last.

Two more things matter at scale:

  • Structure helps retrieval. Use clear section headers, file paths, or numbered chunks in your long context so you can refer back to them explicitly (see Section 4 or in `auth/session.rb`) instead of relying on the model to re-locate content by content alone.
  • Multi-target recall degrades. Google's docs note that single-fact (needle) retrieval is highly accurate, but accuracy drops as the number of distinct facts you need pulled from the same context grows. If you need many discrete answers out of one long document, consider splitting the task into several calls, or use context caching for the shared material so you're not re-paying for the same tokens on every request.

This context-engineering discipline is the same one covered more generally in the complete guide to prompt engineering — Gemini just gives you a much bigger canvas to apply it on.

Multimodal prompting: images, video, audio, PDF

This is where Gemini genuinely diverges from most competitors. Requests can mix text with images, video, audio, and PDFs as first-class input types, either inline (base64, capped around 20MB per request) or via the Files API for larger or reused assets. For a single image plus text, Google's vision documentation recommends putting your text instruction before the image; for multiple images, label or interleave each one with its own text so the model knows which instruction applies to which asset.

Image and video tokenization is resolution-dependent — media_resolution controls how many tokens the model spends per image or video frame, a real cost lever on video-heavy workloads, not just a quality knob. Supported image formats include PNG, JPEG, WEBP, HEIC, and HEIF.

Be specific about what you want pulled from the media (list every defect visible in this product photo beats describe this image); treat PDFs as documents Gemini reads natively rather than images you pre-OCR; and for video, trim to the relevant clip instead of sending a full recording, since cost scales with media_resolution × frame count.

Structured output and function calling

Gemini has two ways to force machine-parseable output. On generateContent, set generationConfig.responseMimeType to application/json and supply generationConfig.responseSchema with a JSON Schema (or an OpenAPI-style subset of one) describing the exact shape you want back. On the newer Interactions API, the equivalent is a response_format object with mime_type and schema fields. Both approaches constrain generation directly — the model can't emit prose around the JSON — which is far more reliable than asking nicely and parsing with a regex.

// generateContent request body (classic, stable API)
{
  "model": "gemini-3.5-flash",
  "systemInstruction": {
    "parts": [{ "text": "You are a support-ticket triage assistant. Be terse. Never invent fields." }]
  },
  "contents": [
    { "role": "user", "parts": [{ "text": "Ticket: 'App crashes on login since the 2.3 update, iPhone 15.'" }] }
  ],
  "generationConfig": {
    "responseMimeType": "application/json",
    "responseSchema": {
      "type": "object",
      "properties": {
        "severity": { "type": "string", "enum": ["low", "medium", "high", "critical"] },
        "category": { "type": "string" },
        "summary": { "type": "string" }
      },
      "required": ["severity", "category", "summary"]
    }
  }
}

Function calling works the same way: declare tools with a name, description, and parameter schema, and let the model decide when to call them. Both APIs expose a tool-choice mode roughly matching auto (model decides), forced (must call something), and none (disabled) — generateContent nests this under toolConfig.functionCallingConfig.mode, Interactions exposes a top-level tool_choice. For deeper patterns on getting consistently valid structured output from any model, see getting reliable structured output from LLMs, every time.

Thinking mode and how prompting changes

Gemini 3 models replaced the old token-budget approach to reasoning (thinkingBudget, still used on Gemini 2.5) with a thinking_level control: minimal, low, medium, or high, capping how much internal reasoning the model does before answering. Defaults vary by model — Flash-Lite tiers default to minimal, Gemini 3.1 Pro defaults to high.

Google's own Gemini 3 guidance marks a real change from older prompting habits: stop hand-holding. Elaborate think step by step, first do X, then do Y scaffolding that helped earlier models now tends to make Gemini 3 more verbose and less accurate, because it already reasons internally at whatever thinking_level you set. Give it a concise, direct instruction and let thinking_level do the work; reserve high for genuinely hard reasoning, math, or coding, and drop to low/minimal for lookups and simple transforms. Request thinking_summaries: "auto" if you want visibility into the reasoning trace for debugging.

Parameters and common mistakes

temperature, top_p, and top_k were marked deprecated on current Gemini 3.x models in Google's July 2026 changelog. Don't rely on them: leave temperature at its default of 1.0 — Gemini 3's own docs warn that lowering it can cause looping or degraded output quality rather than the more focused behavior it produced on older models — and reach for thinking_level, a tighter responseSchema, or a stricter system instruction when you want more consistent output.

Other Gemini-specific mistakes worth avoiding: treating system instructions as optional (persona and hard rules left in the user turn get diluted by everything else in a long prompt); front-loading the question in long-context prompts instead of putting it last; porting Gemini 2.5-style chain-of-thought scaffolding onto Gemini 3, which measurably hurts its output; and mixing generateContent and Interactions field names in the same request.

If you work across model families, the parallel guides for Claude and OpenAI's GPT models cover the equivalent decisions for those vendors, and the top AI models hub is the place to start if you're deciding which model to prompt in the first place. For the underlying principles that apply regardless of vendor, the complete guide to prompt engineering is the pillar to read next.

← Back to Articles How we research & review →