On October 26, Gemini changed a default rather than shipping a feature. New projects on the paid tier that call the Generate Content API now store requests by default, the same behavior the Interactions API already had. Nothing in your code has to change for this to apply, which is exactly why it is worth checking: the practical test is your project's creation date, then your data classification, then whether to opt out.
The short version: projects created on or after 2026-10-26 store by default; older projects keep their existing setting, which is off unless logging was previously enabled in AI Studio. If you need to opt out, you can do it per request or per project, and the per-request setting wins. Both routes have a cost that is easy to miss, and the cost is state.
Everything below follows the official release notes, the Logs and datasets guide, and the Interactions API documentation, checked on 2026-10-27. Confirm against those pages before changing a production setting.
What changed, in the official words
The release note is compact and worth quoting closely: new projects using the Generate Content API, meaning generateContent, streamGenerateContent, and batchGenerateContent, on the paid tier now store requests by default with store=true, matching the Interactions API. Existing projects keep their current setting.
Two details in that sentence matter more than they look. First, the change is scoped to new projects, so a workspace with several projects may contain both behaviors at once. Second, it covers three call shapes, including batch, so a team that only audits its interactive calls can still be storing batch traffic.
The opt-out paths are named in the same note: set store=false on individual requests, or turn off Generate Content API logging in the Settings panel of the Logs and Datasets dashboard.
How to tell whether you are affected
Start with the creation date. The Logs guide states the boundary explicitly: Generate Content requests are stored by default for projects created on or after 2026-10-26, while projects created before that date do not store requests by default unless logging is enabled in AI Studio.
Then check the endpoint you actually use. The coverage note is broader than the API name suggests: logging supports GenerateContent, BatchGenerateContent, and StreamGenerateContent calls, plus Interactions API calls excluding Managed Agents, and it explicitly includes calls made through OpenAI compatibility endpoints. A gateway or client that only swapped the base URL is still in scope, which is the part most likely to be missed by an audit that greps for Gemini SDK usage.
Finally, confirm the tier. Storage for Gemini API logs is available only for projects on the paid tier. That is consistent with the changelog's framing, and it means the change does not reach free-tier projects.
One operational footnote from the same guide: a project needs at least one active API key for logs to be displayed. If every key in a project is deleted, log visibility disappears until a key exists again. That matters during an incident, when keys are sometimes rotated or revoked first and investigated second.
How long stored requests last
Retention is a separate setting from storage, and the defaults are stated plainly. Logs expire and are marked for deletion after a default window of 55 days, unless they are saved to a dataset, which does not expire. A project's retention window can be configured to 7, 14, 28, or 55 days, with 55 as the maximum.
Three consequences follow. The default is the longest permitted window, so a team that wants less must act rather than rely on a default. Datasets are an explicit exception, which makes them the right place for records you must keep and the wrong place for data you meant to expire. And retention is a project-level control, so projects with different data classes should not share a setting by accident.
The Interactions API documentation describes the same retention shape for its own objects, with a tier difference: paid tier retains interactions for 55 days, free tier for 1 day, and paid projects can configure the window to 7, 14, 28, or 55 days in AI Studio. A shorter window may affect retrieval of past conversations.
The two ways to opt out, and which one wins
The per-request route is the store parameter set to false. It is precise: you can disable storage for the calls that carry sensitive content while leaving the rest observable. The cost is discipline, because every request has to carry the flag, and a single client that forgets it writes to storage again.
The project-level route is the Settings panel in the Gemini API Logs dashboard, where storage can be toggled independently for the Generate Content API and the Interactions API. It applies once and covers every call in that project, including calls you did not write, such as a vendor SDK or an internal tool pointed at the same key.
The precedence rule resolves conflicts: the request-level store property takes precedence over the project-level setting. That is convenient for exceptions, and it is also a warning. If your project-level switch is off but an application sets store=true, storage happens anyway. Auditing the dashboard alone is not enough; the request path has to be checked too.
For teams that already log prompts deliberately, provider-side storage is not a substitute for your own records, and your own records should not become a second copy of everything.
What opting out costs
This is the part that turns a privacy toggle into an architecture decision. The Interactions API documentation states that store=false is incompatible with background execution and prevents using previous_interaction_id for subsequent turns.
In plain terms: storage is what makes server-side conversation state and long-running background work possible. Turn it off and those features stop being available for that request, so a pipeline built around continuing a conversation by ID needs a different design, either sending the relevant history each time or accepting that stateful features are unavailable.
The same documentation notes that server-side state is optional and that stateless operation is supported by sending the full conversation history in each request. That is a real option, not a dead end, but it changes token usage and application logic. Test it on non-sensitive traffic before you flip a production path.
There is also a deletion path worth knowing. On the paid tier you can delete stored interactions at any time with the delete method, which requires the interaction ID. The design implication is circular but honest: if you never stored the interaction, there is no ID to delete. Deletion is a remedy for data you kept, not a substitute for deciding not to keep it.
Why the Interactions API is the reference point
The default change is best read as alignment. The Interactions API already stored requests by default to support previous_interaction_id, background=true, and observability, and the Generate Content API now matches that behavior for new projects.
The strategic detail is in the Interactions documentation: going forward, all new models, multimodal capabilities, tools, and agentic features will launch on the Interactions API. The same page describes the original generateContent API as legacy but fully supported.
That sentence should shape the policy. A blanket "turn storage off everywhere" is not a durable position if the capabilities you plan to adopt arrive on the API whose state features depend on storage. The durable position is tiering: decide per data class, keep the retention window as short as the requirement allows, and be explicit about which workloads need stateful features.
For teams running multiple projects or customers, the same logic applies at the tenant boundary; the multi-tenant guide covers separating quotas and keys, and storage settings belong in that same per-tenant checklist. If you route through an OpenAI-compatible layer, add a line for provider-side storage defaults to your own integration review.
A policy that survives the next default change
Defaults will keep moving, in both directions, and each move will be announced in a release note that most teams read after the fact. The defense is a small, explicit policy rather than a one-time toggle.
Classify traffic first. Requests that carry customer content, credentials, or regulated data are candidates for request-level store=false. Internal debugging traffic is usually the opposite: keeping it is what makes observability possible, and the logging guide explains what to capture without capturing secrets. The API key hygiene guide covers the credential side of the same boundary.
Then set retention to the shortest window that satisfies the requirement, remembering that the default is the maximum and that datasets do not expire. Record who deleted what, by interaction ID, so a deletion request can be answered with evidence rather than memory.
Finally, add the check to the integration process. The API integration checklist and the internal docs are where a new vendor or endpoint gets reviewed; "what does this provider store by default, for how long, and how do we turn it off" belongs in that review, next to base URL and model IDs.
The checklist
- List projects and their creation dates; the 2026-10-26 boundary decides the default.
- Confirm whether traffic reaches Gemini through an OpenAI-compatible endpoint, not only through the native SDK.
- Classify data: customer content, regulated data, and internal debugging traffic may deserve different settings.
- Choose per-request
store=falsefor sensitive calls, and the project-level toggle for whole projects that should never store. - Before disabling storage, test whether the workload depends on
previous_interaction_idorbackground=true. - Set retention to 7, 14, 28, or 55 days based on the requirement, not on the default.
- Keep evidence you must retain in a dataset, and record deletions by interaction ID.
- Add "provider-side storage default and retention" to the vendor integration review.
The change itself is one line in a release note. The work it implies is a short policy, applied per project and per data class, with the state trade-off understood before anything is switched off. Verify the current behavior on the official pages, because the next default may move in the other direction.
All details above follow the official pages as checked on 2026-10-27; confirm them against the current documentation before relying on them.