I was two hours into a debugging session with Claude when it just stopped.
No warning. No countdown. No indication I was close. Just a message telling me I'd reached my usage limit.
Two hours of context — gone. I had to start over.
That was the moment I started actually trying to understand how Claude's rate limits work. What I found surprised me, and I haven't seen it explained clearly anywhere.
Claude has two completely separate rate limits
Most developers assume there's one limit. There are two, and they operate independently:
The 5-hour session limit tracks your message volume within any rolling 5-hour window. This is the one that catches most developers off guard because it resets on a rolling basis — not at a fixed time.
The 7-day weekly limit tracks cumulative usage across a rolling 7-day period. This one resets 7 days after your first message in the window — not on Sunday, not at midnight.
You can be at 0% on the weekly limit and 90% on the session limit. You can max both on the same day if you work in concentrated bursts.
Why "rolling" matters more than you think
The rolling reset is the part that trips people up most.
If you sent your first message at 9:14am on Tuesday, your 5-hour window resets at 2:14pm — not at 10am, not at noon, not at midnight. If you send your first message on Monday at 11pm, your 7-day limit resets the following Monday at 11pm.
This means the mental model of "it resets Sunday night" or "it resets every morning" is wrong for most users. The reset time is personal to your usage pattern.
The practical consequence: you can't plan around a fixed reset schedule. You need to know the actual countdown.
What Claude exposes through its internal API
This is the part most developers don't know exists.
When you use Claude through the browser at claude.ai, the interface makes requests to an internal usage endpoint that returns your actual utilization data — not estimates, not approximations, but the exact numbers Claude uses to decide when to cut you off:
json
{
"five_hour": {
"utilization": 0.82,
"reset_at": "2026-07-15T14:14:00Z"
},
"seven_day": {
"utilization": 0.34,
"reset_at": "2026-07-21T21:00:00Z"
}
}
That utilization field is a percentage — 0.82 means you're at 82% of your 5-hour limit. The reset_at field is the exact UTC timestamp when that window resets.
This data is available to anyone using Claude through the browser. You don't need an API key. You don't need special access. Your existing browser session already has permission to read it — because Claude itself uses it to show rate limit warnings.
Why Claude's rate limits are measured in tokens, not messages
The limits aren't per-message — they're per-token. A short message consumes far fewer tokens than a long one with a code paste.
A 500-line file is approximately 25,000-30,000 tokens. A typical detailed response might be 1,000-2,000 tokens. A debugging session where you paste large code snippets can burn through your 5-hour window in under an hour.
The models also matter. Claude Opus is significantly more expensive per token than Claude Sonnet or Haiku, which affects how quickly you consume your quota.
The degradation problem — quality drops before the limit
Here's something that isn't documented anywhere: Claude's response quality degrades before you hit the hard limit.
The mechanism is attention. Large language models weight recent tokens more heavily than distant ones. In a very long conversation, Claude can technically "see" everything you've written, but its effective attention to content from early in the conversation weakens as more content is added.
Practically, this means you'll notice Claude starting to ignore constraints or forget decisions established earlier in the conversation — usually around 60-70% of the context window. By the time you're at 80%, you're often getting meaningfully worse answers than you would in a fresh conversation with a good summary.
The right time to restart is at 60% of the context window — not when Claude tells you the conversation is too long.
How I track this in real time
After getting cut off enough times, I built a Chrome extension that reads this data directly from Claude's internal API and shows it in the browser.
TokenPulse injects a slim bar above Claude's input box showing:
- 1. Context window percentage in real time
- 2. 5-hour session utilization (exact percentage from Claude's API)
- 3. 7-day weekly utilization (same)
- 4. Countdown to each reset
- 5. Estimated cost per conversation, per day, per week
It also works on ChatGPT, Gemini, DeepSeek and Grok — though those platforms don't expose rate limit data the same way Claude does, so those use client-side estimation.
No API key required. No account. It reads your existing browser session — the same one Claude already uses to pull this data for its own interface.
Practical strategies based on this understanding
Check both limits before starting heavy sessions. If you're at 70% of your 5-hour window, either work quickly or wait for the reset. Starting a 2-hour debugging session at 70% almost guarantees getting cut off.
Start new conversations for each distinct problem. Every message accumulates context. If you're debugging three separate functions, three conversations is more efficient than one long one.
Restart at 60% context, not when Claude tells you to. By the time Claude warns you, quality has already degraded. Summarize at 60%, start fresh, paste the summary.
Use Haiku and Sonnet for iteration, Opus for final decisions. All models consume the same rate limit quota. Matching model capability to task complexity extends how long you can work before hitting limits.
Time heavy sessions around your actual reset time. Check your reset countdown before starting an intensive session. If your 5-hour window resets in 20 minutes, waiting is often worth it.
The extension is free and open source if you want to look at how it reads Claude's usage data:
Chrome Web Store: token-pulse.in
GitHub: github.com/anu-ship-it/TokenPulse
Happy to answer questions about how the rate limit detection works in the comments.
Top comments (2)
This is really cool. I am a Claude Pro subscriber $20/mo and when I use Fable 5 High I get 1 prompt before they start charging me usage tokens. I usually work around that by scaffolding out in Sonnet 5 first, then when I need the larger work done, I 1 shot it in Fable 5 and then switch back to Sonnet 5. But, programmatically working with rate limiting on the usage detection is super cool that you outlined here. Thanks!
The useful bit here is treating rate limits as inventory, not a moral failing by the tool. Once the reset is rolling, the scarce resource is the next uninterrupted block of context. A small local meter changes behavior because it gives you a stopping rule before the session dies mid-debug.