claude-code - 💡(How to fix) Fix [FEATURE] Turn the 5h limit into a rolling window, instead of emitting "resets at <time>" whilst expecting form the user to sent a message first

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…
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

The 5h limit reset is misleadingly promoted to the user as a 'given':

<img width="757" height="153" alt="Image" src="https://github.com/user-attachments/assets/be2d7250-40f1-4b72-a845-e51a784221c4" />

The way it is set-up right now where a 'message has to be sent' is a policy that makes no sense at all in regards to the why and the resulting impact for user-experience.

Sometimes a large amount of work has to be done of which can be estimated that more of a single full 5h session is required. With a rolling window, I can set my alarm at a given time and have clean carry-over to a fresh 5h session without risking a large cache-miss, thus not rendering the promised 1M context window utterly useless.

The ask of Claude is now to "send a message" to start, which means in order to make most of the day I would have to either atune my computer use to the 5h window in order to send those messages in time to get everything in alignment with my schedule, or automate it.

The most sensible way is then to automate sending a message "hi" to mr Haiku at 8:00, so i can start work execution at 11:00 and have a clean carry-over without cache hits for the next 5h window (also requiring input).

Proposed Solution

The non-rolling window is fruitless, and disfavors the user-experience.

I'm sure Anthropic's retention rates would benefit from an actual rolling 5h window, instead of the "send hi to mr. Haiku first" methodology.

I can safely infer that this non-rolling window is a load/abuse reductive measure, however in the sense of abuse: Those who automate abuse are not thwarted, and only those who not abuse are affected.

In terms of load: Given the latest improvements in quotas in lights of the announcement of a partnership that increased the service delivery capabilities of Anthropic, and the net-positive effect on user retention rates, I think it would be ill advised to not start providing this real 5h rolling window to users and reduce some of the frustration when it comes to having to work around big cache-misses (often seen as 'bugs' by users).

Alternative Solutions

No response

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

No response

Additional Context

No response

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING