Gemini request records: choose what your app keeps

Know what stays after a request

Before adding customer information to an AI feature, ask what remains after it produces an answer. A useful starting point is a demonstration with invented details, showing the app's saved request history and the settings controlling it.

On October 26, Google changed the default for new paid projects using the Generate Content part of the Gemini API, the connection an app uses to ask Gemini for an answer. Supported requests are now stored by default. Existing projects keep their previous setting.

Saved request records can help a builder understand an unexpected answer and improve the tool. The useful choice is deciding which information belongs in those records and how long the team needs it.

Read the announcement: Google: October 26 Gemini API storage-default change.

Check the content and the lifetime

Google's guide says records can include the full request sent to Gemini, its response and context from earlier turns. Storage for these logs is available on the paid Gemini API tier. A log is a saved record of a request and its result.

By default, logs expire and are marked for deletion after 55 days. The project can instead use a 7, 14 or 28-day window. If someone saves records into a dataset, a collected set of examples, that collection does not expire automatically.

Google also lets teams choose to share datasets for its research and development. Saving request records and choosing to share a dataset are separate controls. Check the choices your project actually makes rather than assuming they are the same.

Ask to see the setting in your project

The official guide describes a logging switch for each project in Google AI Studio. A builder can also choose whether to store an individual request. Those request-level choices take priority over the project setting and require supported versions of Google's software tools.

Review the relevant setting with the person responsible for your app. Agree who may inspect saved requests and how a person can raise a question about information the tool keeps. Avoid copying private records into a shared project note.

You can practise the review without customer data. Use an invented message whose wording you recognise, and compare the record with the information you expected to save.

1. List what the app sends to Gemini for one useful task.
2. Use an invented example and ask the builder to show which parts appear in the request record.
3. Confirm the project's storage choice, how long records stay and who can view saved examples.
4. Check whether any records are saved into longer-lived collections, and agree who manages them.

Keep useful evidence deliberately

Our perspective is that being able to explain an AI app's saved information is part of building it well. A clear record can help improve answers, while a deliberate storage choice helps the team understand what it is responsible for keeping.

For a guided build or a tool commissioned from a studio, include these choices in the handover. You should be able to ask a simple question about where the information goes and receive an answer you can understand.