Gemini API Request Storage Is Now Default for New Paid Projects

Google has turned on request storage by default for new paid-tier Gemini API projects using Generate Content. The change took effect on October 26. Existing projects retain their current setting, so the update does not switch logging on across every application already using the API.

The Gemini API changelog names three affected methods: generateContent, streamGenerateContent and batchGenerateContent. Their new-project default is store=true, matching the Interactions API.

For developers, this changes what a fresh project does before anyone deliberately configures logging. If your deployment process creates projects for new customers or environments, request-storage settings now deserve an explicit check during provisioning.

Which projects are affected?

Google's data logging and sharing policy specifies Generate Content projects created on or after October 26, 2026. Logging is available for billing-enabled projects.

This distinction matters when comparing development and production. A team might create a replacement project, reuse the same application code and still inherit a different storage default. Checking only the request payload would miss a project-level configuration difference.

How to opt out

The changelog gives two controls. Set store=false on individual requests, or disable Generate Content API logging in the Settings panel of AI Studio's Logs and Datasets dashboard.

The request option lets an application state its choice explicitly. The dashboard option changes the project configuration. Teams should decide where they want to manage that choice and check it when creating another environment.

I would make the check part of release review: identify the project serving the application, inspect its logging setting and confirm that the request path applies the intended storage option. Repeat that review for streaming and batch workflows if the application uses them. A successful model response says nothing about whether the storage configuration matches your intention.

Storage and model training are separate choices

Google describes these logs as developer-owned data private to the Cloud project. These are separate from abuse-monitoring logs.

By default, prompts and responses in these paid-project logs are not used for product improvement or development. Choosing to share a dataset with Google changes the applicable data-use terms and can permit model improvement and training.

The default maximum retention period is 55 days, after which logs are marked for deletion. Project owners can choose 7, 14, 28 or 55 days. Dataset storage is separate and has no fixed expiry.

That creates two separate review questions for a team: whether requests should be stored for its own use, and whether any selected data should be shared with Google. Enabling one should not be treated as an answer to the other.

Put the setting into deployment documentation

Request logs can be useful when investigating a poor answer or reproducing an application problem. They also create another stored copy of material that passed through the application. The appropriate choice depends on what the application processes and who is responsible for that data.

A concise deployment record can name the logging owner, the selected retention period and any request-level opt-out. That gives the next engineer something concrete to verify when a project is recreated, instead of relying on what the previous default happened to be.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain API changes and developer workflows clearly, including the configuration details that affect adoption and trust.

Book a 30-minute call.