Thank you for looking into this. I am happy to provide the exact details regarding my setup, as well as a timeline of a test I ran to track this billing anomaly.
Account & Setup Details:
-
Account Type: This is my individual, personal test project. I am the only developer working on it.
-
Authentication Method: I am accessing the Gemini API using a static API Key generated in Google AI Studio. I am not using OAuth for end-users or a Service Account JSON file.
-
Shared Credentials: The API key is strictly private and has never been shared.
-
Tech Stack: Rust backend using the reqwest HTTP client with connection pooling, calling the REST endpoint (generativelanguage.googleapis.com/v1beta).
-
Model: models/gemini-3.1-pro-preview
Cache Test & Logs:
To understand the issue, I ran a strict test using curl. I created a cache with a short TTL (60 seconds) and monitored the API and billing.
1. Creating the cache (TTL: 60s):
% ./cache_create.sh 60s
{
"name": "cachedContents/frp5xlu6h48e7w2ui9g82imzcoods3e9gb3aonft",
"model": "models/gemini-3.1-pro-preview",
"createTime": "2026-03-22T09:34:49.342985Z",
"updateTime": "2026-03-22T09:34:49.342985Z",
"expireTime": "2026-03-22T09:35:48.044411163Z",
"displayName": "",
"usageMetadata": {
"totalTokenCount": 4100
}
}
2. Querying the cache list (Cache exists):
% ./cache_list.sh
{
"cachedContents": [
{
"name": "cachedContents/frp5xlu6h48e7w2ui9g82imzcoods3e9gb3aonft",
"model": "models/gemini-3.1-pro-preview",
"createTime": "2026-03-22T09:34:49.342985Z",
"updateTime": "2026-03-22T09:34:49.342985Z",
"expireTime": "2026-03-22T09:35:48.044411163Z",
"displayName": "",
"usageMetadata": {
"totalTokenCount": 4100
}
}
]
}
3. Querying the cache list after TTL expired (Cache is gone):
% ./cache_list.sh
{}
Billing Observations Timeline:
After confirming the cache was gone via the API, I checked the billing dashboard every hour. Here is what happened with SKU E181-DFF8-56CF:
-
First 12 hours: The SKU did not appear at all (expected delay).
-
Next 12 hours: The SKU appeared, but showed a massive, highly inflated spike of 2801 hours (incorrect).
-
Next Day (24h+ later): The SKU retroactively auto-corrected itself down to 66.85 hours (correct).
My Hypotheses regarding the issue:
Based on these observations, I have two thoughts on what is happening on your backend:
-
Initial Miscalculation Bug: For some reason, the billing system initially drastically overestimates the cache duration (showing huge spikes on day 1 every time), and only triggers a reconciliation/correction job the following day to fix the data (on next day).
-
The “Zombie Cache” Scenario (My original issue): In the case where my bill was growing infinitely for 3 days, a cache was expired/deleted, but got stuck in your system. So the billing system assumed it was still active, charging me every hour. It seems the backend only triggered the reconciliation process after I completely Disabled the Gemini API. Once disabled, the system spent the next 3 days (day by day) retroactively correcting the previous 3 days of phantom growth back to the accurate values.
I hope these logs and timeline help your engineering team pinpoint the bug.
