Gemini API now stores your requests by default: audit your projects
Since 26 October 2026, new paid Gemini projects store requests for 55 days unless you say otherwise. What changed, what the docs say, and an audit script for call sites that never set store=false.
Prakhar
Backend engineer · PressentifyPublished • Updated 30 October 2026

Fifty-five days. That is how long Google will now keep the prompts and responses of any Gemini API project created on or after 26 October 2026, unless you tell it not to. The changelog entry is one sentence long and never mentions the number.
If your team sends customer text to Gemini, read the docs page behind that sentence today, because the number is there and the switch is yours.
One sentence in the changelog, and a docs page that fills it in
The 26 October entry says new projects on the paid tier that use the Generate Content API “now store requests by default,” which means store=true. It adds that this matches how the Interactions API already behaved. Existing projects keep what they had. You opt out with store=false or in the Logs and Datasets dashboard.
Alex Merced’s weekly roundup on dev.to the same day puts it more bluntly: Google “turned on request storage by default for new paid-tier projects.” He lists the affected methods as generateContent, streamGenerateContent and batchGenerateContent, and he is right that the changelog gives no retention period.
The Logs and datasets page does. Logs expire and are marked for deletion after a default window of 55 days, adjustable in AI Studio to 7, 14, 28 or 55. The same page says the request-level store property takes precedence over the project-level setting. That last line is the useful one. You can fix this in code, call by call, without waiting for whoever owns the Cloud project.

What I could not verify
store in each language. The REST body takes it at the top level of the request, as shown below. In the Python and JS SDKs, check where your installed version puts it before you ship, because a misplaced key in a config object can be silently ignored.The per-request fix is two lines
POST https://generativelanguage.googleapis.com/v1beta/models/MODEL:generateContent
{ "contents": [ ... ],
"store": false }That is the whole opt-out for one call. Put it in the one wrapper function that talks to Gemini, not at forty call sites. If you do not have a wrapper, that is the real finding of this audit.
What 55 days of default adds up to
Take a support tool sending 20,000 Gemini calls a day, each with a ticket body that may hold a name, an email or an order number. At steady state that is 20,000 x 55 = 1.1 million stored request and response pairs in a Google-hosted log. You did not design that store, it is not in your data map, and your deletion process does not know it exists.
Two facts keep this honest. Google says logging is only available on billing-enabled projects and that logs are not used for product improvement by default. Sharing a dataset with Google is a separate, deliberate choice. So this is not Google training on your tickets. It is a retention copy you did not plan for, which is exactly what an auditor asks about.
Which setting for which kind of traffic
| Traffic | Setting | Why |
|---|---|---|
| Customer PII, health, finance | store=false on every call | No copy to govern. Easiest answer to a regulator. |
| Internal tools, no personal data | Default, retention cut to 7 days | Logs help debugging; a short window limits exposure. |
| Eval and prompt tuning sets | Store, then save chosen logs to a dataset | Datasets do not expire, so redact before you save. |
| Unknown, nobody owns it | store=false until someone does | Turning storage on later is easy. Un-storing is not. |
My own rule: store nothing by default and opt in per feature, with a named owner and a retention number written next to the flag. The vendor default is a convenience for their product, not a policy for yours.
Find the calls that never said no
Read the dashboard first, but a dashboard cannot tell you which line of code sent a request. This script can. It walks a directory, finds Gemini call sites in JS, TS and Python, and fails on any with no explicit store set to false within a few lines. It is a text heuristic: a call that gets store from a helper three files away will be flagged, and a comment containing the right string will pass. Both errors are tolerable in an audit.
// Usage: node audit.mjs <dir>. Flags Gemini call sites with no explicit store: false nearby.
import { readdirSync, readFileSync, statSync } from 'node:fs';
import { join } from 'node:path';
const CALL = /\b(generateContent|streamGenerateContent|batchGenerateContent|generate_content|generate_content_stream)\b/;
const SAFE = /\bstore["']?\s*[:=]\s*(false|False)\b/;
const SKIP = new Set(['node_modules', '.git', '.next', 'dist']);
function* walk(d) {
for (const n of readdirSync(d)) {
if (SKIP.has(n)) continue;
const p = join(d, n);
if (statSync(p).isDirectory()) yield* walk(p);
else if (/\.(m?[jt]sx?|py)$/.test(n)) yield p;
}
}
let bad = 0;
for (const f of walk(process.argv[2] || '.')) {
const lines = readFileSync(f, 'utf8').split('\n');
lines.forEach((l, i) => {
if (!CALL.test(l)) return;
const window = lines.slice(Math.max(0, i - 5), i + 15).join('\n');
if (SAFE.test(window)) return;
bad++;
console.log(`${f}:${i + 1} no store=false within 20 lines: ${l.trim()}`);
});
}
console.log(bad ? `FAIL: ${bad} call site(s) rely on the project default` : 'PASS');
process.exit(bad ? 1 : 0);I ran it on 30 October 2026 against two fixtures: one JS call with no store, and one Python call passing a config dict with "store": False. The Python one passed. The JS one did not, and the exit code went to 1 so CI can block on it.
$ node audit.mjs fixtures
fixtures\a.mjs:1 no store=false within 20 lines: const r = await ai.models.generateContent({
FAIL: 1 call site(s) rely on the project default
$ echo $?
1
The compliance questions that come after the code
Changing code fixes new traffic. It does nothing for the logs already sitting in any project created since the 26th. Work through these in order.
- Inventory. List every Google Cloud project that calls Gemini, with its creation date. Anything on or after 26 October is storing.
- DPA. Check that your data processing agreement with Google covers stored API logs, not just inference. I could not verify the terms; ask your Google contact rather than assuming.
- Retention. If you keep storage on, set the window in AI Studio to the shortest your debugging needs, and write that number in your data map.
- Deletion. Work out how you would delete one user’s logs on request. If the answer is “wait 55 days,” your privacy notice must say so.
- Redaction. Strip emails, phone numbers and IDs before the request leaves your server. It protects you whether or not storage is on, and it is the only control that works for datasets that never expire.
Next step for today: run the script, add the wrapper, and open the dashboard of your newest project. It takes less time than reading this post did.
Sources & Credits
- Google, Gemini API changelog, entry of 26 October 2026: ai.google.dev/gemini-api/docs/changelog
- Google, Gemini API “Logs and datasets”: ai.google.dev/gemini-api/docs/logs-datasets
- Alex Merced, AI Weekly, dev.to, 26 October 2026: dev.to
The audit script, table, graphics and arithmetic are our own work. Last verified 2026-10-30. Corrections: if Google changes these settings or we got a detail wrong, tell us and we will fix this page and note the change here.
Share this article
Written by
Prakhar
Backend engineer · Pressentify
Backend engineer building Pressentify — interactive cheatsheets, handbooks and a job-hunt workspace.
Get the next one in your inbox
One practical backend article at a time. No spam; unsubscribe in one click.
Keep reading

Copilot drops Opus 4.8 and GPT-5.6 Terra on Nov 16, the API drops Sonnet 4.5 on Nov 30. Are you pinned?
Three retirement dates in the next 31 days, one of them already past for Gemini. A repo scanner for pinned model IDs, an eval gate that blocks regressions, and the order I would migrate in.
· 8 min

LiteLLM 1.107.0 was a credential stealer: how it got into the release workflow
A malicious LiteLLM 1.107.0 sat on PyPI for about 1h41m on 21 October 2026 and stole secrets at install time. The timeline, the release-workflow hole, and an audit you can run today.
· 8 min

PgBouncer 1.26.1 fixes an auth bypass: one SCRAM password can log in as any user
CVE-2026-107350 lets a client that knows one SCRAM user's password log in as another, admins and superusers included. Two denial-of-service bugs ship in the same release. What to check and what to patch.
· 3 min