Gemini API logging is now on by default: how to opt out

Gemini API logging changed on October 26, 2026. In any paid Gemini API project created on or after that date, every generateContent request is now stored in the project's logs by default: the full prompt, the response and any earlier turns, kept for up to 55 days. Projects created before that date keep their old setting, which for most of them is off. Nothing in your code changes, and no error tells you it happened.

For a team that sends user content to Gemini, that default matters. If your backend classifies app store reviews, summarizes support tickets or powers an AI feature in a browser extension, those inputs now sit in a log that anyone with access to the project can open. This guide explains exactly what changed, what a log contains, who can use it, and how to opt out per request or per project, based on Google's logs and datasets documentation, its data logging and sharing policy and the Gemini API changelog, all read on October 31, 2026.

Key takeaways

• Since October 26, 2026, the Generate Content API "stores requests by default for new projects." Older projects are unchanged.
• The Interactions API has always stored requests by default (store=true), because it uses them for server-side conversation state.
• Logs hold the full prompt and response and are kept for 55 days by default. Owners can shorten that to 7, 14 or 28 days. Logs saved into a dataset do not expire.
• Opt out per request with store: false (inside config in the JavaScript SDK, version 2.31.0 or later), or turn Generate Content logging off for the whole project in AI Studio.
• store: false does not switch off Google's separate abuse monitoring, which keeps prompts and outputs for 55 days.

What changed on October 26, 2026#

The changelog entry is short: new paid-tier projects that use the Generate Content API now store requests by default, which matches how the Interactions API already worked. Existing projects keep their current setting, and you can opt out per request or in the Logs and Datasets settings. The logs documentation was updated the same day: projects created before October 26 keep their existing setting, which is off unless someone enabled logging in AI Studio.

Here is the default for each case:

Three details are easy to miss:

• It only applies to paid projects. Google says "storage for Gemini API logs are only available for projects on the Gemini API paid tier." A free-tier project has no logs, but it is covered by different data terms, described below.
• Batch and streaming calls count. Logging covers GenerateContent, BatchGenerateContent and StreamGenerateContent, plus Interactions API calls (except Managed Agents). A nightly batch job that labels thousands of reviews is logged the same way as a single interactive call.
• The OpenAI compatibility endpoints are included. If you call Gemini through the OpenAI-style endpoint so you can reuse an OpenAI client, those calls are logged too.

Some inputs are never logged: Imagen and Veo models, Gemini embedding models, the Gemini Robotics model, inputs that contain videos, GIFs or PDFs, and public preview agents. An embeddings pipeline, such as the review search in our pgvector in Node.js guide, is not affected.

What a Gemini API log contains#

A log entry is not a usage counter. Google's docs say that opening an entry shows the payload, including the full prompt, the response and the context from earlier turns. For an Interactions API entry, the log also links to the previous_interaction_id, so a whole conversation can be followed.

Logs appear on the Logs page in Google AI Studio, newest first, for the project you select. Two practical rules from the docs:

• A project "requires at least one active API key for logs to be displayed." If you delete every key, you lose access to the logs until a key exists again.
• Projects created before October 26 have to turn on Generate Content logging in the settings panel before any entries appear.

From the logs you can build datasets: filter, tick the entries you want and choose Create dataset. Datasets can be exported as CSV, JSONL or to Google Sheets, and Google suggests using them as evaluation sets. That is the upside of the change. Real production prompts make better test cases than invented ones, which is why logging is useful when you turn it on deliberately.

Retention: how long Gemini API logs are kept#

The logging policy sets a "default maximum period of 55 days." After that, logs are "automatically marked for deletion." A project owner can choose a shorter window of 7, 14 or 28 days in AI Studio.

The exception is datasets. Logs that you save into a dataset have no set retention period, so a dataset built from production traffic keeps that user content until you delete the dataset.

Is logged data used for training?#

Not by default, on the paid tier. Because logging needs billing, the policy says prompts and responses in these logs are not used "for product improvement or development." Logs are private to your Google Cloud project.

That changes in two situations, and both are opt-in:

1. Sharing a dataset with Google. Shared datasets are processed under the Unpaid Services terms and "may be used to develop and improve Google products, services, and machine learning technologies." Human reviewers may read them after they are disconnected from your account, API key and project. Google's own warning: "Do not include personal, sensitive, or confidential information."
2. The Gemini API Contributor Tier. This invite-only preview offers "up to 50% off token costs for select models" in exchange for using that traffic under the same Unpaid Services terms.

Separately from your logs, Google keeps prompts, context and outputs for 55 days for abuse monitoring. The usage policies page says this data is used only for policy enforcement and is "not used to train or fine-tune any AI/ML models besides those used specifically for policy enforcement." Setting store: false does not change this.

The free tier works differently again. The Gemini API terms say Google uses content sent to the Unpaid Services "to provide, improve, and develop" its products, that human reviewers may read it, and: "Do not submit sensitive, confidential, or personal information to the Unpaid Services." If user reviews or user prompts flow through a free-tier key, that is a bigger question than logging.

Why app and extension developers should check this#

Developers who build on store data tend to send exactly the kind of text these warnings are about:

• Store reviews. Reviews often include names, email addresses, order numbers and complaints about specific people. A review-labeling job like the one in our app review analysis with an LLM guide now stores every review it sends, in a new project.
• AI features in extensions. An extension that sends page text or user prompts through your backend, the setup our guide to hiding an API key in a Chrome extension recommends, puts whatever the user was reading into the log.
• Support and feedback tools. Summaries of tickets and survey answers carry the same personal data as the originals.

None of this makes logging wrong. It does mean the decision should be yours, not a default. If your privacy policy or your store data disclosures describe how user content is processed and retained, check that they still match what your Gemini project does.

How to check whether your project stores requests#

1. Open Google AI Studio and go to Logs.
2. Select the project your production API key belongs to.
3. Open the Settings panel of the Logs dashboard. It has separate switches for generateContent and the Interactions API.
4. If your project was created on or after October 26, 2026, expect Generate Content logging to be on. If entries are already listed, it is.

Do this for every project that holds a production key. Teams often create a fresh project for a new feature or a new environment, and that new project is exactly where the new default applies.

Opt out per request with store: false#

The API reference says a request-level setting "takes precedence over the project-level logging config", so the most reliable fix is in code: set it on every call, and your behavior no longer depends on when a project was created or what someone toggled in AI Studio.

In the JavaScript SDK, store goes inside config. It needs @google/genai 2.31.0 or later (Python google-genai 2.33.0, Java 1.79.0, Go 1.76.0):

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

const ai = new GoogleGenAI({}); // reads GEMINI_API_KEY from the environment

const response = await ai.models.generateContent({
  model: 'gemini-3.8-flash',
  contents: 'Label this review: "The sync broke after the last update."',
  config: {
    store: false, // do not keep this request in the project's logs
  },
});

console.log(response.text);

Over REST, store is a top-level field of the request body, next to contents and generationConfig. The API reference describes it as configuring "the logging behavior for a given request":

curl -s "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{ "parts": [{ "text": "Label this review: \"The sync broke after the last update.\"" }] }],
    "store": false
  }'

Older SDK versions do not support the setting, so pin the minimum version in package.json and check the installed version in CI instead of assuming every service was upgraded.

Make it the default in your own code#

One call site with store: false is easy. Twenty call sites written by different people over a year is how the setting gets lost. Route every Gemini call through one helper that sets it unless the caller explicitly asks for logging:

// gemini.js: the only module that talks to the Gemini API.
import { GoogleGenAI } from '@google/genai';

const ai = new GoogleGenAI({});

/**
 * generateContent with logging off unless a caller opts in on purpose,
 * for example while collecting an evaluation set.
 */
export async function generate({ model, contents, config = {}, logRequest = false }) {
  return ai.models.generateContent({
    model,
    contents,
    config: { ...config, store: logRequest },
  });
}

Because store is written after the spread, a stray store: true in config cannot turn logging back on; only the named logRequest flag can. A one-line lint rule or a grep in CI that fails on any other import of @google/genai keeps the helper the only door.

Interactions API: think before you turn it off#

The Interactions API stores requests by default for a reason: it keeps conversation state on the server so you can continue with previous_interaction_id. Its store flag is a top-level argument rather than part of config, and Google notes that turning Interactions logging off at the project level also stops automatic storage and retrieval of conversation history, unless a request overrides it. If you turn it off, send the full history yourself on each turn.

Opt out for the whole project#

If you prefer a project-wide switch, turn off Generate Content logging in the Settings panel of the Logs dashboard. That is the only option for traffic you cannot easily change, such as calls through the OpenAI compatibility endpoint, where the logging docs do not show a per-request switch.

Use both layers where you can. The project setting protects you from a call site that forgot store: false; the request setting protects you from a project someone created next month with the new default.

If you want to keep logging on#

Logs are genuinely useful for debugging prompts and building evaluation sets. If you keep them:

• Shorten retention to 7 or 14 days unless you have a reason to keep 55.
• Redact before you send. Strip email addresses, phone numbers and order IDs from review text. The model rarely needs them to label a complaint.
• Treat datasets as long-lived copies. They do not expire, so build them from redacted traffic and delete them when the evaluation is done.
• Do not share datasets with Google if they contain user content, given the human review and training terms above.
• Limit who can open the project. A log viewer sees full prompts.

If you also track spend and latency per call, our guides to LLM observability with OpenTelemetry and LLM cost per user show how to record what you need (tokens, latency, model, user ID) in your own systems without keeping prompt text.

How this compares with OpenAI#

The defaults differ by provider, which matters if your backend switches between them. OpenAI's data controls page says abuse monitoring logs are kept "up to 30 days" by default, that API data is not used for training unless you opt in, and that the Responses API has "a 30 day Application State retention period by default, or when the store parameter is set to true." So both providers now keep a copy of requests for their stateful features by default, and both let you set store to false per request. If you abstract several providers behind one client, make "no storage" the default in that abstraction, the same way the helper above does for Gemini.

Gemini API logging checklist#

• List every Google Cloud project that holds a production Gemini API key, with its creation date.
• Open Logs in AI Studio for each one and check the Generate Content and Interactions switches.
• Upgrade to @google/genai 2.31.0 or later (or the matching Python, Java or Go version).
• Send store: false on every Generate Content call that carries user content, through one helper.
• Turn project-level Generate Content logging off unless you use it on purpose.
• If logging stays on, shorten retention and redact personal data before sending.
• Review datasets: delete ones built from unredacted user content, and do not share them.
• Confirm production traffic never uses a free-tier key.
• Check that your privacy policy and store data disclosures match what you now do.

Where Extenify fits#

Most of the user text that ends up in an LLM pipeline for app developers starts as store reviews. Extenify handles the collection side: it is an app review monitoring and Chrome extension analytics dashboard that records reviews, ratings, installs and versions every day for your apps and extensions, and your competitors', on the Chrome Web Store, Edge Add-ons, Firefox Add-ons, Google Play and the App Store. It sends app store rating alerts to email, Slack, Discord, Telegram or Teams when something changes, so you only send the reviews that matter to a model. Every plan starts with a free trial; see Extenify pricing.

For other recent API changes that can break or change a backend without a code change on your side, see our roundup of LLM model retirements in late 2026. And if your alerts go to Slack, our guide to the Slack webhook in Node.js covers the delivery side.

Frequently asked questions#

Does the Gemini API store my prompts?#

On the paid tier, it depends on the project. Interactions API calls are stored by default. Generate Content calls are stored by default in projects created on or after October 26, 2026, and not stored in older projects unless someone turned logging on. Separately, Google keeps prompts and outputs for 55 days for abuse monitoring in every case.

How do I turn off Gemini API logging?#

Set store: false on each request (inside config in the JavaScript SDK 2.31.0 or later, or as a top-level field over REST), and turn off Generate Content logging in the Settings panel of the Logs dashboard in AI Studio. The request setting wins if the two disagree.

How long does the Gemini API keep logs?#

Up to 55 days by default. A project owner can set 7, 14 or 28 days instead. Logs saved into a dataset have no set retention period and stay until you delete the dataset.

Is my Gemini API data used for training?#

Not on the paid tier by default. It can be if you share a dataset with Google or join the Contributor Tier, both of which put that data under the Unpaid Services terms. Content sent through the free tier can be used to improve Google's products and may be read by human reviewers.

Does store: false stop all data retention?#

No. It keeps the request out of your project's logs. Google's abuse monitoring still retains prompts, context and outputs for 55 days, solely for detecting policy violations.

Do I need to change anything if my project is older than October 26, 2026?#

Not because of this change: older projects keep their setting. It is still worth setting store: false in code, because the next project your team creates will get the new default.

Summary#

Gemini API logging is now on by default for the Generate Content API in paid projects created on or after October 26, 2026, matching the Interactions API. Logs hold full prompts and responses for up to 55 days, datasets built from them do not expire, and abuse monitoring keeps its own 55-day copy regardless. If you send store reviews or user prompts to Gemini, check each project's log settings, send store: false through a single helper, turn project-level logging off unless you use it deliberately, and keep logs short-lived and redacted when you do.

Image credits#

• Cover photo: Historic government book and records archive by Jennifer Bourn on the WordPress Photo Directory, CC0.