Gemini API’s new storage default makes project settings part of the release checklist

Google’s October 26 release notes say newly created paid-tier projects now store Generate Content API requests by default, using store=true. The change covers generateContent, streamGenerateContent and batchGenerateContent and aligns the default with the Interactions API.

Existing projects keep their current setting. This is a change to the starting configuration of new projects, rather than an announcement that every existing integration has been switched on. The release notes identify two opt-out paths: store=false on an individual request, or disabling Generate Content API logging in the Logs and Datasets dashboard settings.

Google’s logging guide says projects created before October 26 retain their earlier Generate Content setting, which is off unless logging was previously enabled in AI Studio. The guide also says request-level store settings take precedence over project-level settings, and the two API families have separate project toggles.

Consider a hypothetical team whose older paid-tier project has logging off and whose application leaves store unspecified. Moving that unchanged application to a newly created paid-tier project can produce different storage behavior because the project default differs. This is an implication of the documented settings, not a report of a customer incident.

For a release review, “the code did not change” is therefore incomplete evidence. A useful deployment record includes the project, API family, intended project setting and any explicit request override. That gives reviewers something concrete to compare when a test environment becomes a production environment.

The Interactions API documentation explains that stored interactions support server-side conversation state. A later request can use previous_interaction_id to continue from an earlier interaction; disabling storage prevents that subsequent use. Applications that keep and resend their own full history use a different state-management pattern.

Google’s background-execution guide adds another dependency: background=true requires store=true. Combining background execution with store=false produces a 400 error. A blanket setting copied across unrelated API calls can therefore affect functionality as well as logging.

These dependencies make an API-by-API review more useful than a single instruction to disable storage everywhere. The intended behavior for a one-shot generation request may differ from a workflow that relies on a stored interaction to continue or finish in the background.

A small review can separate three questions: which project receives the request, which setting actually wins, and whether the application depends on retained state. Google’s logging guide notes that request-level control requires supported SDK versions, so an explicit application setting should be checked against the installed client rather than assumed to exist in every version.

A team can then verify its chosen behavior with non-sensitive test content and record the result with the release. Such a check establishes the configuration exercised by that test; it does not establish broader privacy, compliance or retention guarantees. Those require their own review of applicable documentation and requirements.