Gemini API request logging: new paid projects store requests by default

Which projects are affected? Check the tier and creation date

Google’s October 26 release note and current logging guide confirm that new Gemini API projects created from that date store Generate Content requests by default. The logging feature is currently limited to paid-tier projects. Do not apply this rule directly to the consumer Gemini chat app or Vertex AI.

Projects created before October 26 retain their existing setting: Generate Content remains store=false unless logging was previously enabled in AI Studio. When moving to a new project, recheck the default even if the code and model name stay the same. The team’s memory of an older project is insufficient.

How do you check one request? Inspect store as well as the project default

The store field controls whether a request enters this logging storage mechanism. An explicit request value overrides the project setting, so a screenshot showing logging disabled in the console does not prove that every client avoids storing requests.

Have an authorized project owner check Settings in the AI Studio Logs Dashboard, inspecting the Generate Content and Interactions controls separately. Then inspect the actual request and SDK configuration: omitting store uses the default; an explicit false disables logging for that request. Inspecting settings does not require submitting real keys, customer text, or production conversations.

Before changing a client, check the SDK version and field placement

Google lists these minimum SDK versions for Generate Content store support: Python google-genai 2.33.0, JavaScript @google/genai 2.31.0, Java google-genai 1.79.0, and Go google.golang.org/genai 1.76.0. Having the package installed does not establish that it supports the field.

The Python Generate Content example places the switch in config={'store': False}; JavaScript uses config: {store: false}. In the Interactions examples, store is a top-level request field. These are field-placement notes, not executed API calls. If your integration uses a wrapper, check that it does not discard or override the field.

Use fictional text without private data in an authorized isolated environment to check request serialization and configuration propagation. If the client rejects the field, verify its version and the actual API before consulting the current official example. Changing IP addresses, rotating keys, or adding retries will not resolve a configuration mismatch.

Why check Interactions separately? It also manages conversation history

Interactions already stores requests by default to support server-side conversation state. The previous_interaction_id field can continue an earlier interaction. This is distinct from the October 26 change to the Generate Content default for new projects.

Disabling Interactions logging at the project level prevents automatic storage and retrieval of conversation history unless a request explicitly overrides it. Applications that depend on that history should first decide how subsequent context will be supplied. A single setting change does not validate both privacy behavior and multi-turn conversation behavior.

Retention and missing logs: distinguish logs from datasets

Logs default to 55 days of retention, with project options of 7, 14, 28, or 55 days. Expired logs are marked for deletion; the expiry time is not a promise of immediate complete erasure. Separately saved datasets do not automatically expire with those logs.

The guide also requires at least one active API key in a project to view its logs. Losing visibility after deleting all keys does not establish deletion. Do not use key deletion as a log-cleanup method or treat an empty view as proof that no requests were stored.

Make the decision traceable and keep troubleshooting evidence minimal

For each project, record its creation date, paid tier, API, project default, explicit store values used by clients, SDK versions, and dependencies on conversation history. Distinguish a planned change, an applied configuration, and a controlled validation result. A false value in a configuration file alone does not validate the whole system.

Disabling this logging feature does not establish zero retention, removal of all historical data, or a change to training terms. Those questions require their own product and contractual evidence. For troubleshooting, prefer redacted error codes, timestamps, and request identifiers, and review your own gateway, client, and relay logs separately. This guide did not access private projects, change settings, or test anyone’s requests.