URGENT: Huge cost cache increase issue (2)

On 2026-06-06 at 14:00 (BRT), I noticed a spike in explicitly cached token usage.

SKU

{
    "id": "583D-5DB6-4555",
    "description": "Generate_content cached text storage token hours for gemini 3 flash"
}

At first, I thought the issue was on our end because we were running an analysis and actively creating cached content.

The costs started to increase on 2026-06-03 at 13:00 (BRT), which was the exact time our script started.

On 2026-06-06 at 14:00 (BRT), I turned the script off and verified that there were no remaining listed caches (reference)

At that time, I opened a billing issue (#720261..) to see if we could negotiate the charges, as I initially thought this was our mistake and represented normal billed usage.

HOWEVER, SOMETHING IS DEFINITELY WRONG!

Since I turned everything off, the charges have not stopped accumulating. As of my last check on 2026-06-07 at 03:45 BRT, the cost has reached almost R$ 20k.

So, I started to dig deeper into this. I exported my billing data to BigQuery. Please see the hourly breakdown below:

usage_start_time (BRT) usage_end_time (BRT) Cost (BRL) Usage (M tok·h) Count Cumulative (BRL)
2026-06-03 13:00 2026-06-03 14:00 11.2573 1.9551 2 55.6892
2026-06-03 14:00 2026-06-03 15:00 23.4907 4.0798 2 79.1799
2026-06-03 15:00 2026-06-03 16:00 24.0273 4.1730 2 103.2072
2026-06-03 16:00 2026-06-03 17:00 23.2630 4.0402 4 126.4702
2026-06-03 17:00 2026-06-03 18:00 25.7959 4.4801 2 152.2661
2026-06-03 18:00 2026-06-03 19:00 23.5803 4.0953 2 175.8464
2026-06-03 19:00 2026-06-03 20:00 21.9892 3.8190 2 197.8355
2026-06-03 20:00 2026-06-03 21:00 26.9255 4.6763 4 224.7610
2026-06-03 21:00 2026-06-03 22:00 24.7933 4.3060 2 249.5543
2026-06-03 22:00 2026-06-03 23:00 27.0847 4.7040 2 276.6391
2026-06-03 23:00 2026-06-04 00:00 27.0106 4.6911 5 303.6496
2026-06-04 00:00 2026-06-04 01:00 26.8089 4.6560 3 330.4585
2026-06-04 01:00 2026-06-04 02:00 24.3714 4.2327 5 354.8299
2026-06-04 02:00 2026-06-04 03:00 24.3330 4.2260 2 379.1629
2026-06-04 03:00 2026-06-04 04:00 24.9384 4.3312 3 404.1013
2026-06-04 04:00 2026-06-04 05:00 27.7965 4.8276 2 431.8977
2026-06-04 05:00 2026-06-04 06:00 26.2819 4.5645 2 458.1797
2026-06-04 06:00 2026-06-04 07:00 26.4110 4.5869 2 484.5907
2026-06-04 07:00 2026-06-04 08:00 26.6055 4.6207 4 511.1961
2026-06-04 08:00 2026-06-04 09:00 25.3443 4.4017 2 536.5404
2026-06-04 09:00 2026-06-04 10:00 26.3138 4.5701 4 562.8542
2026-06-04 10:00 2026-06-04 11:00 25.1505 4.3680 2 588.0047
2026-06-04 11:00 2026-06-04 12:00 25.2133 4.3789 4 613.2180
2026-06-04 12:00 2026-06-04 13:00 26.7247 4.6414 2 639.9428
2026-06-04 13:00 2026-06-04 14:00 24.1219 4.1894 3 664.0647
2026-06-04 14:00 2026-06-04 15:00 22.8357 3.9660 3 686.9004
2026-06-04 15:00 2026-06-04 16:00 29.5106 5.1253 2 716.4109
2026-06-04 16:00 2026-06-04 17:00 27.0296 4.6944 2 743.4406
2026-06-04 17:00 2026-06-04 18:00 26.8817 4.6687 3 770.3222
2026-06-04 18:00 2026-06-04 19:00 26.4330 4.5908 3 796.7552
2026-06-04 19:00 2026-06-04 20:00 26.4825 4.5994 3 823.2377
2026-06-04 20:00 2026-06-04 21:00 27.7752 4.8239 4 851.0128
2026-06-04 21:00 2026-06-04 22:00 27.1360 4.7129 4 878.1488
2026-06-04 22:00 2026-06-04 23:00 26.8387 4.6612 2 904.9875
2026-06-04 23:00 2026-06-05 00:00 26.9636 4.6829 3 931.9511
2026-06-05 00:00 2026-06-05 01:00 28.1955 4.8969 1 960.1466
2026-06-05 01:00 2026-06-05 02:00 28.4486 4.9408 1 988.5953
2026-06-05 02:00 2026-06-05 03:00 26.9662 4.6834 2 1,015.5615
2026-06-05 03:00 2026-06-05 04:00 65.4293 11.3635 1 1,080.9908
2026-06-05 04:00 2026-06-05 05:00 27.9708 4.8578 2 1,108.9616
2026-06-05 05:00 2026-06-05 06:00 26.9316 4.6774 2 1,135.8932
2026-06-05 06:00 2026-06-05 07:00 26.8524 4.6636 2 1,162.7456
2026-06-05 07:00 2026-06-05 08:00 26.9929 4.6880 3 1,189.7385
2026-06-05 08:00 2026-06-05 09:00 26.8580 4.6646 3 1,216.5965
2026-06-05 09:00 2026-06-05 10:00 26.7391 4.6439 3 1,243.3356
2026-06-05 10:00 2026-06-05 11:00 27.0973 4.7061 3 1,270.4328
2026-06-05 11:00 2026-06-05 12:00 26.9872 4.6870 2 1,297.4200
2026-06-05 12:00 2026-06-05 13:00 26.8647 4.6657 3 1,324.2847
2026-06-05 13:00 2026-06-05 14:00 26.8342 4.6604 1 1,351.1189
2026-06-05 14:00 2026-06-05 15:00 29.1381 5.0606 3 1,380.2570
2026-06-05 15:00 2026-06-05 16:00 86.8009 15.0752 2 1,467.0579
2026-06-05 16:00 2026-06-05 17:00 145.7507 25.3133 4 1,612.8086
2026-06-05 17:00 2026-06-05 18:00 148.4111 25.7754 2 1,761.2198
2026-06-05 18:00 2026-06-05 19:00 149.3033 25.9303 1 1,910.5230
2026-06-05 19:00 2026-06-05 20:00 156.6750 27.2106 3 2,067.1980
2026-06-05 20:00 2026-06-05 21:00 156.8820 27.2466 1 2,224.0800
2026-06-05 21:00 2026-06-05 22:00 174.8669 30.3701 3 2,398.9469
2026-06-05 22:00 2026-06-05 23:00 207.9905 36.1229 2 2,606.9374
2026-06-05 23:00 2026-06-06 00:00 248.1091 43.0905 4 2,855.0465
2026-06-06 00:00 2026-06-06 01:00 298.8483 51.9027 2 3,153.8949
2026-06-06 01:00 2026-06-06 02:00 369.8446 64.2330 3 3,523.7395
2026-06-06 02:00 2026-06-06 03:00 410.3671 71.2707 1 3,934.1065
2026-06-06 03:00 2026-06-06 04:00 460.9613 80.0577 2 4,395.0678
2026-06-06 04:00 2026-06-06 05:00 458.3854 79.6103 1 4,853.4532
2026-06-06 05:00 2026-06-06 06:00 511.5525 88.8442 3 5,365.0057
2026-06-06 06:00 2026-06-06 07:00 562.9647 97.7732 3 5,927.9704
2026-06-06 07:00 2026-06-06 08:00 644.5889 111.9493 4 6,572.5593
2026-06-06 08:00 2026-06-06 09:00 714.5027 124.0916 4 7,287.0620
2026-06-06 09:00 2026-06-06 10:00 793.6961 137.8456 2 8,080.7581
2026-06-06 10:00 2026-06-06 11:00 875.1844 151.9981 2 8,955.9424
2026-06-06 11:00 2026-06-06 12:00 956.7866 166.1704 2 9,912.7291
2026-06-06 12:00 2026-06-06 13:00 1,037.6763 180.2190 4 10,950.4053
2026-06-06 13:00 2026-06-06 14:00 1,118.4296 194.2439 2 12,068.8350
2026-06-06 14:00 2026-06-06 15:00 1,155.6384 200.7061 4 13,224.4733
2026-06-06 15:00 2026-06-06 16:00 1,155.6846 200.7142 3 14,380.1579
2026-06-06 16:00 2026-06-06 17:00 1,155.6846 200.7142 1 15,535.8425
2026-06-06 17:00 2026-06-06 18:00 1,155.6846 200.7142 2 16,691.5270
2026-06-06 18:00 2026-06-06 19:00 1,155.6846 200.7142 1 17,847.2116
TOTAL 17,847.2116 3,099.6219 341

As the data shows, these are explicitly caching costs. I strongly suspect that the cache is not being cleared correctly on the backend, even though my scripts are turned off and the cache registry shows as empty!

In a desperate attempt to stop these accumulating charges, I have now completely disabled the Gemini API Service in my Google Cloud Project.

Please investigate this as a matter of urgency.

Here is what helped me (at least to check if this is the exact same issue):
If possible, disable all your Gemini accounts and wait 1-2 days. For me, the system started cleaning up automatically.

Also I did code fix: I now explicitly DELETE the cache via the API after it is created (once the timeout is reached). Basically, I create the cache with a longer TTL, but always delete it by my code.

Also, billing support told me last week that my issue was fixed on engeneering side. I don’t know if this will help, but you can reference to my billing support ticket number: 69966378.

Thank you @Liz2k,

I have disabled my project and I am abandoning the explicit cache.
On the other hand, what is curious is that the list API returns an empty dict, so I cannot delete the cache.

It is very stressful to see the costs increasing and not be able to do anything about it.

you right, list always (when bug happened) was empty for me ether.

So this is why I did fix where I create cache with longer TTL and Delete from code while it still alive.

Same thing happened to me. I asked to billing support about my situation and I added the link of this page for reference. I can share the result here after I get any response from support.

Same experience here. Support team tells you to go to the forum, meanwhile there is no response over here either.

Update: still no response after two days.

Our case is under analysis too.

Hi

Apologies for the delay on this.

This issue has been resolved , If you have created a billing case , can you please DM me the case number along with your project id and billing id

Hey @Mustan_lokhand, our team faced the same issue regarding this spike in billing due to cache. We have raised a billing case, but haven’t received a response yet.

The system won’t allow me to DM you with the details. Could you please send me a direct message so I can reply with our project and billing IDs? Thanks!"

First of all, thank you for resolving the issue.
I sent you a DM with the details.

I have a few questions about this case.

  1. Was it the “Orphan Cache” (or “Zombie Cache”) problem?
  2. Is it recommended to delete the cache explicitly like @Liz2k mentioned above as a secondary line of defense?

3. What should I do next with my billing case:
Do I have to deal with it to finish the case / or just wait for it to be closed?

[Situation]
Billing support asked me if I want to get “assistance with the bill” during the chat session.

  • I said “yes” because I had no idea what was going on with this problem.
  • I repeatedly insisted that I did not and wasn’t able to use that much, but the billing support kept saying the usage is recorded because “I used that much”.
  • (I guess) I got all of my prepay credit back now, but what should I do about my “assistance” process that never should have started in the first place?