Gemini 3.1 Pro Cloud Agent session — cache-read tokens nearly doubling call-to-call, ~180M tokens for one UX review

Discussions
, ,
1

Has anyone else seen Gemini 3.1 Pro cache-read tokens balloon within a single Cloud Agent session?

I ran a full UX review with a Cloud Agent using gemini-3.1-pro. The session made two model calls 83 minutes apart:

  • Call 1: 68.8M total tokens (64.4M cache-read)
  • Call 2: 111.9M total tokens (99.5M cache-read) — a 55% larger cache-read than call 1

Together these two calls blew off my whole billing period on API.

I fully understand a context-heavy review will legitimately pull in a lot of files/history, and that cache-read is expected to grow somewhat as a session continues. What I’m trying to understand is whether a near-doubling of cache-read tokens between two calls in the same continuous session is normal behavior, or a sign the agent re-processed/re-sent context it should have already had cached.

Has anyone run into something similar with Gemini 3.1 Pro specifically, or found a way to confirm from the client side whether a session is reusing cache efficiently vs. reloading context each turn? Trying to figure out if this is expected behavior I should just budget for - basically not use cursor for - or a bug worth flagging.

Thanks!

9

Hey @FredP, thanks for the detailed report,!

What you’re seeing is common behavior with Gemini models in long agent sessions. The “two calls” on your dashboard are actually grouped usage events, each covering hundreds of individual model calls the Cloud Agent made while it worked. On every step, the model re-reads the whole conversation so far as cache-read tokens, which are billed at a much lower rate than fresh input. That’s why cache-read makes up almost all of your total.

Gemini in particular tends to take many small tool-call steps on big review tasks, so these totals show up most often with Gemini models.