google-gemini / google-gemini/gemini-cli
feat(stats): Expose aggregate 'Chat API requests per day' quota in /stats
- Dominant language
- TypeScript
- Stars
- 107k
- Forks
- 14.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 45
Description
## Problem
There is a hidden aggregate quota called **"Chat API requests per day per user"** that is separate from the per-model quotas currently shown in `/stats`. Users cannot see this limit until they hit it with an error like:
```
Quota exceeded for quota metric 'Chat API requests' and limit 'Chat API requests per day per user'
of service 'cloudaicompanion.googleapis.com' for consumer 'project_number:XXXXXXX'.
```
### The problem:
1. **This quota is invisible** - `/stats` only shows per-model quotas via `retrieveUserQuota`, not the aggregate request count
2. **Users can't access it in GCP Console** - The project number in the error is Google's internal project, not the user's
3. **Users only discover the limit when they hit it** - No proactive visibility
4. **The limits vary by tier** but aren't documented clearly:
- Free tier: ~1,000 requests/day
- Standard/Enterprise: ~1,500-2,000 requests/day
### Why this matters now:
Before PR #16387, **every single request** unnecessarily invoked the classifier which consumed from this aggregate quota. Users who thought they were conserving quota by explicitly setting `--model` were still burning aggregate requests on classifier calls.
## Proposed Solution
Add the aggregate "Chat API requests per day per user" quota to the `/stats` output, showing:
- Used requests today
- Remaining requests
- Reset time
This likely requires a backend change to the `retrieveUserQuota` API to return this aggregate limit alongside per-model buckets.
## Related Issues
- #8474 - General request for cumulative daily usage stats
- #12859 - Misleading quota for Ultra subscribers
- #15743 - Usage limit reached confusion
- #16386 / #16387 - Classifier unnecessarily consuming aggregate quota (now fixed)
## User Story
As a Gemini CLI user, I want to see my aggregate daily request quota (not just per-model) in `/stats` so I can proactively manage my usage and avoid unexpected quota errors.
Contributor guide
Assessment
This issue has not been assessed yet.