Gemini Now Keeps New Paid Projects' Requests for 55 Days

Since 26 October, a Gemini API project created on the paid tier stores every generateContent, streamGenerateContent and batchGenerateContent request and response for 55 days, viewable in the AI Studio logs page. Projects created before that date keep storage off unless someone switched it on. The per-request opt-out is a top-level store: false, and the SDKs that can send it on this endpoint shipped three days before the default flipped.

Send config: { store: false } through @google/genai 2.30.0, the version from 15 October, and the request goes out without the field and succeeds. I captured the bodies on a local server: 2.30.0 drops it, 2.31.0 sends it. The Python SDK one version back refuses the field with a validation error instead, which is the better failure.

On the OpenAI-compatible endpoint, which the docs list as logged, store in either state returns a 400. There is no request-level opt-out on that path, only the project switch in AI Studio. And nothing in a response, header or body, says whether the request was kept.

What changed on 26 October

The release note is three sentences. New projects on the paid tier that use the Generate Content API now store requests by default, matching the Interactions API, which already stored requests by default so that previous_interaction_id and background execution can work. Existing projects keep their current setting. The opt-out is store=false per request, or the Generate Content API toggle in the settings panel of the Logs and Datasets dashboard.

The data logging page, last updated the same day, describes what the logs are. They are private to your Google Cloud project, separate from the abuse-monitoring logs Google keeps anyway, retained 55 days by default, with 7, 14 or 28 days available in AI Studio. They are not used to improve models unless you build a dataset from them and share it, at which point that dataset falls under the terms for Unpaid Services and human reviewers may read it. The same page announces an invite-only Contributor Tier: up to 50% off token costs on Gemini 4 Argon, 3.1 Pro Preview, 3.8 Flash and 3.5 Flash-Lite in exchange for Google using your data from those models.

The logs are a product feature, not a terms change. The practical effect is that a project created this week has 55 days of prompts and responses in a dashboard its developer may not know exists.

What I ran

Everything below is about a dozen calls on gemini-3.8-flash, each a seven-token prompt asking for the word pong, for well under a cent in total. The SDK tests ran against a local HTTP server on my laptop that logs the request body and answers with a canned response, so I could see what each SDK version puts on the wire without the real API involved. The REST and Interactions tests went to the real API with the key from this workspace.

That key belongs to a project created before 26 October. The API gives no way to read a project's storage setting, so I can't tell you whether my generateContent calls were kept. That is part of the point.

Where the field goes

The control row matters. The API rejects fields it doesn't know, so a 200 on the first three rows means store was parsed, not ignored. A hand-built request with the field in the wrong place fails loudly, which is more than the JavaScript SDK does.

The SDK one version back

The docs say setting store on Generate Content requests needs google-genai 2.33.0 for Python, @google/genai 2.31.0 for JavaScript, 1.79.0 for Java and 1.76.0 for Go. The Python and JavaScript releases both landed on 23 October, the Go one on 22 October. I installed the version on either side of the line for Python and JavaScript and pointed each at the capture server.

The JavaScript row is the one to act on. On 2.30.0 the config object accepts store, the request builder doesn't know the key, the body goes out without it and the call returns normally. If the project is new, the request is stored, and the code that was written to prevent that reports success. TypeScript catches it, because the GenerateContentConfig type in 2.30.0 has no store member, so a strict build fails to compile. Plain JavaScript, or a config typed as any, sails through.

Python fails at the pydantic layer before any network call, with a message that names the field. That is what you want from a privacy switch: either it works or it stops you.

Both SDKs, at every version, send store: false correctly on interactions.create, because that parameter has existed there since the Interactions API shipped. The gap is specific to the older endpoint.

The endpoint with no switch

The logs guide says calls through the OpenAI compatibility endpoints are included in logging. The OpenAI SDK has a store parameter of its own, false by default on OpenAI's side, and a developer who points that SDK at generativelanguage.googleapis.com/v1beta/openai and sets store=False to be safe gets a 400 back. The field is not accepted in either state.

So on that path the project-level setting is the only control. For a new project, that means logging is on until someone opens AI Studio and turns it off, and no amount of request-side care changes it.

An interaction you don't store has no id

The Interactions API has had this default all along, and it is worth seeing what the opt-out does there. A default interactions.create came back with an id, and a GET on that id returned the full record including my user_input step. The same call with store: false returned the answer and no id field at all. There is nothing to fetch, delete, or continue from, which is the documented trade: store=false rules out previous_interaction_id and background execution.

That missing id is the only signal the API gives. On generateContent there is no difference to observe.

The new CLI runs on the stored one

Google announced the gemini-api CLI as a beta on 27 October, a stateless Go binary for coding agents, scripts and CI, at v0.4.5 since 30 October. Its generate and media commands are Interactions API model calls, so each one is stored by default, for 55 days on a paid project. The README is open about it: the CLI keeps no local conversation state, and server-side interactions manage their own retention. Managed agent runs are the exception; the logs guide says those are not shown in the dashboard.

gemini-api agent run exposes the field as a flag. generate, image and the other media commands don't; for those you pass --body with "store": false, which the README's own hero-image example does. If the CLI is going into a pipeline that handles customer documents, that body file is where the opt-out lives.

What to do

If you created a Gemini project this week and it handles anything you wouldn't want in a dashboard for two months, open the Logs and Datasets settings in AI Studio and set the Generate Content API toggle before you set anything in code. The project switch covers the OpenAI-compatible path and every SDK version at once.

If you rely on store: false in code, pin @google/genai to 2.31.0 or later and google-genai to 2.33.0 or later, and add a test that asserts the field is in the outgoing body. Mine was a 20-line HTTP server. On TypeScript, keep the build strict; it is the only thing that caught the 2.30.0 case without a capture.

Not tested: batchGenerateContent, the Go and Java SDKs, the AI Studio toggle itself, whether a request from a pre-26 October project is kept, and Vertex AI, which is a different product with its own logging. The SDK captures ran on my laptop against a fake server; the REST results are from the live API on 31 October.