I use both models regularly and my tokens usage is always way above that, this completely killed all of my projects.
Also, this change makes no sense. How am i supposed to use 30 RPM with 16k context?? Really, what were they thinking?
I want to flag a specific issue with the TPM change rather than the RPD change. I think this thread is at risk of collapsing the two into a single complaint. They are actually separate problems with separate impacts.
My use case is creative writing, and I use Gemma 4 31B to expand and edit roleplay responses that I manually guide and continue. That workflow needs a single call to carry meaningful running context, including character grounding and recent exchange history, so the output stays coherent with what has already happened. Attempting to reduce this to smaller chunked calls breaks narrative continuity mid-scene.
RPD was never my constraint. Even at the old 1,500 requests per day free-tier cap, I had far more daily headroom than I could use. The volume side of these limits has always been generous for how I actually work. The new 16K TPM ceiling caps what a single request can send regardless of billing status. I have confirmed in the Cloud Console quota panel that this ceiling remains the same even at Tier 3, the highest paid tier available. Paying more buys no additional single-call headroom. This differs from how TPM scales for Gemini-branded models, where the free-to-paid jump increases capacity substantially.
Beyond my specific use case, capping the per-call ceiling without a mechanism to avoid re-paying fixed overhead turns smaller requests into more total compute for the same finished work. Stateless APIs mean every call resends the full fixed overhead. For agentic workflows, this includes system prompts, tool schemas, and MCP definitions. If that fixed tax consumes 5,000 to 10,000 tokens before a single token of actual task progress occurs, a 16K ceiling leaves only 6,000 to 10,000 tokens of usable headroom per call. Completing a task that requires ten tool-calling turns means paying that same 5,000 to 10,000 overhead ten separate times. The total tokens processed to finish the task goes up.
My creative writing editing workflow costs less compared to agentic workflows. My overhead consists mostly of the character card and system prompt. The overhead-multiplication effect also severely impacts developers building agentic and tool-calling applications. The 16K ceiling makes those existing projects unworkable.
Request: Please consider increasing Gemma’s TPM limit. Additionally, please raise the ceiling on the original tier to 100K to 150K tokens. RPD remains a completely sufficient volume safeguard on its own. A higher TPM ceiling would restore the ability to send a single request with real context.
If raising the raw TPM ceiling is impossible, an alternative would be implementing Context Caching for the static portion of the prompt. Allowing developers to cache system prompts, tool definitions, and character cards would mean this fixed overhead stops being repaid every single call. Only the genuinely new content would count against the TPM limit. This would fix the compute-waste issue and provide a functional middle step before Vertex AI’s dedicated infrastructure. Right now, legitimate small workloads like mine are falling through that gap.
Other developers in this same thread are reporting the same 16K ceiling making their existing projects unworkable. It would be appreciated if this change were re-evaluated.
Man, even that isn’t enough on free and you want it on paid??
No single text model has it under 100k on free, why would a cheaper model need to be so restrictive on PAID?
You’re being way too soft on them, they should just go back as it was before.
100k-200k tokens in TPM is not enough for the Gemma model; there is a reason why someone thought this through at the beginning and it was “unlimited”.
The purpose of Gemma’s existence was to be a fast model for agentic use cases → and this makes the TPM absurdly high, not in the range of 100k but 1 million+. For me, it was often in the range of 1-2 million.
Why does Gemma reach such levels? Because it is a model designed for agentic operations along with tools. Using MCP, e.g., notebooklm, a browser, or some services, shoots the TPM into space.
Personally, I created something called “GOALS” where the main agent and its workers create a knowledge base on a specific topic. This is an agent + sub-agents; the TPM immediately hits one million right at the start when the workers are using a browser, Google Search, etc. Well, that is the very purpose of this model’s existence.
Another mode is the autonomous mode, where a special agent creates knowledge sets for me for subsequent actions with an embedding model and semantic operations; there, a file on a specific topic quickly grows to 100kb. After all, for an autonomous agent to build efficiently (which, let me remind you, is one of the purposes of existence for models like Gemma), it must perform deep searches, and that means a jump to 2M tokens in TPM.
The Gemma model with any sort of limited TPM is simply KILLED. Because its entire concept of existence is agentic operation with the help of sub-agents, etc.
This reminds me of an airline giving someone 1,000 flights a year as a reward, but only for distances of no more than 100km ;/.
Having the same issue, my app stopped working, there is no way to increase it even If I pay.