Google announced on August 28, 2026, that Gemini Notebook would replace its fixed daily feature caps with a compute-based usage model beginning September 2, a structural shift that changes how every consumer account on the platform tracks and spends its AI allowance. Under the new system, a user's overall usage limit will factor in prompt complexity, chat length, number of sources, and the features you use; a short factual query costs the compute budget far less than generating a multi-source Video Overview or a full Slide Deck. Google is the third vendor to restructure limits this way. The industry has decided that transparent prompt counts are over. The new metric is compute cost, and the vendor decides what that number means.
The 120-route construction ERP at coenconstruction.com calls GPT-4o for document extraction through a scheduled job. The prompt is versioned. The inputs are standard PDFs. The batch size has not changed in three months. Under a prompt-based limit, that workload is predictable. I know how many documents the job will process and how many API calls that requires. Under a compute-based limit, the same inputs can consume different amounts of quota depending on what OpenAI decides the complexity was that day. The job that ran Monday for five units might cost forty-seven units on Tuesday because the vendor classified the same PDF as complex.
The pricing is transparent but the budget is not
Thepunchlist.ai runs a classifier every morning that processes punch-list photos through GPT-4o vision. The system prompt is identical across all images. The resolution is standardized. The API returns deterministic JSON. That workload was predictable when the rate limit was a fixed number of requests per minute. OpenAI still publishes the per-token price, and the API still returns token counts in the response headers. The invoice is transparent. What changed is the allocation.
Once you hit the limit, Google will switch you to a smaller model, so you can continue working. That is the new pattern. The vendor detects that you hit a usage threshold, silently serves a cheaper model, and the response still returns status 200. The capability degrades but the integration does not break. The model ID in the logs does not change. The only signal is accuracy drift in production, and by the time a customer reports that half the line items are missing from the extraction, you are debugging a phantom.
Compute-based limits make usage unpredictable for batch workloads
Estimate.pro calls Claude Sonnet through AWS Bedrock for bid-item extraction. The integration processes twelve million tokens a day. Customers load historical bid sets when they onboard, so the daily volume is stable. Under a prompt-based limit, that load is a fixed ceiling. There are strict Claude code limits governing usage, including a five-hour rolling window and weekly caps. Under compute-based limits, the same twelve million tokens might count as eight million on Monday and nineteen million on Wednesday, because Anthropic reclassified the complexity mid-week.
The shift is not about protecting shared infrastructure or managing abuse. Vendors already had rate limits, token quotas, and per-minute throttles for that. Compute-based limits solve a different problem. They let the vendor reprice the same workload without changing the per-token cost. The API contract stays stable. The model ID does not change. The integration keeps working. The cost just becomes variable, and the variance is invisible until the limit hits.
The pricing is still transparent. The usage budget is not.
Limits may change without notice, including due to capacity constraints; when there's a large increase in activity in Gemini Apps, Google may change limits to maintain a high standard of quality. That is the new normal. The vendor can adjust your effective quota in response to load, launch week traffic, or data center capacity, and the change will not appear in the API response. The first signal is a 429 error or a silent model downgrade, and the workload that ran fine last week now exhausts its allocation by Tuesday morning.
Compute-based limits are fine for interactive chat. They are a cost-management disaster for production batch jobs that depend on predictable throughput. The job that extracted forty PDFs yesterday might only handle twelve today, and the only way to know is to track quota exhaustion in logs and build fallback routing into every integration. The vendor moved the uncertainty from the price to the allocation, and now every batch workload needs multi-provider failover just to survive an opaque quota change.