Making Gemini API Output Reproducible with the seed Parameter — Practical Patterns for Tests and Debugging

Minimal Python example

Here is a minimal, working example with the google-genai Python SDK, shaped so it drops straight into a pytest snapshot test.

# pip install google-genai
import os
from google import genai
from google.genai import types
 
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
 
def generate_with_seed(prompt: str, seed: int = 42) -> str:
    """Get a highly reproducible response for the same seed and prompt."""
    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=prompt,
        config=types.GenerateContentConfig(
            temperature=0.0,
            top_p=1.0,
            seed=seed,
            max_output_tokens=512,
        ),
    )
    return response.text
 
if __name__ == "__main__":
    out_a = generate_with_seed("Answer with the capital of Japan in one word.")
    out_b = generate_with_seed("Answer with the capital of Japan in one word.")
    print(out_a)
    print(out_b)
    print("match:", out_a == out_b)

This calls the model twice with seed=42, temperature=0.0 and compares the results. Both should print Tokyo and match: True. Adding even a single trailing space to the prompt can change the response, so manage your input strings strictly in tests.

REST and Node.js variants

From REST, put seed inside generationConfig.

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent?key=YOUR_GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{"parts":[{"text":"What is 2+2? Answer with just the number."}]}],
    "generationConfig": {
      "temperature": 0.0,
      "topP": 1.0,
      "seed": 42,
      "maxOutputTokens": 32
    }
  }'

With Node.js (@google/genai), you just pass seed in the config object.

import { GoogleGenAI } from "@google/genai";
 
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY! });
 
const result = await ai.models.generateContent({
  model: "gemini-2.5-flash",
  contents: "Translate 'Good morning' to French.",
  config: { temperature: 0, topP: 1, seed: 42, maxOutputTokens: 64 },
});
console.log(result.text);

REST and Node.js behave the same internally — same parameters, same result.

Three patterns I use for tests and debugging

These are the three I reach for day to day.

1. Snapshot-freeze for regression tests

So that a diff only appears when you intend one, generate the response with fixed seed + temperature=0 and save it to a snapshot file. If CI can catch the diff, you avoid the "output quietly changed and nobody noticed" class of incident. The full implementation is in Building Prompt Regression Tests for the Gemini API with Pytest.

2. Variance reduction for prompt A/B comparison

When comparing "is prompt A or B better," running each once with the same seed is less reliable than preparing 3–5 seeds and doing a paired comparison per seed. Even when you deliberately raise temperature to measure diversity, fixing the list of seeds keeps the experiment reproducible.

3. Bug reports and reproduction environments

When a user reports "it returned something weird," logging the seed alongside the prompt dramatically raises your odds of reproducing it locally. Always keep prompt, model, temperature, and seed in your app logs.

The thing silently dropping your seed is usually your own wrapper

When "I passed a seed but it doesn't match," the first suspect is not the model — it's the layer sitting between your code and the API. The mistake I actually made was rebuilding GenerateContentConfig in a shared wrapper and forwarding only temperature and max_output_tokens, quietly dropping seed.

# Before: seed is never forwarded, so tests look "non-deterministic"
def call_model(prompt: str, cfg: dict) -> str:
    response = client.models.generate_content(
        model=cfg["model"],
        contents=prompt,
        config=types.GenerateContentConfig(
            temperature=cfg.get("temperature", 0.0),
            max_output_tokens=cfg.get("max_output_tokens", 512),
            # forgot to forward seed here
        ),
    )
    return response.text

# After: build the config so no known field can be dropped
KNOWN_KEYS = {"temperature", "top_p", "seed", "max_output_tokens"}
 
def call_model(prompt: str, cfg: dict) -> str:
    passthrough = {k: cfg[k] for k in KNOWN_KEYS if k in cfg}
    response = client.models.generate_content(
        model=cfg["model"],
        contents=prompt,
        config=types.GenerateContentConfig(**passthrough),
    )
    return response.text

The point is to pass known keys through as a dict comprehension rather than copying each setting by hand. That way, adding a new parameter later can't reintroduce a "forgot to forward it" bug. If an enterprise gateway is stripping unknown fields, this shape also makes it easier to tell whether the field is being stripped or was never sent in the first place.

A top-down flow to eliminate the source of variance

When seed isn't working, don't poke at it randomly. Walking down this order gets you to the cause fastest.

1. Send the same minimal prompt three times in a row (seed=42, temperature=0). If all three match exactly, the raw API call is at least healthy
2. If they don't match, call the SDK directly, bypassing your wrapper. If it matches now, the wrapper is the culprit (see the Before/After above)
3. Still wobbling? Check temperature. Make sure a stray 0.7 hasn't slipped in via an env var or default
4. Check the model name isn't an alias (-latest). Pin tests to an explicit version
5. Check the input isn't multimodal, streaming, or tool-using. Those are outside seed's jurisdiction, so split the test unit

Walking these five steps top to bottom prevents the "it's the model's fault" time sink almost entirely. After I wrote this order on a sticky note, my time spent investigating seed-related issues dropped by roughly half.

When seed does not help

Let me expand on the "outside seed's jurisdiction" that showed up in steps 4–5. If you're passing a seed and the result still varies, check whether you've hit one of these.

• Temperature is high: at 0.7–1.0, the sampling space is wide enough that seed alone leaves room for noise — as measured above, the match rate can fall to 41%. For maximum reproducibility, keep it in the 0–0.2 range
• The model name is an alias: aliases like gemini-2.5-flash-latest can be swapped for a different version underneath. In tests, use gemini-2.5-flash (or an explicit version) to be safe
• Multimodal input (images, PDFs): the image preprocessing path has its own variance and is less stable than text alone. In snapshot tests, stick to text input
• Streaming responses: chunk boundaries can shift. Compare on the final, fully assembled text
• Tool use or grounding: the external call results themselves change over time, so seed alone can't reproduce them. Mock the tools in tests

In short, seed suppresses "sampling variance" but not "external variance." The trick is to split the test unit and stay conscious of where the wobble is coming from.

Diagnosing why it wobbles with logprobs

When you want to take the diagnosis a step deeper, pull logprobs and look at how much the model hesitated at each token. The closer the top candidates' probabilities are, the more easily that token flips to another word when conditions change slightly — an obvious relationship, but a useful one to see.

from google import genai
from google.genai import types
 
client = genai.Client()
 
resp = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="Answer the sentiment in one word, positive / negative: shipping was slow but the quality was great",
    config=types.GenerateContentConfig(
        temperature=0.0,
        seed=42,
        response_logprobs=True,
        logprobs=5,  # top 5 candidates per position
    ),
)
 
# Inspect how close the candidates are at the first token
for cand in resp.candidates:
    for step in cand.logprobs_result.top_candidates[:1]:
        for c in step.candidates:
            print(f"{c.token!r}: logprob={c.log_probability:.3f}")

If positive and negative have near-identical logprobs at the first token, that prompt is inherently prone to splitting. Rather than papering over it with a seed, rewriting the prompt to widen the confidence gap helps both test stability and production quality. The full walkthrough is in Measuring Classification Confidence with Gemini API logprobs.

A short story: why seed matters more in evaluation than production

At first I thought of seed as a "test-time only" tool. What changed my mind was running prompt evaluations in parallel. Without a seed, the score for the same prompt drifted slightly run to run, and the effect of a small prompt improvement drowned in that noise.

The moment I fixed the seed and the model version, the score started reflecting "the intrinsic quality of the prompt" rather than "sampling luck." If you're doing serious prompt improvement, fix the seed in your evaluation jobs before you even think about production. And if you're using an LLM-as-judge, fix the judge's model and seed too — otherwise you're measuring two layers of wobble at once.

Designing seed alongside temperature and top_p

These are the three settings I've settled into.

• Full reproducibility (for tests): temperature=0, top_p=1.0, seed=fixed. Aims for near-exact snapshot matches
• Allowing slight variation (production): temperature=0.2, top_p=0.95, seed=unset. Feels more natural for user-facing responses
• When you need creativity (copywriting, etc.): temperature=0.9, top_p=0.95, seed=rotating. Cycle through several seeds and compare candidates

Tune response quality on the temperature side and reproducibility on the seed side — separating the roles keeps your settings from sprawling. For choosing temperature itself, I've collected use-case-by-use-case guidance in Task-by-Task Temperature Best Practices for the Gemini API.

Quick sanity check: confirming seed actually works in your stack

Before relying on seed across your test suite, run a one-line confirmation in the same environment your tests use. Network proxies, alternate endpoints, or a mismatched SDK version can all produce subtle differences. The fastest check is to send the same minimal prompt three times back-to-back with seed=42, temperature=0 and assert all three are byte-identical. If they are, your stack honors seed correctly. If not, something between your code and the model is dropping it — usually a wrapper that forgets to forward the parameter, or a gateway that strips fields it doesn't recognize. The Before/After and triage flow above are your prescription.

What to try next

Open one of your current Gemini API call sites, add seed=42 and temperature=0, and run the same prompt twice. In most cases the two outputs will match exactly. If they don't, walk down the triage flow — it's almost always one of those issues.

Once you have that working, add a single snapshot test to CI for one important prompt. The moment your pipeline can detect quiet output drift, your ability to iterate on prompts steps up noticeably. Reproducibility is an unglamorous foundation, but whether or not you have it changes how fast everything downstream moves. I hope this helps in your own work, and thank you for reading.