Gemini API Request Storage Is On by Default: How to Set store=false per Request and per Project

Gemini API request storage is now on by default for new paid projects. Any paid project created on or after October 26, 2026 logs Generate Content prompts and responses unless someone changed its storage setting. Requests keep succeeding either way, so the change can sit unnoticed. Whether that matters depends on what your prompts contain, and the answer should be a decision made for each project. The AUCV storage review (Audit, Upgrade, Configure, Verify) below turns that choice into a repeatable check.

Background: What Changed for New Paid Gemini Projects

Since October 26, 2026, new paid Gemini API projects store Generate Content prompts and responses by default. Projects created before that date keep storage off. Two projects in the same organization, running identical code, can behave differently purely because of when they were created.

Nothing in your code or your error logs shows that logging is on, which is why this goes unnoticed. If those prompts carry customer data, your data protection owner will want to hear about it, ideally from you, along with an honest account of what is still unknown. The release note does not explain why Google changed the default, does not define the exact cutoff for new projects, and does not say whether the change will later extend to existing projects. Plan for today's split and assume it could shift.

Nobody has leaked anything here; a default changed. Logging is a documented feature with real uses for debugging and evaluation, so the work is about knowing which projects have it on and why.

What Google Keeps, and for How Long

The default retention period for logs is 55 days, after which logs expire and are marked for deletion. Project owners can shorten that window to 7, 14 or 28 days.

Datasets need separate attention, because they follow different rules. Logs saved to a dataset have no retention period and stay until someone deletes them. Datasets can be exported as CSV, JSONL or to Google Sheets, which makes them useful for evaluation work. Those exports mean copies can drift outside the project if nobody tracks them.

By default, prompts and responses in billing-enabled project logs are not used to improve or develop Google's products. The Contributor Tier, covered in the caveats below, is the exception to watch.

Some models and inputs are not supported for logging at all. BaristaLabs' summary of Google's guide lists Imagen and Veo models, Gemini embedding models, the Gemini Robotics model, inputs containing videos, GIFs or PDFs, and public preview agents.

Grounding is a separate retention path entirely. Data from grounding with Google Search and grounding with Google Maps is retained for 30 days, and that retention cannot be disabled.

Phase 1 (Audit): Inventory Projects, SDKs and Data Owners

Start with a list of every paid Gemini API project your organization owns, with its creation date. Treat anything created on or after October 26, 2026 as storing requests until you have confirmed otherwise.

Against each service on that list, record the SDK language and the version installed in the running environment, since a README or an old requirements file can lag behind what is actually deployed. You can only set store on a request if the SDK supports it, and the minimum versions differ by language.

Services that also reach Vertex AI deserve a separate line in the inventory. Both the Python and JavaScript release notes label the store option "Gemini Developer API only". If some services call Vertex AI through the same SDK, don't assume this guide covers them. Review Google Cloud's Vertex AI data governance documentation for those services and record that decision next to your Gemini Developer API projects.

Once you know which projects and SDKs are live, the remaining audit question is a policy one: which workloads may keep logging? Settle it with your data owner and write the answer down project by project. Internal debugging and evaluation work are reasonable candidates. Requests carrying customer personal data usually are not. As an illustration, picture a team with two Gemini projects: a support assistant that summarizes tickets containing customer names and account details, and an internal evaluation script that replays synthetic prompts to compare model versions. The support project gets project logging off and store=false in code. The evaluation project can keep logging with a short retention window, because stored requests there help the team debug regressions and build datasets, and none of the content would raise a privacy question.

Phase 2 (Upgrade): Move Every Service to an SDK That Supports store

Per-request store needs at least the following SDK versions:

The Python 2.33.0 release and the JavaScript 2.31.0 release both shipped on October 22, 2026, and both add store to GenerateContentConfig. For Java and Go, the listed minimums are google-genai 1.79.0 and google.golang.org/genai 1.76.0.

Upgrade each service and pin the version in your lockfile. If the version floats, a rollback or a fresh environment could quietly drop support for the field.

Phase 3 (Configure): Set Project-Level Logging in AI Studio First

The project setting catches the requests someone forgets to flag, so set it before touching code.

For projects that should never store requests, turn project-level logging off in AI Studio, following the steps in the Logs and datasets documentation. Where logging stays on for debugging or evals, shorten retention from the 55-day default to 7, 14 or 28 days, whichever fits your data policy. Existing datasets need their own pass, because changing log retention won't clean them up: delete the ones nobody needs, and record any CSV, JSONL or Google Sheets exports so they fall under your normal data handling.

Which setting wins when the request and the project disagree? We suggest confirming the precedence rule in the current logs documentation before relying on either setting alone. Setting both takes most of the urgency out of the question. If the project is off and the request says store=false, a future default change or one missed setting won't quietly switch storage back on.

Phase 3, continued: Opt Out per Request with store=false

Step 1: Set store to false in GenerateContentConfig

The setting is a field called store on GenerateContentConfig. The Python and JavaScript snippets follow the shape described in the release notes. Treat the Java and Go snippets as unverified: we have not confirmed the Java builder method or its parameter type, or whether the Go Store field is a bool or a *bool, against v1.79.0 and v1.76.0. Check the release notes and the Go package docs before you ship them.

Python:

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="YOUR_MODEL_ID",
    contents="Summarize this support ticket...",
    config=types.GenerateContentConfig(store=False),
)

JavaScript:

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({});

const response = await ai.models.generateContent({
  model: "YOUR_MODEL_ID",
  contents: "Summarize this support ticket...",
  config: { store: false },
});

Java:

// Unverified shape: confirm the builder method and parameter type in 1.79.0.
GenerateContentConfig config = GenerateContentConfig.builder()
    .store(false)
    .build();

GenerateContentResponse response = client.models.generateContent(
    "YOUR_MODEL_ID", "Summarize this support ticket...", config);

Go:

// Unverified shape: confirm whether Store is bool or *bool in v1.76.0.
config := &genai.GenerateContentConfig{
    Store: genai.Ptr(false),
}

resp, err := client.Models.GenerateContent(ctx, "YOUR_MODEL_ID",
    genai.Text("Summarize this support ticket..."), config)

Step 2: Centralize the setting in one client wrapper

Opt-outs usually fail at the one call site nobody routed through the wrapper. Route every Gemini call through one internal helper that applies store=false by default and only allows logging when a caller explicitly asks and project policy permits it. The policy then lives in one reviewed file instead of dozens. If you already centralize provider calls behind a gateway, that routing layer is a sensible home for the rule. Just confirm each provider's flag actually gets passed through.

Step 3: Enforce it with a test or lint rule

A unit test on the config your wrapper produces, or a lint rule that flags direct generate calls without an explicit store value, catches the endpoint someone adds next quarter and forgets to route properly.

Streaming, batch and other providers

The new default is described for Generate Content requests. Before assuming streaming or batch paths behave the same way, check Google's Logs and datasets documentation and the Gemini API release notes.

Teams on more than one provider can share a single policy. OpenAI's Responses API also keeps application state for 30 days by default and accepts store: false.

Phase 4 (Verify): Prove the Opt-Out With a Marker Test

The code shows what you requested. The logs dashboard shows what was actually stored. Checking the second one takes a few minutes.

1. Generate a unique marker string, such as a random ID plus today's date.
2. From the project under test, send one request containing the marker with store=false.
3. From the same project, send a control request with a different marker and logging allowed, if your policy permits a harmless test prompt to be stored.
4. In the AI Studio logs dashboard for that project, filter or browse recent logs by timestamp and look for both markers.
5. Pass: only the control request appears. Fail: the store=false request appears, so recheck the SDK version, the wrapper or the project setting.
6. Delete the control log entry if your policy requires it.

If project-level logging is already off

In that case the control won't appear either, and seeing neither marker is the expected result. That shows nothing reached the logs. It does not prove store=false works on its own, because the project setting suppresses the request either way. To isolate the flag, repeat the test from a dedicated test project with logging on, using the same SDK version and wrapper and only harmless prompts.

Rerun the test after SDK upgrades, wrapper changes and every new project. Keep a dated record: project, SDK version, project log setting, request setting, outcome. When a compliance review asks what was tested and when, that record is your answer. Keep in mind the test covers the logging feature only; abuse monitoring and grounding retention sit outside it.

Common Mistakes When Turning Off Gemini Request Storage

Assuming an older SDK will honor store. Below the Phase 2 minimums, the field isn't available on GenerateContentConfig.

Fixing one project and missing the next. New paid projects start out logging, so put the project setting on your project creation checklist.

Treating opt-out as zero retention. According to a DEV Community write-up, Google's separate abuse monitoring still keeps prompts and outputs for 55 days, used only for policy enforcement. Turning off logging doesn't change that, and grounding retention sits outside these settings too.

Leaving old datasets in place. Datasets don't expire, and shortening log retention doesn't touch them.

Assuming the flag covers Vertex AI. The SDK release notes scope store to the Gemini Developer API. Use the Vertex AI step from Phase 1.

Checklist for Your AUCV Storage Review

• [ ] Audit: inventory paid Gemini API projects and flag those created on or after October 26, 2026
• [ ] Audit: record SDK language and installed version per service, and identify Vertex AI calls
• [ ] Audit: agree with the data owner which workloads may log
• [ ] Upgrade: move to Python 2.33.0, JavaScript 2.31.0, Java 1.79.0 or Go 1.76.0 or later, and pin versions
• [ ] Configure: turn off project-level logging where storage is not allowed, or shorten retention to 7, 14 or 28 days
• [ ] Configure: review stale datasets, record their exports and delete them
• [ ] Configure: set store=false in a central wrapper, enforced by a test or lint rule
• [ ] Configure: check streaming and batch coverage in Google's docs
• [ ] Verify: run the marker test and save a dated record
• [ ] Verify: document grounding and abuse-monitoring retention in privacy notes

Caveats and Open Questions

Google hasn't said whether existing projects will move to the new default. That alone is reason to set store=false in code on older projects too. Endpoint coverage and precedence rules live on Google's logs and changelog pages, which can change without notice, so recheck them whenever you upgrade SDKs.

The 55-day abuse-monitoring figure comes from a community post rather than Google's own documentation, so confirm it against Google's data use terms before it goes into a policy document.

Discounted pricing can pull in the opposite direction. Google describes an invite-only Contributor Tier in private preview, in which eligible developers receive up to 50% off token costs on selected models in exchange for allowing data from those models to be used under the Unpaid Services terms. That reverses the default protection for paid project logs, so bring in the privacy owner before signing up.

None of this makes logging a bad choice. Stored requests help with debugging production issues and building evaluation datasets. With provider logging off, your own traces become the debugging record. Our OpenTelemetry GenAI tracing playbook covers that setup, and the same data owner decision should govern any prompt content you capture there. The aim is a clear decision per project, since a blanket opt-out can leave engineers without the data they need.

If an outside reviewer would help, Optijara can run this storage review with your team across Gemini and the other AI providers you use.