Detailed Breakdown of the New Compute Limits: Good for Simple Discussions, but Breaking the Coding Workflow
Hi everyone,
Google recently changed the billing/usage model for paying Gemini Plus/Pro/Ultra users. Instead of a fixed daily prompt limit, we are now facing an opaque, rolling 5-hour limit based on dynamic "resource usage."
I empirically tested the system to find out what exactly drains this budget. The data reveals a massive architectural bias against coding and a severe penalty for "Conflicting Objectives." I tracked the usage percentage in the dashboard after specific prompts, comparing an extremely long chat with a completely fresh, empty chat.
The Test Parameters
- Context Size: Long Chat (~750 bubbles, equivalent to a >2,600-page PDF export) vs. New Chat (0 bubbles, completely empty).
- Model Used: Gemini 3.1 Pro (extended thinking mode).
- Goal: Testing incremental limit increases over 9 prompts across different content types.
The Empirical Results (Backed by Screenshots)
The table below illustrates how the 5-hour limit was consumed step-by-step across both scenarios:
| Interaction Step | Long Chat (750+ Bubbles) | New Chat (0 Bubbles) |
|---|---|---|
| Prompts 1 & 2 (Pure Text / Short Code) | 1% (cumulative) | 3% (initial text) |
| Prompt 3 (Python Script Upload, ~52k chars) | +7% (Dashboard: 9%) | +4% (Dashboard: 10%) |
| Prompt 4 (Screenshot Upload) | +1% (Dashboard: 10%) | +1% (Dashboard: 11%) |
| Prompts 5–9 (5x Text follow-ups / Platform discussion) | +22% (Dashboard: 32%) | +12% (Dashboard: 23%) |
| Total Resource Consumption | 32% | 23% |
Technical Analysis: The "Vector Paradox" & AI Deadlock
My findings indicate that the overall length of a chat remains largely irrelevant for reaching the limit during normal interactions in natural speech. However, it has a significant, compounding effect when importing and iterating on code.
Furthermore, the follow-up discussions yielded a massive discrepancy (+22% vs. +12%), most likely due to a Logical Deadlock (Conflicting Objective Optimization) that occurred exclusively in the long chat, forcing the model into cognitive dissonance at the vector level:
>
To resolve this contradiction, the model had to suppress its own resource-saving protocols to comply with my direct command while simultaneously handling platform de-escalation. Processing this internal conflict required thousands of hidden "thinking" tokens. Because these tokens had to be cross-referenced against the massive 750-bubble history, the compute cost skyrocketed.
My Analysis & Critique
- The Good: For casual conversations, text-based follow-ups, or occasional image uploads, the new limits actually hold up surprisingly well—even within massive context windows. Reading and simple text interactions are highly optimized.
- The Dealbreaker for Developers: If you use Gemini Advanced for serious coding and multi-step iterations, this system completely breaks your workflow. The combination of dense code inputs and ongoing discussion forces you into an involuntary hiatus right in the middle of a complex engineering task.
- The "Pocket Money" UX Flaw: Adjusting limits based on actual resource consumption makes sense as user demand grows. However, enforcing a strict 5-hour resetting interval feels patronizing. It feels like parents doling out an allowance on a strict weekly schedule because they don't trust their child to manage a monthly budget. Google needs to allow power users to spend their compute budget in high-intensity sessions rather than forcing arbitrary time-outs.
The European & German Legal Perspective
For EU and German users, this sudden enforcement of an unpredictable hourly limit on a monthly paid subscription is highly problematic under consumer protection laws:
- Unpermissible Modification of Performance (§ 308 Nr. 4 BGB): Tech giants rely on "Subject to change" clauses in their Terms of Service. In the EU, these are void if the change is unreasonable. Shifting the entrepreneurial risk of server load-balancing onto a paying customer mid-month—thereby destroying their professional workflow—is highly unreasonable. A provider cannot unilaterally degrade a service if it jeopardizes the very purpose of the contract. In Germany, the following rule applies: A provider may not simply modify or restrict the promised performance in ongoing contracts unilaterally, unless this is reasonable for the consumer. The Problem: We signed up for a subscription to a "Pro" tool. If Google now introduces an hourly limit that is so tight that we are locked out for 5 hours after just 10–15 clicks, the very purpose of the contract is jeopardized. The Erosion: Courts often rule that modifications which erode the primary contractual obligations (i.e., render the product useless) are void. A "working tool" that you have to put away for 5 hours every 30 minutes loses its character as such.
- Digital Product Protection (§ 327r BGB): If a digital product is unilaterally degraded after purchase, strict consumer protection regulations apply, protecting the user from an unannounced gutting of core performance.
- Violation of the Transparency Principle (Transparenzgebot) (§ 305c BGB): Terms and conditions must be clear and comprehensible. The phrasing "4x higher limit" sounds like an improvement. The reality (massive throttling due to token counting within long contexts) is surprising and opaque to the average user. Such "surprising clauses" (§ 305c BGB) are routinely struck down by courts.When you pay for a "Pro/Advanced" tool advertised to handle large context sizes, but actually using that context locks you out of the software after mere 20–30 iterations, the core performance is compromised. This lack of clarity directly challenges the EU Transparenzgebot.
My Proposal to Google
Give us a Global Account Budget instead of micro-managed hourly intervals. While the necessity of stricter usage limits due to server capacities is understandable, and new pricing models have their value, a monthly fee should grant a flexible monthly budget.
Let power users allocate their compute heavily during intense 3-day coding sessions (burst sessions) rather than micro-managing clicks every 5 hours. Furthermore, server load balancing should be achieved through cheaper regional pricing during off-peak hours rather than imposing patronizing, hard time-outs.
Are your experiences with the new limits comparable to mine?
What would you think about prices depending on the daytime?