What happened
Google’s Gemini API documentation now says that Generate Content requests are stored by default for new projects on the paid Gemini API tier. The change applies to projects created on or after October 26, 2026. In request terms, the default is store=true for the Generate Content API in those new projects.
The scope is broader than one synchronous endpoint. Google lists generateContent, streamGenerateContent, and batchGenerateContent under Generate Content behavior. It also says that supported logging includes calls made through its OpenAI-compatible endpoint. That means an application using an OpenAI-shaped integration surface is still subject to the Gemini project’s storage configuration rather than escaping the setting through a compatibility layer.
The prior-project behavior remains distinct. Projects created before October 26 retain their existing Generate Content storage preference, which is store=false unless logging had previously been enabled in Google AI Studio. The change is therefore not described as a retroactive switch for existing projects; it is a new-project default. Storage for Gemini API logs is available only for projects on the paid tier.
Google provides two control levels. In Google AI Studio, a team can enable or disable storage separately for Generate Content and the Interactions API at the project level through the Gemini API Logs Dashboard settings. A request can also explicitly set store to true or false, and the request-level property overrides the project-level setting. The documentation gives minimum SDK versions for setting this property on Generate Content requests: google-genai 2.33.0 for Python, @google/genai 2.31.0 for JavaScript, google-genai 1.79.0 for Java, and google.golang.org/genai 1.76.0 for Go.
Interactions API storage is not the newly changed surface: Google says Interactions stores requests by default, in part to support server-side state management. Turning off Interactions logging in AI Studio prevents automatic storage and retrieval of conversation history unless a request explicitly overrides that behavior. Managed Agents are excluded from the set of API calls the logging page says it supports.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
No supplied pattern genuinely fits this narrowly documented storage-default change; it is a configuration and retention signal rather than evidence for a broader product architecture shift.
Why it matters
A default is operational policy disguised as convenience. Teams often create projects through templates, experiments, or separate environments and assume the new project behaves like the one they already operate. Here, that assumption can produce different handling of requests solely because a project was created after a stated date.
For teams sending proprietary application context, user submissions, or sensitive prompts to Gemini, the first deployment task is now to make storage intent explicit. Project-level configuration can establish a baseline, while store=false at the call level can protect particular flows where retention should be disabled. The practical concern is not that Google’s documentation establishes every compliance outcome for every workload; it is that retention behavior must be reviewed before the first production request, not discovered after integration.
What happens next
- More Gemini integrations will make storage intent explicit in shared client wrappers and project templates. (3 months, 70%). Watch for: SDK examples and internal setup checklists that set
storedeliberately. - Teams with pre-existing and newly created Gemini projects will audit for inconsistent logging behavior. (6 months, 65%). Watch for: project inventories comparing creation dates and Logs Dashboard settings.
Limits and uncertainty
The documentation establishes the storage default and its configuration controls, but it does not, in the supplied material, specify a retention duration, storage location, deletion workflow, access model, or legal treatment for stored requests. It also does not say why Google selected October 26, 2026, whether every paid-tier billing arrangement is identical, or how organizations should classify particular data types. A store=false setting is a documented control, but teams still need to assess their own application architecture, project configuration, and obligations rather than infer a complete data-governance program from this page.
Skill to build now
Add an explicit storage setting to your Gemini client wrapper this week. For each route that uses Generate Content, decide whether the request should pass store=true or store=false rather than inheriting a project default. Then check the Google AI Studio Logs Dashboard for every paid project, especially projects created after October 26, 2026. Record the intended setting beside the project identifier and test one request-level override so a future SDK or infrastructure change does not silently alter the behavior you expect.
Reader takeaway
New paid Gemini API projects no longer share the old Generate Content assumption of non-storage by default. If request retention matters to your product, set and review store deliberately at project creation and, where needed, on individual calls. The relevant engineering change is small; the governance consequence can be large.
Open question
Will Google publish retention, deletion, and access details that let teams evaluate the practical consequences of this storage default beyond the store control itself?