## Description Subscription usage is spiking to 75-80% within minutes of a fresh reset window, even with minimal usage. This behavior is new and doesn't match the expected pattern. ## Steps to Reproduce 1. Wait for the usage window to reset (5h rolling window) 2. Start a new Claude Code session 3. Perform light work (a few file reads, some edits, brief conversation) 4. Check usage — already at 75-80% ## Expected Behavior After a reset, light usage over ~30 minutes should not consume 80% of

Subscription usage jumping to 80% within minutes of reset

Open 💬 19 comments Opened Mar 24, 2026 by igorgesso

Description

Subscription usage is spiking to 75-80% within minutes of a fresh reset window, even with minimal usage. This behavior is new and doesn't match the expected pattern.

Steps to Reproduce

Wait for the usage window to reset (5h rolling window)
Start a new Claude Code session
Perform light work (a few file reads, some edits, brief conversation)
Check usage — already at 75-80%

Expected Behavior

After a reset, light usage over ~30 minutes should not consume 80% of the quota. Previously, similar workloads would stay well under 50%.

Actual Behavior

Usage jumps to 75-80% within the first 20-30 minutes after reset, with relatively light activity. The reset doesn't seem to meaningfully restore capacity.

Environment

Model: Claude Opus 4.6 (1M context) via subscription
Platform: Linux (Ubuntu)
Claude Code version: current (as of 2026-03-24)

Additional Context

This is a subscription plan, not API key usage
The behavior started recently — same usage patterns previously stayed well within limits
If the quota is consumed this fast after reset, the 5h rolling window effectively provides no meaningful recovery
/cost shows "You are currently using your subscription to power your Claude Code usage" (no detailed token breakdown for subscription)

Question

Was there a recent change to how subscription usage is calculated or how the rolling window works? The current behavior feels like a regression or unannounced limit change.

View original on GitHub ↗

19 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

andyjamesn · 3 months ago

Same issue here. On max plan and hit limit within half an hour of using it. I almost never hit my limit.

Now I have to wait 4+ hours to use it again! Very annoying

shineon82 · 3 months ago

Same issue here.

Arch Linux, CLI version 2.1.81.

josehenriquedev · 3 months ago

Same issue here.

Ubuntu Linux. Max Plan. CLI 2.1.81

Astro-Han · 3 months ago

You wait 5 hours for the reset, come back, and it's gone in 20 minutes doing the exact same stuff that used to last hours. That's the most frustrating part.

I've been tracking this with a statusline I built (https://github.com/Astro-Han/claude-lens) and the thing is, right after reset the pace is already off. It's not like it gradually speeds up. It's wrong from the first turn.

At least lets you see that early so you can decide whether to stop and wait another 5 hours.

aimarjs · 3 months ago

Same here. A couple of weeks ago, I wasn't able to hit the rate limit, but now I can't finish my 5-hour window without hitting it within 2 hours. The work amount is the same. Using the Claude Code Max subscription on macOS. Very annoying.

majedoler · 3 months ago

I thought something was off, same here. It's burning through rapidly fast.

sophiaashi · 3 months ago

Yeah the 80% jump is wild. I've started routing non-critical requests through alternative models to stretch my quota. TeamoRouter does this automatically — teamo-balanced sends simple tasks to GPT-4o/Gemini and saves Claude for the complex stuff. Doesn't fix the counting bug but at least your session doesn't die in 10 minutes.

https://gateway.teamo.ai/skill.md (takes 2 min to set up)

myleshungerford · 3 months ago

+1 Four days of work have been mostly lost due to this bug.

andiappan-ar · 3 months ago

Same issue , for pro max , For a simple tasks - even outside peak hour , even sonnet burning the usage.

mhbosch · 3 months ago

I've alerted the most prominent German media outlets to the situation, since Anthropic hasn't commented. Furthermore, we need to investigate how we can get our money back for the paid plans. My main priority, however, is to get back to work productively. It seems, though, that I'll have to find a new provider after Anthropic's behavior.

ulazcano · 3 months ago

Same Issue here. Plan Max, today monday 30th March this happend after 5 simples prompts with opus 4.6. I never reached my limit before. I can't work know I'm stuck in a rut with my work; I depend on my agents for various jobs.

mhbosch · 3 months ago

I have do only /compact. This is 20percent of hourlimit and 2Percent Weekly Limit. I cant do work with it,

sclcoder · 3 months ago

I encountered the same problem. After resetting, the first prompt consumed 31%, and I only asked 5 questions before it consumed 100%.

junaidtitan · 3 months ago

Usage jumping to 80% within minutes of reset means the session carries massive accumulated bloat. Cozempic v1.6.11's guard daemon prunes at 25%/55%/80% thresholds. 18 strategies target every bloat type. compact-summary-collapse alone saves 85-95%.

pip install cozempic && cozempic init

matiascorrea007 · 2 months ago

+1 — same issue here, started today (2026-04-29).

Setup

Model: Opus 4.7 (1M context)
Platform: Windows 11 / VSCode extension
Plan: [completá]

Behavior

After session limits reset (UI confirmed reset), I opened Claude Code and sent a single short prompt — no tool use, no agent spawning, just a question. The 5hr session meter immediately jumped to 25%.

This is consistent: every fresh session starts at 20-25% with effectively zero work done.

Confirms what others reported

Light work right after reset → meter jumps disproportionately (matches OP and #53486)
The 5hr "rolling window" provides no meaningful recovery
Switching models mitigates but doesn't eliminate

This bug has been open for 5 weeks (#38369), with parallel reports in #53486 and #45868. Affected users span Linux, macOS, and Windows, across Opus 4.6 and 4.7. Please prioritize — this makes the subscription unusable for daily work.

RalphStevensky · 1 month ago

Yep this is exatly what happened to me, how is it not addressed and fixed yet?! It seems like a scam.

lernin2doit · 27 days ago

Weekly usage was about to hit 70%, session was about to hit 100%. As soon as session capped out, weekly capped out as well. This is absolutely a bug.

parikshit223933 · 20 days ago

Same issue. Mine went 100%. Are you kidding me?
This is 100$ plan. What is going on man?