Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Feature Request: Allow users to configure 5-hour session window offset (timezone disadvantage) [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#47866•Fetched 2026-04-15 06:40:05
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
0
Author
kjh91-samkjh91-sam
Participants
github-actions[bot]github-actions[bot]kjh91-samkjh91-sam
Timeline (top)
commented ×2labeled ×2closed ×1

Root Cause

I love Claude Code. I'm a paying Max subscriber. I use it all day, every day. But this timezone-locked session window has single-handedly turned my evenings into overtime — not because I want to work late, but because the product's rate limit schedule makes it irrational not to. That's not a good user experience. That's a structural penalty for living in the wrong timezone.

Fix Action

Fix / Workaround

Current Workaround

Code Example

{
  "sessionWindowOffsetHours": 3
}
RAW_BUFFERClick to expand / collapse

The Problem

The 5-hour session windows appear to be fixed at UTC-aligned slots (e.g., 00:00, 05:00, 10:00, 15:00, 20:00 UTC). I'm a Max plan subscriber in South Korea (KST, UTC+9), and this translates to:

WindowKST TimeUsable during work?
105:00 – 10:00❌ Sleeping / commute
209:00 – 14:00✅ Morning work
314:00 – 19:00✅ Afternoon work
419:00 – 00:00❌ Should be off work
500:00 – 05:00❌ Sleeping

I get exactly 2 usable session windows during business hours. A developer in San Francisco with the same plan gets 3.

Why This Hurts

Every single day, my session limit exhausts around 6–7 PM KST. That's exactly when I should be wrapping up and going home. But then the next window opens at 7 PM, and I think: "The limit just reset, I can finally use Claude again..." — and I end up working overtime. Every. Single. Day.

This isn't a minor inconvenience. This is a structural incentive to overwork that's baked into the product for anyone east of UTC+5.

To make it worse: my weekly quota still has plenty of capacity. I'm not out of usage. The weekly limit says I can keep going. But the 5-hour session window says no — not until 7 PM. So I either:

  1. Wait until 7 PM and work overtime to use what I already paid for, or
  2. Pay extra via extra usage during the afternoon to access quota that's technically still available in my plan

Either way, I lose. I'm either paying with my time or paying with my money for something my subscription should already cover.

This Is NOT the Same as #32550 / #1450

Those issues asked for the reset time to be displayed in local timezone. That's a cosmetic fix. My problem is fundamentally different:

The window boundaries themselves need to be movable.

Showing me "resets at 7:00 PM KST" instead of "resets at 10:00 UTC" doesn't help. I already know when it resets. The problem is that the reset schedule is structurally misaligned with my working hours, and I have zero ability to change it.

Who This Affects

This isn't a niche problem. UTC+8 to UTC+9 covers:

  • 🇰🇷 South Korea (~52M)
  • 🇯🇵 Japan (~125M)
  • 🇨🇳 China (~1.4B)
  • 🇹🇼 Taiwan (~24M)
  • 🇭🇰 Hong Kong (~7.5M)
  • 🇸🇬 Singapore (~6M)

That's over 1.6 billion people in some of the most developer-dense regions in the world. Every single one of them gets 2 business-hour windows while US-based users get 3.

And it's not just East Asia. Anyone outside the Americas is affected to varying degrees — European users (UTC+1~+2), Indian users (UTC+5:30), Australian users (UTC+10~+11) all face their own misalignments.

Proposed Solution

Allow users to set a session window offset in ~/.claude/settings.json:

{
  "sessionWindowOffsetHours": 3
}

This shifts the entire fixed window grid by N hours. For example, a KST user setting offset to 3 would get:

WindowKST TimeUsable during work?
108:00 – 13:00✅ Morning
213:00 – 18:00✅ Afternoon
318:00 – 23:00✅ Evening (optional)

Three full windows during working hours. Same plan, same price, actually fair.

Alternatively:

  • A "timezone": "Asia/Seoul" setting that auto-calculates the optimal offset
  • Or simply let users pick their "work start hour" and derive the grid from that

Current Workaround

None. There is absolutely no way to shift the window boundaries. No setting, no config, no hack. You just live with it.

Final Note

I love Claude Code. I'm a paying Max subscriber. I use it all day, every day. But this timezone-locked session window has single-handedly turned my evenings into overtime — not because I want to work late, but because the product's rate limit schedule makes it irrational not to. That's not a good user experience. That's a structural penalty for living in the wrong timezone.

Please give international users the ability to align their session windows with their actual working hours.

extent analysis

TL;DR

Allowing users to set a session window offset or configure their timezone could help align session windows with their working hours, mitigating the issue of exhausting session limits during business hours.

Guidance

  • Consider implementing a sessionWindowOffsetHours setting in the user's configuration file, as proposed, to shift the session window grid by a specified number of hours.
  • Alternatively, introduce a timezone setting that auto-calculates the optimal offset based on the user's location, or allow users to specify their "work start hour" to derive the grid.
  • Evaluate the impact of this change on users in different timezones, ensuring that the solution is fair and effective for a global user base.
  • Test the proposed solution with a small group of users in different timezones to validate its effectiveness before rolling it out to all users.

Example

A potential configuration file update could include:

{
  "sessionWindowOffsetHours": 3
}

This would shift the session window grid by 3 hours, potentially aligning it with the user's working hours.

Notes

The proposed solution may require significant changes to the existing rate limiting system, and its implementation should be carefully planned and tested to avoid unintended consequences.

Recommendation

Apply a workaround by introducing a configurable session window offset or timezone setting, as this would allow users to better align their session windows with their working hours, addressing the root cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#mixed precision#training loop#device allocation#model download#tokenizer error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Feature Request: Allow users to configure 5-hour session window offset (timezone disadvantage) [2 comments, 2 participants]