[FEATURE] Allow users to configure usage quota reset time / timezone

Resolved 💬 2 comments Opened Jan 22, 2026 by cloudcerebro Closed Feb 28, 2026

Summary

Allow Claude Code users to configure their preferred usage quota reset time or timezone, rather than having a fixed server-determined reset schedule.

Related: This request was previously raised in #3496 but was closed without any official response from Anthropic.

---

Problem Statement

Currently, all Claude Code users have their usage quotas reset at fixed times determined by Anthropic's servers. This creates friction for users in non-UTC timezones:

  • A user in IST (UTC+5:30) might have their quota reset at 7:30 AM, but if they don't start working until 9:00 AM, those 1.5 hours of "fresh quota" are effectively wasted
  • Users cannot align their quota windows with their actual productive hours
  • Peak working hours in one timezone may coincide with quota exhaustion, while quota resets during sleep hours

---

Proposed Solutions

Option 1: User-Configurable Reset Hour

Allow users to set their preferred reset hour (e.g., 6 AM, 8 AM, or midnight in their local timezone).

Option 2: Timezone-Based Automatic Reset

Automatically detect user timezone and set reset time to a sensible local hour (e.g., 3 AM local time).

Option 3: Activity-Based Rolling Window

Start the 5-hour window from the user's first interaction of the day, rather than a fixed clock time.

---

Advantages

For Users

| Benefit | Description |
|---------|-------------|
| Better productivity alignment | Users can align quota availability with their actual working hours |
| Reduced frustration | No more hitting limits during peak productivity while quota sits unused during off-hours |
| Global accessibility | Equal experience for users regardless of timezone |
| Predictable planning | Users can plan intensive work sessions around their personalized reset schedule |

For Anthropic

| Benefit | Description |
|---------|-------------|
| Distributed server load | Spreading resets across 24 hours eliminates concentrated usage spikes that occur when all users rush to use fresh quota simultaneously |
| Improved capacity planning | More predictable, even traffic patterns are easier to provision for than artificial spikes |
| Better user retention | Users frustrated by timezone misalignment may churn; this removes a pain point |
| Reduced support burden | Fewer complaints about "inconvenient reset times" or timezone confusion |
| Competitive advantage | Most AI coding assistants don't offer this level of customization |

---

Potential Concerns & Mitigations

| Concern | Mitigation |
|---------|------------|
| Gaming/abuse | Limit reset time changes to once per month (or per billing cycle) |
| Implementation complexity | Start with simple timezone selection; advanced options can come later |
| Billing cycle alignment | Reset time is independent of billing; quota amount stays the same |
| Support complexity | Clear documentation and UI showing "Your quota resets at X:XX in your timezone" |
| Edge cases (DST, etc.) | Use IANA timezone database; handle DST transitions gracefully |

---

Implementation Suggestions

  1. Settings location: Add to Claude Code settings (~/.claude/settings.json) or account preferences on claude.ai
  2. Default behavior: Keep current behavior as default for users who don't customize
  3. UI indication: Show reset time in user's local timezone in /usage output
  4. Change limits: Allow modification once per billing cycle to prevent gaming

---

Example User Experience

# In settings
{
  "quotaResetTimezone": "Asia/Kolkata",
  "quotaResetHour": 6  // 6 AM IST
}

# In /usage output
Usage: 45% of daily limit
Resets: 6:00 AM IST (in 4 hours)

---

Prior Art

  • Mobile data plans often reset on user-chosen billing dates
  • GitHub Actions minutes reset based on account creation date, not a global time
  • Many SaaS products allow timezone configuration for usage reporting

---

I believe this feature would significantly improve the Claude Code experience for the global user base while also benefiting Anthropic's infrastructure through better load distribution.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗