Bug: Setting subscription-level On-Demand Credit Cap to 0 blocks purchased Monthly Commitment Pool credits for Free tier users
Summary
When a Free tier user sets the subscription-level On-Demand Credit Cap to 0 via the Customers Portal, the purchased Monthly Commitment Pool credits are also blocked, preventing the user from using any credits at all.
Expected behavior
Setting the On-Demand Credit Cap to 0 should only block On-Demand (overage) credit usage. Purchased Monthly Commitment Pool credits should still be accessible, since the user has already paid for them.
- Cap = 0 → On-Demand credits blocked
✅ - Cap = 0 → Purchased Monthly Commitment Pool credits still usable
✅
Actual behavior
Setting the On-Demand Credit Cap to 0 blocks all credit usage, including the purchased Monthly Commitment Pool credits. The user is unable to use any GitLab Duo Agent Platform features despite having paid for credits.
- Cap = 0 → On-Demand credits blocked
✅ - Cap = 0 → Purchased Monthly Commitment Pool credits also blocked
❌
Steps to reproduce
- As a Free tier user on GitLab.com, purchase a Monthly Commitment Pool of GitLab Credits (e.g., 5 credits)
- Sign in to Customers Portal
- On the subscription card, select GitLab Credits dashboard
- In the On-demand Credit Cap panel, turn on the Monthly On-demand Credits cap toggle
- Set the cap value to
0 - Select Save
- Attempt to use a GitLab Duo Agent Platform feature (e.g., Duo Chat)
Result
Access to GitLab Duo Agent Platform features is suspended, even though the user has purchased credits available in their Monthly Commitment Pool.
Environment
- GitLab.com (SaaS)
- Tier: Free
- GitLab version: 18.11
- Cap configured via: Customers Portal
Additional context
The documentation states that the Usage Caps feature (introduced in GitLab 18.11) is intended to prevent unexpected overage charges. Blocking already-purchased credits when the cap is set to 0 is contrary to this intent and results in a poor user experience for Free tier users who have paid for credits.